Shared database anti-pattern in Microservices - Deep Dive

Overview - Shared database anti-pattern

What is it?

The shared database anti-pattern happens when multiple microservices use the same database to store and read data. Instead of each service managing its own data, they all connect to one common database. This creates tight links between services, making them less independent and harder to change. It looks like sharing one big notebook where everyone writes and reads, instead of each having their own.

Why it matters

This anti-pattern causes problems like services breaking each other by accident, making updates risky and slow. Without clear boundaries, teams can't work independently, slowing down development and causing bugs. If this pattern was everywhere, microservices would lose their main benefit: being small, independent, and easy to change.

Where it fits

Before learning this, you should understand what microservices are and why independence matters. After this, you can learn about better ways to share data between services, like APIs or event-driven communication.

Mental Model

Core Idea

Sharing one database among microservices creates hidden links that break their independence and cause tight coupling.

Think of it like...

It's like several roommates sharing one diary to write their own stories instead of each having their own notebook. When one changes a page, it can confuse or erase another's story.

┌───────────────┐
│ Shared       │
│ Database     │
├───────────────┤
│ Service A    │
│ Service B    │
│ Service C    │
└───────────────┘
All services read and write here, causing overlap and confusion.

Build-Up - 6 Steps

1

Foundation

What is a microservice architecture

Concept: Microservices are small, independent services that work together to form a bigger system.

Imagine a big company split into small teams. Each team handles a specific job and has its own tools and rules. Microservices work the same way: each service does one thing well and can change without affecting others.

Result

You understand that microservices aim for independence and clear boundaries.

Knowing microservices are about independence helps see why sharing a database can cause problems.

2

Foundation

Role of databases in microservices

Concept: Each microservice should own its data and database to keep independence.

If each team has its own notebook, they can write freely without worrying about others. Similarly, each microservice having its own database means it controls its data and changes safely.

Result

You see why separate databases support service independence.

Understanding data ownership is key to designing scalable and maintainable microservices.

3

Intermediate

What is the shared database anti-pattern

🤔Before reading on: do you think sharing one database helps or hurts microservice independence? Commit to your answer.

Concept: Sharing one database among microservices creates hidden dependencies and tight coupling.

When multiple services use the same database, they depend on the same tables and schemas. Changes by one service can break others. This reduces the ability to deploy or update services independently.

Result

You recognize that shared databases cause tight coupling and risk.

Knowing this anti-pattern helps avoid a common trap that undermines microservice benefits.

4

Intermediate

Problems caused by shared databases

🤔Before reading on: do you think shared databases make deployment easier or more risky? Commit to your answer.

Concept: Shared databases increase risk of breaking changes, reduce team autonomy, and complicate scaling.

If one service changes a table structure, all others must adapt immediately. Teams must coordinate tightly, slowing development. Also, scaling one service independently is harder because the database is a shared bottleneck.

Result

You understand the practical risks and delays caused by shared databases.

Recognizing these problems explains why teams avoid this anti-pattern in real projects.

5

Advanced

Alternatives to shared databases

🤔Before reading on: do you think services should share data by direct database access or through APIs/events? Commit to your answer.

Concept: Microservices should share data via APIs or events, not by sharing databases.

Instead of sharing a database, services communicate by sending messages or calling APIs. Each service keeps its own database and exposes only what others need. This keeps services independent and reduces risk.

Result

You learn better ways to share data that keep microservices decoupled.

Understanding alternatives helps design systems that scale and evolve safely.

6

Expert

Hidden coupling in shared databases

🤔Before reading on: do you think coupling only happens in code, or can it happen in data too? Commit to your answer.

Concept: Shared databases create hidden coupling through data schemas and transactions, even if code is separate.

Even if services have separate codebases, sharing tables means they depend on the same data structure. Changing a column or constraint affects all services. Also, distributed transactions across services become complex and fragile.

Result

You realize coupling can be invisible and hard to detect in shared databases.

Knowing hidden coupling helps avoid subtle bugs and design truly independent services.

Under the Hood

When microservices share a database, they access the same tables and data structures. This means schema changes by one service affect all others. Transactions may span multiple services, causing complex locking and failures. The database becomes a central point of failure and coordination, reducing service autonomy.

Why designed this way?

