Software Architecture: The Hard Parts — Episode 3

After splitting the code, one database remains shared. Change control, connection management, scaling, fault tolerance, and a smaller blast radius favor separation. Foreign keys, data relationships, and transactions pull back: a service boundary turns local consistency into a distributed problem.

The split has five steps: identify domains, group tables into schemas, remove cross-schema joins and move logic behind APIs, separate schemas physically, and switch clients. Migration may combine backup and restore with replication; old links are removed after traffic moves.

The hosts compare relational, key-value, document, wide-column, graph, cloud-native, and time-series databases. Criteria include modeling, scalability, availability, consistency, community support, and read-write profile. The table offers orientation, but subjective ratings cannot replace product research.

Granularity concerns service size. Scope, change rate, scaling, fault tolerance, and security push services apart; transactions, workflows, data links, and shared domain libraries pull them together. The notification center illustrates change cadence and meaningful naming; the profile-and-password case weighs consistency against data protection.