Shared Database Anti-Pattern Lab (Interactive)
Scale pods against one Postgres max_connections limit and watch greedy pools starve the services that arrive second. Several microservices share one database: connection pools multiply by pod count, greedy allocation starves latecomers, and any schema change can crash-loop every other service.
Shared Database Starvation Cascade
Twenty “microservices”, one PostgreSQL instance. Scale one service or run one migration and starve everyone else.
How It Works Under the Hood
The shared database is the most common fake microservice architecture: services look independent in code but fuse at the schema. Two failure modes emerge mechanically. First, connection exhaustion — 20 Order pods with 10-connection pools consume 200 of a Postgres max_connections budget, so a burst or a greedy service starves Billing and Catalog of every remaining slot. Second, schema coupling — a Beta team dropping a column that the legacy dashboard reads crash-loops unrelated services. Availability multiplication across consumers of one database plus deployment serialization is the tax this anti-pattern always collects.
Core Architectural Principles
- Demand = pods × pool size per service, greedily allocated against one fixed max_connections cap.
- A 10× traffic burst re-runs allocation and starves lower-priority services of database connections.
- The ALTER TABLE DROP COLUMN control shows schema coupling: one migration breaks every dependent service.
Interviewers probe shared-database designs specifically to see if you catch it. Say: "Two services with foreign keys across their tables is one deployment unit with extra steps." Then quantify — pods times pool size against max_connections — and propose the fix ladder: schema isolation first, API-mediated reads, then database-per-service with eventual consistency.
One database is cheap and transactionally simple, but it multiplies availability, serializes deploys, and couples every failure domain.