Why each service owns its data in Microservices - Scalability Evidence

Scalability Analysis - Why each service owns its data

Growth Table: Data Ownership in Microservices

Users	Data Management	Service Independence	Data Conflicts	Scaling Complexity
100 users	Single shared database possible	Low, services tightly coupled	Minimal conflicts	Simple scaling
10,000 users	Services start owning own databases	Moderate independence, some duplication	Conflicts start appearing	Moderate complexity
1,000,000 users	Each service owns its data fully	High independence, clear boundaries	Conflicts minimized by design	High complexity, requires automation
100,000,000 users	Data ownership critical for scaling	Complete autonomy, polyglot persistence	Conflicts handled asynchronously	Very high complexity, advanced tooling

First Bottleneck: Shared Database Coupling

When multiple services share the same database, the database becomes the first bottleneck as user count grows. This causes tight coupling, making it hard to scale services independently. Data conflicts and schema changes affect all services, slowing development and deployment.

Scaling Solutions: Service Data Ownership

• Database per service: Each service manages its own database to isolate data and reduce coupling.
• API contracts: Services communicate via APIs, not shared databases, ensuring clear boundaries.
• Event-driven data sync: Use events to synchronize data asynchronously between services.
• Polyglot persistence: Services choose the best database type for their data needs.
• Automated deployment: Independent data ownership enables independent service deployment and scaling.

Back-of-Envelope Cost Analysis

Assuming 1 million users with 10 requests per user per day:

• Requests per second: ~115 (1,000,000 users * 10 requests / 86400 seconds)
• Database load per service: Reduced by isolating data, each handles only relevant queries.
• Storage: Distributed across services, allowing tailored storage solutions.
• Network bandwidth: Increased inter-service communication but manageable with efficient APIs.

Interview Tip: Structuring Scalability Discussion

Start by explaining the problem of shared databases causing coupling and bottlenecks. Then describe how owning data per service improves independence and scalability. Discuss trade-offs like data duplication and eventual consistency. Finally, mention practical solutions like event-driven sync and polyglot persistence.

Self Check Question

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

Answer: Split the shared database into multiple databases owned by individual services to reduce coupling and distribute load, enabling independent scaling.

Key Result

Owning data per service prevents database bottlenecks and tight coupling, enabling independent scaling and faster development as user count grows.