Shared database anti-pattern in Microservices - System Design Guide

Problem Statement

When multiple microservices directly access the same database schema, changes by one service can break others unexpectedly. This tight coupling causes deployment delays, data corruption risks, and limits independent scaling and evolution of services.

Solution

Each microservice should own its own database or schema, accessing data only through well-defined APIs. This isolates data changes, allowing services to evolve independently and reducing the risk of cascading failures.

Architecture

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Microservice A│──────▶│ Shared DB     │◀──────│ Microservice B│
└───────────────┘       └───────────────┘       └───────────────┘

This diagram shows two microservices directly accessing the same shared database, illustrating tight coupling and shared data risks.

Trade-offs

✓ Pros

→

Simplifies initial development by avoiding data duplication.

→

Ensures strong consistency since all services read/write the same data source.

→

Reduces infrastructure overhead by maintaining a single database.

✗ Cons

→

Tight coupling between services reduces independent deployability.

→

Schema changes require coordination across teams, slowing development.

→

Increased risk of data corruption and cascading failures.

→

Limits ability to scale services independently.

Only suitable for very small systems with minimal service count and low change frequency, typically under 10 services and low traffic.

Avoid when services need independent deployment, scaling, or when the system grows beyond a few tightly coupled components.

Real World Examples

Amazon

Early Amazon architecture used shared databases causing deployment bottlenecks; they moved to service-owned databases to enable rapid independent deployments.

Netflix

Netflix avoided shared databases to allow each microservice to scale and evolve independently, improving fault isolation.

Uber

Uber transitioned from shared databases to service-specific data stores to handle rapid feature development and scaling.

Alternatives

Database per service

Each microservice owns its own database, accessed only via service APIs, avoiding direct data sharing.

Use when: When independent service deployment, scaling, and evolution are priorities.

Event-driven data replication

Services maintain local copies of data updated asynchronously via events, reducing coupling.

Use when: When eventual consistency is acceptable and services need local data for performance.

Summary

Sharing a database among microservices creates tight coupling that hinders independent deployment and scaling.

Owning separate databases per service isolates changes and improves fault tolerance.

Avoid shared databases except in very small, simple systems with minimal change.