Software Architecture: The Hard Parts — Episode 3

Alina likes this book less than the previous one but found it useful: the heroes' dialogues show how a structured professional opinion grows out of generalities. By now the heroes have split the monolith into domain services around one big database, and chapter 6 asks what to do with it. Disintegrators are the factors for splitting: change control, because the database is an implicit API and dropping a column or changing a type breaks three services while the forgotten fourth is discovered by its crash; Vova adds that with four hundred microservices such changes can never be made. Then connection management: every instance has its own pool, connections sit idle, and the authors propose quotas — equal at first, then by measured need; scalability, fault tolerance with the database as a single point of failure, the architecture quantum — which Ilya defines for himself as the deployment blast radius — and choosing a storage type for the data.

Integrators are what holds data together: relationships through foreign keys, views, and triggers that cannot be cut without losing transactionality, and database transactions themselves, for whose sake services cut too finely have to be merged back. Alexander recalls Vlad: if you need one transaction, it is one aggregate and there will be no distributed system. Then the five steps, which the authors now call steps rather than patterns — the participants see it as instant feedback on their earlier complaint. Alina walks through them: analyse the data domains; assign tables to domain schemas, preserving query compatibility with synonyms; separate the connections so that no cross-joins remain and other domains' logic moves to the service level — a state the authors call "nirvana" and data sovereignty, paid for with performance and consistency; move schemas to separate servers through backup/restore or replication, which, in Alexander's experience, still starts with a restore and a catch-up stream; and switch over, deleting the old.

The authors point to Sadalage's Refactoring Databases, and a large part of the chapter surveys storage types on seven characteristics: ease of learning and modelling, scalability, availability, consistency, language support, community size and, as Ilya notes, the ability to hire, plus the read-or-write skew. Alexander runs through the types: relational — the gold standard with SQL and ACID; key-value — a big hash table that can only fetch by key, so data is modelled for the queries; document, popularised by MongoDB, which was once fast because it did not write to disk; column-family, with Cassandra's tunable consistency for reads and writes and a non-trivial model; graph, where Alexander managed data himself and gave a talk, with the elegant Cypher query language and an enterprise price like an airplane wing; NewSQL such as Spanner and CockroachDB, stretching CAP through infrastructure; cloud-native; and time series such as InfluxDB and TimescaleDB.

The final star-rated table resembles the comparison of architecture styles in Fundamentals — Alexander shows his notes on that book, where service-oriented architecture scored "better than layered": the numbers are debatable, taken not from thin air but from somewhere nearby, and the table will not spare you from learning each type. Vova notes that columnar databases like ClickHouse are absent, and Ilya recalls the South Park episode where the government decides by a headless chicken. The participants' impression: the comparison looks copied from NoSQL overviews of a decade ago, as if time stood still in this chapter. Yet the point of the chapter is not the stars: once the database is split, each service picks storage for its own data, and that is where the book's heroes begin the practical split.

Chapter 7 separates modularity — which meaningful parts to split into — from granularity — how fine. The metrics are statements and the number of public interfaces, both hospital averages. The table is again two columns, very similar to the previous one. Disintegrators: the service's scope — on the example of notifications sent three ways; code volatility — one part changes weekly, the rest twice a year, and extracting it spares retesting and redeploying the whole unit, though Ilya notes the same argument can keep together modules that change in sync; scaling — a monolith scales as a whole and resources vanish into nowhere, doubly important at today's hardware prices; fault tolerance, which you only get if services do not call each other at every step; security — the sensitive part goes into a separate perimeter; and extensibility, where Alexander warns against premature optimisation: a monolith surrounded by moon-services still falls together with Jupiter.

Integrators: database transactions, a workflow with orchestration or choreography across many services, shared code, and data relationships. On shared code the authors are careful: infrastructure libraries — logging, monitoring, authorisation — are justified, while domain logic in a library used by dozens of services demands rebuilding all of them on every change and turns the system into a distributed monolith. Among the heuristics is the name: if you cannot name a service, it is cut wrong; Ilya was amused by the example where postal mail changes weekly and SMS and email twice a year. The story's case is whether to split passwords out of the profile: security demands a separate service, the business is not ready for eventual consistency in the profile, and in the end security is provided by design through a framework while transactions stay in one service; the project sponsor chooses security after a recent leak. Alina liked that the architect ran the conversation as a facilitator rather than bringing a ready answer. Alexander adds the news of the week: Apple showed a passwordless login protocol on device private keys — a radical way to cut passwords out of the database altogether. Next session — part two, how to put the pieces back together.