Software Architecture: The Hard Parts — Episode 6

Anton, invited on Monday to read a four-hundred-page book by Thursday, starts with the chapter that annoyed him most: the authors take on many deep topics, each worth a book of its own, and the result is idiosyncratic. A contract is the format in which parts of a system interact, and the chapter moves between two extremes: strict contracts with field names, types, and order — exchanging concrete objects and RPC — and loose ones, where you work out from the arriving data what you were sent: JSON, YAML, a map. The authors put GraphQL in the middle, though Anton would count it as strict; a classification of two extremes and "something in between" is a trait of the whole book, Vova notes. Anton points to the classic — Hohpe's Enterprise Integration Patterns: four integration styles and the idea that a contract is the grammar of service communication, where what counts is the noun; Vova recalls the episode on Kleppmann's encoding chapter with JSON, XML, Protobuf, and Avro.

The useful part of the chapter is the anti-patterns. Architects like strict contracts because they reduce errors — critical for services that move money or personal data in a bank; the price is the difficulty of change, when adding a mandatory field means touching the whole system. Loose contracts seem flexible, but a schema checks that mandatory fields are present, not that components understand the data the same way: Anton's example is a user name that is a mere label in the personal account and an identifier in an attached ticketing service, so after a name change the person cannot collect the ticket at the cinema. The authors' answer is consumer-driven contracts: consumers describe in advance which data they need, the provider builds those contracts into its automated tests and ships a version only when all are green. Alexander sees a compromise: rigidity is added to a loose format but checked at deployment rather than at runtime, and responsibility moves to the consumer teams — if they are not up to it, you get a mess. Anton stresses the minimal necessary data: extra fields "just in case" breed fuzzy logic.

Anton recalls special projects where a couple of extra fields requested by a facade pushed processing time into 504 timeouts. Vova explains stamp coupling from his years in the travel industry: the Open Travel Alliance schema — hundreds of XML schemas almost the whole industry runs on; a large shared document in which each service enriches its own piece can replace an orchestrator in the choreography of many vendors with different licensing, but it demands a different service architecture and hurts throughput — they wrote a custom cache in MongoDB to avoid pushing large files over the network. Alexander shares a student trauma: a climate model in Fortran with two screens of three-letter global variables at the top of every file, which made him change his thesis topic — global stamp variables look the same. Anton adds what the authors left out: a document's lifecycle is rarely linear, it branches and needs stamps from parallel structures, and computing a sane document status becomes categorically hard.

The analytics chapter is the club's third pass at the topic. Vova covers the basics: the DWH is a separate store into which data is extracted from many sources, transformed into a star or snowflake schema, and loaded; the consumers are analysts with their queries, BI, and reports; the engines are relational MPP databases like Greenplum, as Alexander notes. The upsides are centralisation and an isolated tool for analysts; the downsides are extreme domain knowledge, brittle integration as the schemas of hundreds of sources keep changing, complexity, and poor scalability: whole teams clean and catalogue data so that reports at least do not get worse. The data lake is the next approach historically: less structuring, raw data exported with minimal transformation and shaped per data mart — schema on read instead of schema on write; but the relationships between data have to be invented after loading, and ad hoc transformations become the norm. Alexander recalls Vlad's analysis: analytical and transactional models differ, and partitioning by technology — "these databases here, those there" — works poorly in a complex world, because business lines do not want to lose domain knowledge on export.

Vova describes data mesh as "we are all in one domain boat": data is the most valuable and longest-lived asset, tied to its domain and worth little without it, while the older approaches were a technology story of two teams, one of which did not know the domain. Alexander lists Dehghani's four principles — decomposition around domains, data as a product, autonomous teams with data engineers inside, and the platform as an ecosystem — and notes the authors' addition: the data product quantum, DPQ, a component next to the transactional service responsible for the analytical interface, with a nod to service mesh and sidecars. Three variants: native, cooperative, and aggregate — metrics computed from product events, which Anton compares to fitness functions for a product. Alexander admits he has not built such quanta and recommends Dehghani's book: her article of three years ago was deep and to the point, while here every chapter is cramped.

The final chapter on trade-off analysis disappointed Alexander: instead of a clear algorithm, several more ways to evaluate, whereas Vlad had a decision tree. So he retells another book: a system is judged by functional requirements and by reliability and fitness for use, with trade-offs tied to quality attributes. The tools: sensitivity points, where a decision affects one attribute; trade-off points, where security hits performance, and three synchronised nodes perform worse than one but survive a failure; risks with probability and cost — every next nine is an order of magnitude dearer, and unless you are Google you do not need five; and opportunities for the future. The attributes are RTO and RPO, time to market, total cost; scenarios and a utility tree by attribute. Vova remembers the chapter as a collection of advice: look for the points, build matrices, stay in context, and do not be an evangelist, who inflates the pluses and misses the minuses; Alexander refines — you can evangelise all four options, the question is narrowness of view. Anton adds Uncle Bob: final decisions are made at the last moment, when all constraints are collected. The book is closed; the club now picks a format — white papers, Q&A, a Telegram vote.