What is the Shared Database Anti-Pattern?
Understand the shared database anti-pattern: why letting services share tables recreates coupling, and how database-per-service fixes it.
Expected Interview Answer
The shared database anti-pattern occurs when multiple independently deployed services read and write the same database tables, recreating tight coupling at the data layer that undermines the independence microservices are meant to provide.
It commonly emerges when a team splits a monolith into services but leaves everything pointed at the original single database for convenience, or when a new service is built quickly and just reuses an existing database rather than being given its own. The problem is that a schema change made by one service, renaming a column, adding a constraint, or altering a data type, can silently break every other service reading or writing that same table, since none of them can safely evolve their portion of the schema in isolation. This forces coordinated deployments across supposedly independent services, defeats the purpose of splitting a monolith apart, and often causes lock contention or performance interference between services with very different workload patterns hitting the same tables. The fix is the database-per-service pattern: give each service exclusive ownership of its own data and require all cross-service access to go through APIs instead of direct queries.
AI Mentor Explanation
The shared database anti-pattern is like every franchise in a league writing directly into one shared master scorebook instead of each keeping its own records. If one franchise’s scorer changes the column meaning for “runs” to include extras differently, every other franchise’s reports relying on that same book silently break without warning. No franchise can safely reorganize its own record-keeping because everyone else depends on the exact same shared structure. That fragile, tightly-coupled shared record is exactly the trap the shared database anti-pattern creates between services.
Step-by-Step Explanation
Step 1
Recognize the symptom
Multiple independently deployed services read and/or write the same tables in a single shared database instance.
Step 2
Trace the coupling
A schema change by one service (renamed column, new constraint, changed type) breaks other services querying the same table.
Step 3
Observe coordinated-deployment pressure
Teams must synchronize releases because schema changes cannot be made safely in isolation, defeating microservice independence.
Step 4
Migrate toward database-per-service
Carve out ownership per service, expose data through APIs, and stop direct cross-service table access.
What Interviewer Expects
- Identifies the shared database as an anti-pattern that recreates monolithic coupling at the data layer
- Explains the concrete failure mode: a schema change by one service silently breaking another
- Names database-per-service (with APIs for cross-service access) as the fix
- Mentions performance interference (lock contention) from unrelated workloads hitting shared tables
Common Mistakes
- Assuming a shared database is fine as long as each service only touches its own tables (schema-level isolation still allows accidental coupling and does not solve deployment coordination or workload interference)
- Not identifying it as an anti-pattern at all, treating it as a normal or acceptable microservices setup
- Failing to mention the fix (database-per-service, APIs for cross-service access)
- Ignoring the operational cost: coordinated migrations and releases across teams sharing one database
Best Answer (HR Friendly)
“The shared database anti-pattern is when several independent services all read and write the same database directly. It sounds convenient at first, but it means any team can accidentally break another team’s service just by changing a column or a table, so everyone ends up having to coordinate deployments, which defeats the whole point of having independent services. The fix is to give each service its own database and have other services go through its API instead of querying its tables directly.”
Code Example
# ANTI-PATTERN: three services sharing one database instance
services:
order-service:
database: shared-postgres # same instance
inventory-service:
database: shared-postgres # same instance, same tables
shipping-service:
database: shared-postgres # same instance, same tables
# FIX: database-per-service, cross-service access only via API
services:
order-service:
database: orders-db
exposesApi: /api/orders
inventory-service:
database: inventory-db
exposesApi: /api/inventory
shipping-service:
database: shipping-db
exposesApi: /api/shipping
# order-service now calls GET /api/inventory instead of
# querying the inventory tables directlyFollow-up Questions
- How would you migrate services off a shared database without downtime?
- What is the difference between a shared database and a shared read replica used only for reporting?
- How does the shared database anti-pattern relate to the database-per-service pattern as its fix?
- What early warning signs in a codebase suggest a team is drifting into this anti-pattern?
MCQ Practice
1. What is the core problem with the shared database anti-pattern?
When multiple services share a database, schema changes are no longer isolated, breaking the independence microservices are meant to provide.
2. What is the standard fix for the shared database anti-pattern?
The database-per-service pattern fixes this by giving each service exclusive data ownership and requiring APIs for any cross-service data access.
3. Besides broken schema changes, what other operational issue can a shared database cause?
Unrelated services hitting the same tables can cause lock contention and performance interference, since their workload patterns and query loads differ.
Flash Cards
What is the shared database anti-pattern? — Multiple independently deployed services reading/writing the same database tables directly.
Main failure mode it causes? — A schema change by one service silently breaks other services querying the same table.
What does it force teams to do? — Coordinate deployments across services, defeating the purpose of independent microservices.
What is the standard fix? — Database-per-service: each service owns its data exclusively; others access it only through APIs.