---
title: "The Hard Parts rule for data: whoever writes it owns it"
description: "Software Architecture: The Hard Parts has a short rule: the service that writes the data owns it, and services writing the same table aren't separate yet."
url: "https://michael.zazon.us/notes/the-hard-parts-rule-for-data-whoever-writes-it-owns-it"
published: "2026-06-21T12:00:00-04:00"
kind: "book-notes"
subject: "architecture"
tags: ["data"]
---
One question that keeps coming up for me is.. if you split up a shared database, how do you decide who owns which tables? [Software Architecture: The Hard Parts](https://www.oreilly.com/library/view/software-architecture-the/9781492086888/) by Neal Ford, Mark Richards, Pramod Sadalage, and Zhamak Dehghani (O'Reilly, 2021) spends a big part of the first half of the book talking about how to separate out data, and they have a pretty short answer to this question: [Dan Lebrero's notes on the book](https://danlebrero.com/2022/03/30/software-architecture-the-hard-parts-book-summary/) summarize it as "the service that performs writes owns the data."

The book classifies tables by the number of services that write to them. If there's only one service that writes to the table, that's single ownership, and that's the easy case.. the table should just go with that service. If there are lots of services that write to the table, that's common ownership, and you should fix it by making a dedicated service own the table and have all the other services access it through that. If there are a few services that write to the table, that's joint ownership, and you should either split up the table so that each service writes to its own part, share a data domain, delegate writes to one service, or merge the services.

This rule is important because of the architecture quantum.. the independently deployable unit. If you share a database, you have static coupling. All the services that write to the same tables are part of the same quantum, no matter what your deployment diagram says. I think it's ok to share a database instance to save costs, but sharing write access to the same tables is where you get into trouble. [Milan Milanović's review](https://newsletter.techworld-with-milan.com/p/what-i-learned-from-the-software) makes a similar point about the shared data domain pattern.. it can have good performance and fault tolerance, but ownership and security are difficult.

I think merging, the last option for joint ownership, doesn't get enough credit. It might seem like a regression in your decomposition plan, but if you have two services that need to change the same rows, merging them is often more honest than building a protocol between them (the book's definition already says they're one quantum). One last question: If consolidation is one of the fixes in the book, why don't we see it in decomposition plans more often?