System-Architecture

Overview This compares two data architecture patterns for microservices: a shared database where multiple services read and write the same schema, versus database per service where each service owns an isolated data store. The choice determines how tightly services are coupled, how transactions and queries span service boundaries, and how independently teams can deploy and scale. Comparison Diagram Shared DatabaseDatabase Per ServiceService AService BService CSharedDBService ADB AService BDB BService CDB CSingle point of coupling & contentionIsolated data, independent scaling Comparison Table Aspect Shared Database Database Per Service Schema ownership One schema shared and often co-owned by multiple teams Each service exclusively owns and evolves its own schema Write path Any service can write directly to shared tables Writes go only through the owning service’s API Cross-service queries Simple SQL joins across tables in one database Requires API calls, data replication, or an aggregation layer Distributed transactions Native ACID transactions across affected tables Needs sagas or eventual consistency to span services Schema migrations Any change risks breaking other services using the table Migrations are local and safe to run independently Independent scaling Database becomes a shared bottleneck under load Each store can be scaled or tuned to its own service’s needs Technology choice All services locked into one database engine Each service can pick the best-fit database technology Failure isolation A database outage or lock contention affects every service An outage is contained to the owning service’s data Key Differences Shared database allows cheap cross-table joins but couples every consuming service to one schema Database per service enforces service autonomy at the cost of needing sagas for cross-service transactions Schema changes in a shared database require coordinating multiple teams, while per-service schemas change independently A shared database creates a single failure domain; per-service databases contain outages to one service Polyglot persistence — choosing different database engines per need — is only possible with database per service When to Use Each Shared Database ...

Overview A shared database lets multiple services read and write the same tables through one common schema, while database per service gives each service its own private data store that only it can touch directly. The choice determines how tightly services are coupled at the data layer, how independently teams can deploy, and how much work cross-service queries and transactions require. Comparison Diagram Shared DatabaseDatabase per ServiceService AService BService CShared DBone schema, every service reads/writes it directlyService XService YService ZDB XDB YDB Zeach service owns a private schema, accessed only via its API Comparison Table Aspect Shared Database Database per Service Data ownership No single owner — all services see and can modify the same tables Each service exclusively owns its schema; no one else can touch it directly Access path Services query the database directly, often with raw SQL against shared tables Other services only get data through the owning service’s API or published events Cross-service transactions Native ACID transactions and joins span all the data in one commit No shared transaction; consistency across services needs sagas or eventual consistency Cross-service queries Simple SQL joins pull data from any table in one query Requires API composition, data replication, or a separate CQRS read model Schema changes A column or table change can silently break unrelated services Schema changes are internal; only the public API contract must stay stable Technology choice All services are locked into one database engine and schema Each service can pick the storage engine that fits its data (polyglot persistence) Failure isolation A database outage or lock contention affects every service at once An outage in one service’s database doesn’t directly take down the others Operational overhead One database to provision, back up, and tune N databases to provision, monitor, back up, and scale independently Key Differences Shared database gives every service direct access to the same tables, so a change in one place can silently break another service’s queries — a form of tight coupling. Database per service forces all cross-service data access through an API, giving each service true encapsulation of its data. Cross-entity consistency is a native ACID transaction in a shared database, but needs a saga pattern or eventual consistency once data is split per service. Reporting and ad-hoc joins are trivial with a shared database’s SQL, while database per service usually needs a separate CQRS read model to answer cross-service queries. Database per service allows polyglot persistence — each service picks its own database engine — whereas shared database locks every service to one engine and schema. When to Use Each Shared Database ...