Early microservice attempts reused existing databases to save time and cost. It seemed easier to share data directly than build APIs. However, this shortcut ignored the core microservice principle of independence, leading to tight coupling and maintenance headaches.

┌───────────────┐       ┌───────────────┐
│ Service A    │──────▶│ Shared       │
│ Code & Logic │       │ Database     │
└───────────────┘       ├───────────────┤
┌───────────────┐       │ Tables &     │
│ Service B    │──────▶│ Schemas      │
│ Code & Logic │       └───────────────┘
└───────────────┘       ┌───────────────┐
                        │ Service C    │
                        │ Code & Logic │
                        └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does sharing a database always improve performance? Commit yes or no.

Common Belief: Sharing one database makes data access faster and simpler for all services.

Reality: Shared databases often cause bottlenecks and slow down services due to contention and complex coordination.

Why it matters: Believing this leads to performance problems and scaling failures in production.

Quick: Can microservices be independent if they share a database? Commit yes or no.

Common Belief: Microservices can still be independent even if they use the same database.

Reality: Sharing a database creates hidden dependencies that break true independence and agility.

Why it matters:

Quick: Is it safe to change database schema if only one service uses that part? Commit yes or no.

Common Belief: If only one service uses a table, it can change the schema without affecting others.

Reality: Other services might still rely indirectly on that schema, causing unexpected failures.

Why it matters: Ignoring this leads to subtle bugs and downtime during schema changes.

Quick: Does using APIs for data sharing always add more complexity than shared databases? Commit yes or no.

Common Belief: Using APIs to share data is more complex and slower than sharing a database.

Reality: APIs add clear boundaries and reduce coupling, making systems easier to maintain and scale despite some overhead.

Why it matters: Avoiding APIs due to perceived complexity traps teams in fragile shared database designs.

Expert Zone

1

Schema versioning becomes a hidden challenge when multiple services share a database, requiring careful coordination.

2

Distributed transactions across services sharing a database often lead to performance bottlenecks and failure cascades.

3

Even read-only shared tables can cause coupling if services rely on the same data format and update timing.

When NOT to use

Avoid shared databases when building microservices that require independent deployment and scaling. Instead, use database-per-service with API or event-driven communication. Shared databases might be acceptable in legacy monoliths or tightly coupled systems where independence is not a priority.

Production Patterns

In real systems, teams migrate from shared databases to separate ones by introducing APIs and event streams. They use database replication or change data capture to sync data safely. Some use shared read-only replicas for reporting but keep write operations isolated.

Connections

Event-driven architecture

Builds-on

Understanding event-driven communication helps replace shared databases with asynchronous, decoupled data sharing.

Modular programming

Similar pattern

Both emphasize clear boundaries and independence to reduce hidden dependencies and improve maintainability.

Organizational behavior

Analogy in team autonomy

Just like teams need clear roles and separate responsibilities to avoid conflicts, microservices need separate data ownership to avoid tight coupling.

Common Pitfalls

#1 Multiple services directly modify the same database tables without coordination.

Wrong approach:

Service A and Service B both run ALTER TABLE commands independently, causing conflicts and downtime.

Correct approach:

Each service owns its tables and exposes data changes via APIs or events; schema changes are coordinated through versioning and backward compatibility.

Root cause:

Misunderstanding that database schema is a shared contract requiring coordination.

#2 Assuming shared database means services can be deployed independently.

Wrong approach:

Deploying Service A with a schema change without updating Service B, causing runtime errors.

Correct approach:

Deploy services with backward-compatible changes and coordinate deployments or decouple databases entirely.

Root cause:

Ignoring hidden coupling through shared data structures.

#3 Using shared database for scaling without isolating workloads.

Wrong approach:

All services connect to one database instance causing contention and slow queries.

Correct approach:

Each service uses its own database optimized for its workload; shared data is synchronized asynchronously if needed.

Root cause:

Treating database as a simple shared resource rather than a service boundary.

Key Takeaways

Sharing a database among microservices creates hidden dependencies that break their independence and agility.

True microservice design requires each service to own its data and communicate through APIs or events.

Shared databases cause coordination overhead, deployment risks, and scaling bottlenecks.

Avoiding this anti-pattern leads to more maintainable, scalable, and resilient systems.

Understanding hidden coupling in data helps design better boundaries beyond just code separation.

Practice

1. What is the main problem caused by the shared database anti-pattern in microservices?

easy

