Microservices That Share One Database

Services that read and write the same database tables are coupled through those tables, however separately they are deployed. A change to the schema can break any service that touches it, so every team must take part in it, and the independent deploys that justified microservices stop being independent.

The symptom. Five services, owned by five teams, deploy separately. Yet renaming one column takes a month: a meeting of all five teams, a shared release plan, and a weekend when everyone deploys together.

The trigger. The monolith was split into services along team lines, but its one database was kept, because splitting the data was harder than splitting the code.

The mechanism. Each service reads the orders table directly, so each depends on its exact columns. Renaming total to total_amount breaks every service that reads total the moment it changes. Nobody can change the table without everyone, and nobody knows for sure which services read which columns.

The cost. All the costs of microservices, network calls, many deploys, more to watch, and less of the benefit, because changes still need every team. A slow query from one service can also slow the database for all five.

The remedy. Give each table one owning service. Other services ask the owner through its interface, or keep their own copy updated from its events. Move tables one at a time, starting with those only one service writes. Work that spanned tables in one transaction becomes a saga, a series of steps across services, each with an undo, which the subject on resilient systems covers.

So if services share a database, they are not yet independent: give each piece of data one owner before counting on separate deploys.