🟢 Junior Level

Shared DB is an anti-pattern in microservices where multiple services use the same database.

❌ Order Service → Shared DB ← User Service
                ← Payment Service

Problems:

1. Coupling — schema changes (ALTER TABLE) can break other services that depend on the same table. Services cease to be independent.
2. Coordinated deployment — all services must be updated simultaneously
3. Locks — one service locks tables for others
4. No isolation — DB crash affects all services. While connection pool retry can mitigate short-lived failures, a prolonged DB outage = total system failure.

---

🟡 Middle Level

Detailed problems

// Two services map to the same table — renaming a column breaks both:
// UserService.java: @Column("email") — renamed to "email_address"
// OrderService.java: @Column("email") — broken!

1. Schema coupling:

User Service modified the users table
Order Service broke — expected the old schema

2. Performance:

Order Service runs a heavy query → locks tables
User Service waits → latency grows

3. Data ownership:

Who owns the users table?
User Service? Order Service?
Who is responsible for migrations?

Common mistakes

1. Legacy shared DB:

   Monolith was split into services, but the DB was left shared
   → got all the downsides of microservices without the benefits
   

---

🔴 Senior Level

Migration from Shared DB

Strangler pattern:

1. Create a new DB for each service
2. Dual write → write to both DBs
3. Switch reads to the new DB
4. Remove writes to the old DB
5. Delete the old DB

Best Practices

✅ Database per Service
✅ API for accessing other services' data
✅ Events for data replication

❌ Shared database between services
❌ Direct JOINs across tables of different services

---

🎯 Interview Cheat Sheet

Must know:

• Shared DB is an anti-pattern: one service’s schema change breaks others
• Schema coupling: ALTER TABLE can break dependent services
• Coordinated deployment — all services must update simultaneously
• Locks: one service’s heavy query locks tables for others
• No isolation: DB crash = total system crash
• Migration: Strangler pattern — dual write → switch reads → delete old DB
• Solution: Database per Service + API/events for data access

Frequent follow-up questions:

• How to migrate from Shared DB? Strangler pattern: create DB per service → dual write → switch reads → remove old DB.
• What is the dual write problem? If writing to the old system succeeds but writing to the new one fails, data becomes out of sync — solution: Outbox pattern or CDC.
• Who owns a table in Shared DB? Nobody — that’s the problem, no one is responsible for migrations.
• Can Shared DB be mitigated? Yes — separate schemas, but this is a compromise, not a solution.

Red flags (NOT to say):

• “Shared DB is a normal approach for microservices” — no, it’s an anti-pattern
• “Monolith was split, DB can stay shared” — no, you get downsides without upsides
• “JOINs across service tables is a good idea” — no, that’s coupling
• “Schema coupling is solved with documentation” — no, architectural isolation is needed

Related topics:

• [[13. What is Database per Service pattern]]
• [[24. What is Strangler Fig pattern]]
• [[3. How to implement distributed transactions in microservices]]
• [[1. What is Saga pattern and when to use it]]
• [[15. How to organize communication between microservices]]