Shared Database Pattern

The previous lesson made a strong case for Database per Service. It is the gold standard of microservices data architecture. But here is the thing: plenty of successful systems use shared databases, and they work fine.

Shopify runs one of the largest e-commerce platforms in the world on a sharded but shared MySQL database. They did not go database-per-service because the overhead of managing hundreds of databases, handling distributed transactions, and maintaining eventual consistency was not worth it for their use case. At their scale, they sharded by merchant (each merchant's data lives on one shard), but within a shard, multiple services share the same MySQL instance.

GitHub operated on a shared MySQL database for years. Basecamp still does. These are not small companies. They made a deliberate choice.

The Shared Database pattern means multiple services read from and write to the same database. It is widely considered an anti-pattern in microservices orthodoxy, but "anti-pattern" does not mean "never use it." It means "understand the trade-offs and use it deliberately, not accidentally."

The shared database gives you everything a monolith's database gives you: JOINs, transactions, immediate consistency. The cost is coupling and limited independent scaling.