Data ownership and database per service

Why ownership is the first data question

Chapter 6 split systems into services that are deployed, scaled and changed independently. Code splits relatively easily; data does not. An order refers to a customer, a menu item, a restaurant and a courier, and every team wants to read, and often change, some part of it. The most important question in a distributed data architecture is therefore not which database to buy but who owns each piece of data: which component is allowed to change it, which one enforces its rules, and how everyone else gets to see it.

Ownership matters because data outlives code. Services are rewritten every few years; customer accounts, ledgers and medical records are kept for decades. Getting ownership wrong produces the expensive kind of architectural debt: two services that cannot be released separately because they share tables, a status field that three teams overwrite in turn, or a monthly report that nobody can reproduce because the numbers come from five copies of the same data that disagree.

This section uses two running examples that recur throughout the chapter: a food-delivery platform (customers, restaurants, couriers, orders) and an online bank (customers, accounts, payments, a ledger).

System of record and data ownership

A system of record is the authoritative source for a given piece of data: the place whose value wins when copies disagree. In the bank, the core ledger is the system of record for account balances; the balance shown in the mobile app, the one in the fraud engine's cache and the one in last night's data warehouse load are all copies. In the food-delivery platform, the restaurant's own menu service is the system of record for prices, even though the search index, the mobile app's offline cache and the order lines all hold copies of them.

Data ownership turns this into a responsibility. The owning component (and the team behind it) is the only one that writes the data, enforces its invariants (rules that must always hold, such as a ledger entry is never edited, only reversed), decides its schema, and publishes it to others through an interface it controls. Ownership is a design decision, not a property of the database: two services can sit on the same database server and still have clear ownership, and two services with separate databases can still fight over the same facts if the boundary between them is drawn badly.

A useful rule from Software Architecture: The Hard Parts (Neal Ford, Mark Richards, Pramod Sadalage and Zhamak Dehghani, 2021) is that the service that writes to a table owns it. Reading is cheap to share; writing is not, because whoever writes must enforce the rules.

The shared database and why it couples services

The simplest way to let several applications work with the same data is to give them all access to one database. Martin Fowler called this an integration database (2004): a database that is the integration point between applications, as opposed to an application database that serves one application only. It looks attractive: no APIs to build, joins work across everything, and one transaction can update orders and payments together. Fowler's verdict, shared by most architects, is that integration databases should be avoided, because the coupling they create is deep and mostly invisible.

Consider the forms of coupling it introduces. Schema coupling: every table and column is effectively a public API. Renaming orders.state to orders.status breaks any service that reads it, and nobody can be sure which ones do, because SQL queries are scattered through many codebases, reports and spreadsheets. Deployment coupling: a schema change has to be coordinated across every team that touches the table, so services that were meant to be released independently are released together. Semantic coupling: the schema must serve every client, so it grows more general and more confusing (Fowler notes that it ends up trying to unify concepts that belong in separate bounded contexts), and the business rules for a table end up duplicated, inconsistently, in every service that writes it. Runtime coupling: one service's slow report query or lock-heavy batch job degrades every other service, and the database becomes a shared single point of failure and a ceiling on connections.

None of this is fatal for a single application or a modular monolith whose modules respect each other's tables, or for the coarse-grained service-based architecture in which a handful of domain services often share a database deliberately. It becomes a problem when teams expect independent deployability but keep the shared tables, which is a classic route to a distributed monolith.

Database per service

The alternative, associated with microservices, is the database-per-service pattern: each service's persistent data is private to it and other services can reach it only through the service's API or the events it publishes. Chris Richardson's pattern catalogue (microservices.io) notes that this does not have to mean a separate server per service. There are three levels of separation, and the important line is the first one.

The benefits mirror the costs of the shared database: owners change their schemas freely, scale and tune their stores independently, choose the right kind of database, and contain failures. The costs are real and should be stated in any decision record. Joins across services are gone and must be replaced by API composition or replicated data. A single ACID transaction can no longer span orders and payments; cross-service changes become sagas with compensating steps. Referential integrity across services (every order points to a real customer) is no longer enforced by foreign keys. Reporting needs a separate pipeline. And there are more databases to back up, patch and monitor.

The Hard Parts frames the decision as a balance of forces. Disintegrators push towards splitting data: change control (how many services break when a table changes), connection limits, scalability, fault tolerance, the wish for independently deployable units and the need for different database types. Integrators pull data together: relationships that need referential integrity, and operations that genuinely need one atomic transaction. If two tables are always changed together in one transaction and have no independent life, that is strong evidence they belong to the same owner.