A. Better fault isolation between services

B. Tight coupling between services due to shared data schema

C. Easier scaling of individual services

D. Improved performance by sharing data directly

Solution

1. Step 1: Understand the shared database anti-pattern

   This anti-pattern happens when multiple microservices use the same database schema directly.

2. Step 2: Identify the impact on service independence

   Sharing the database causes tight coupling, making services dependent on each other's data structure changes.

3. Final Answer:

   Tight coupling between services due to shared data schema -> Option B

4. Quick Check:

   Shared database = Tight coupling [OK]

Hint: Shared DB means tight coupling, breaking microservices independence [OK]

Common Mistakes:

• Thinking shared DB improves scaling
• Assuming shared DB isolates faults
• Believing shared DB simplifies service design

2. Which of the following is the correct way to avoid the shared database anti-pattern in microservices?

easy

A. Use a single database schema shared by all services

B. Store all data in a centralized monolithic database

C. Allow direct SQL queries from one service to another's database

D. Each service owns its own database and communicates via APIs

Solution

1. Step 1: Recall best practice for microservice data management

   Each microservice should have its own database to maintain independence.

2. Step 2: Identify the correct communication method

   Services communicate through APIs, not by sharing databases or direct queries.

3. Final Answer:

   Each service owns its own database and communicates via APIs -> Option D

4. Quick Check:

   Separate DB + APIs = Avoid shared DB anti-pattern [OK]

Hint: Separate DB per service + API calls avoid shared DB anti-pattern [OK]

Common Mistakes:

• Choosing shared schema for simplicity
• Allowing direct cross-service DB queries
• Centralizing all data in one DB

3. Consider two microservices, Service A and Service B, sharing the same database. Service A changes a table schema without informing Service B. What is the most likely outcome?

medium

A. Service B automatically adapts to the new schema

B. Service B continues working without issues

C. Service B experiences runtime errors due to schema mismatch

D. Both services improve performance

Solution

1. Step 1: Analyze the impact of schema change on shared DB

   When services share a database, schema changes affect all services using it.

2. Step 2: Predict Service B's behavior

   Service B expects the old schema; a change causes runtime errors like failed queries or crashes.

3. Final Answer:

   Service B experiences runtime errors due to schema mismatch -> Option C

4. Quick Check:

   Schema change + shared DB = runtime errors [OK]

Hint: Schema change in shared DB breaks other services [OK]

Common Mistakes:

• Assuming automatic schema adaptation
• Believing no impact on other services
• Thinking performance improves

4. You find that two microservices share a database causing tight coupling and deployment issues. Which change fixes this problem?

medium

A. Create separate databases and add API communication

B. Merge the two services into one monolith

C. Add more indexes to the shared database

D. Allow both services to write to the same tables

Solution

1. Step 1: Identify the root cause of tight coupling

   Sharing the same database schema causes deployment and coupling problems.

2. Step 2: Apply the correct fix

   Separating databases and using APIs decouples services and allows independent deployment.

3. Final Answer:

   Create separate databases and add API communication -> Option A

4. Quick Check:

   Separate DB + APIs fix shared DB anti-pattern [OK]

Hint: Separate DB + APIs fix tight coupling from shared DB [OK]

Common Mistakes:

• Merging services loses microservice benefits
• Adding indexes doesn't fix coupling
• Allowing shared writes keeps tight coupling

5. A company has three microservices sharing one database. They want to migrate to avoid the shared database anti-pattern. Which approach best balances data consistency and service independence?

hard

A. Split databases per service and use event-driven messaging for data sync

B. Keep shared database but add strict schema versioning

C. Merge all services into a single database schema with shared tables

D. Use direct SQL queries between services to keep data consistent

Solution

1. Step 1: Understand the trade-offs in migration

   Separating databases improves independence but can cause data consistency challenges.

2. Step 2: Choose a pattern that balances consistency and independence

   Event-driven messaging allows services to sync data asynchronously while keeping separate databases.

3. Final Answer:

   Split databases per service and use event-driven messaging for data sync -> Option A

4. Quick Check:

   Separate DB + events balance consistency and independence [OK]

Hint: Use separate DB + events for sync to avoid shared DB anti-pattern [OK]

Common Mistakes:

• Keeping shared DB limits independence
• Merging services loses microservice benefits
• Using direct SQL breaks service boundaries