Shared database anti-pattern in Microservices - Scalability & System Analysis

Scalability Analysis - Shared database anti-pattern

Growth Table: Shared Database Anti-Pattern

Users	What Changes
100 users	Single database handles all microservices; low contention; simple coordination.
10,000 users	Database load increases; contention on shared tables; slower transactions; microservices tightly coupled.
1,000,000 users	Database becomes bottleneck; high latency; schema changes affect multiple services; difficult to deploy independently.
100,000,000 users	Database overloads; scaling vertically is costly; outages impact all services; no isolation; very hard to maintain and evolve.

First Bottleneck

The shared database is the first bottleneck. As all microservices read and write to the same database, contention and locking increase. This causes slow queries and blocks other services. Schema changes become risky because they affect all services, reducing agility.

Scaling Solutions

• Database per service: Each microservice owns its own database to reduce contention and coupling.
• API communication: Services communicate via APIs instead of sharing data directly.
• Event-driven architecture: Use events to sync data asynchronously between services.
• Read replicas and caching: For read-heavy workloads, use replicas and caches to reduce load.
• Data partitioning: Split data by service domain to isolate workloads.

Back-of-Envelope Cost Analysis

Assuming 1 million users generate 10,000 requests per second total:

• Database QPS needed: ~10,000 QPS (likely exceeds single DB capacity).
• Storage: Shared DB grows fast, schema changes affect all services, increasing maintenance cost.
• Bandwidth: Internal network traffic increases due to contention and locking delays.
• Scaling vertically (bigger DB server) becomes expensive and hits limits quickly.

Interview Tip

Start by explaining the shared database anti-pattern and why it causes tight coupling and scaling issues. Then discuss how the database becomes a bottleneck as traffic grows. Finally, propose solutions like database per service and asynchronous communication to improve scalability and independence.

Self Check

Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?

Answer: The first step is to decouple microservices by giving each its own database to reduce contention. Then introduce caching and read replicas to handle read load. This prevents the shared database from becoming a bottleneck.

Key Result

A shared database causes tight coupling and contention among microservices, becoming the first bottleneck as traffic grows. Decoupling databases per service and asynchronous communication are key to scaling.