When several services write the same data

Ownership questions become hard when more than one service legitimately changes the same entity. The Hard Parts distinguishes three situations. With single ownership, only one service writes the table, and it simply owns it. With common ownership, most services write the same table (an audit log or a set of configuration settings, for example); the usual answer is to create a dedicated service that owns the data and give everyone else an API, often an asynchronous one so writers are not slowed down. With joint ownership, a small number of services, typically two, write the same table, usually within the same domain. The book offers four techniques for joint ownership.

No technique is free, and the right one depends on how often the data changes, how strict its rules are and how independent the teams need to be. In practice, delegation is the most common answer for business entities with a lifecycle (orders, payments, bookings), table split works well when the jointly written columns are really different facts that happened to be stored together, and consolidation is the honest answer when the two services were split too finely in the first place.

Reading data you do not own

Once ownership is settled, every other service still needs to read the data. The kitchen display needs the customer's delivery notes; the fraud engine needs the account's recent payments. There are four broad options, and each trades freshness against coupling. Note that event-driven designs, covered in Chapter 6, provide the third and fourth.

Fowler calls the fourth option event-carried state transfer: events such as MenuItemPriceChanged carry the new values, so consumers do not need to call back. A related mechanism, change data capture (CDC), reads the owner's database log and turns each committed change into an event, which avoids the dual-write problem (writing to the database and publishing an event separately, so that one can succeed while the other fails). The transactional outbox, which solves the same problem from inside the application, is covered with sagas.

Reporting across services

Database per service makes one old task harder: the cross-cutting report. Revenue by restaurant by week, net of refunds, split by courier type needs orders, payments, restaurants and deliveries. Running it by calling four APIs page by page is slow and puts reporting load on operational services. Querying their databases directly reintroduces the shared-database coupling through the back door.

The usual answer is to separate reporting from operations. Fowler described a reporting database: a separate store, shaped for queries and fed from the operational systems, which reporting users may read freely. Today this is usually a data warehouse or lakehouse fed by CDC or events, discussed in analytics and streaming. For small, near real-time views inside the product (a restaurant's dashboard of today's orders), a service can build its own read model from events, the idea behind CQRS. Either way, the pipelines that feed reporting depend on the owners' data structures, which is why they need contracts.

Data contracts

A data contract is an explicit, versioned agreement between the owner of a data set and its consumers. It states the schema (fields, types, which may be null), the meaning of each field (is amount in pence or pounds, including VAT or not?), quality expectations (no duplicate order identifiers, at most 0.1% of rows with a missing restaurant), service levels (how fresh the data is, how long it is kept), who owns it and how changes are announced. It applies the idea of an API contract to data that flows between teams through events, CDC streams and warehouse tables.

Contracts are most useful when they are machine-readable and checked automatically: a pipeline that rejects a schema change which would break registered consumers, or a test that fails when a quality rule is violated. The Open Data Contract Standard (ODCS), maintained by the Bitol project under the Linux Foundation AI & Data, defines a YAML format covering schema, quality rules, service levels, roles and support channels. Data contracts are not free: someone must write and maintain them, and overly strict contracts slow down change. The Hard Parts contrasts strict contracts (precise, verifiable, tightly coupling) with loose ones (easier to evolve, needing more testing), and suggests consumer-driven contracts, in which consumers state what they actually use, as a middle path. How to change a schema without breaking consumers is the subject of schema evolution.

Common mistakes

Splitting services but keeping the shared tables. Teams get the operational cost of distribution without the independence it was meant to buy. If services cannot be deployed without coordinating a schema change, they are not independent. Entity services. A CustomerService that is nothing but create, read, update and delete over a table, called by every other service, is a shared database with extra latency; ownership should follow business capabilities and their rules, not nouns. Copies that quietly become masters. See the warning above. Ignoring reporting until the end. The first finance report after the split often reveals that nobody planned how data would be brought back together. Treating ownership as purely technical. Ownership is also organisational: someone must answer for the data's quality, and per Conway's law data boundaries that cut across team boundaries tend not to last.

A good test of any data design is to ask, for each important fact, three questions: who is the only writer, where are its rules enforced, and how stale may each copy be? If any answer is it depends or several services, the design is not finished.