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.

Practice

1. Why should each microservice own its own data instead of sharing a common database?

easy

A. To ensure services are independent and can evolve separately

B. To reduce the total amount of data stored in the system

C. To make it easier to write SQL queries across services

D. To allow all services to access data faster by sharing it

Solution

1. Step 1: Understand service independence

   Each microservice owning its data means it can change its database without affecting others.

2. Step 2: Recognize benefits of separate data ownership

   This independence improves scalability and reduces tight coupling between services.

3. Final Answer:

   To ensure services are independent and can evolve separately -> Option A

4. Quick Check:

   Service independence = D [OK]

Hint: Think about service independence and avoiding tight coupling [OK]

Common Mistakes:

• Assuming shared databases improve performance
• Believing data sharing reduces storage needs
• Thinking SQL queries are easier with shared data

2. Which of the following is the correct way for microservices to access data owned by another service?

easy

A. Directly querying the other service's database

B. Sharing a common database schema

C. Using APIs or messaging to request data

D. Copying the entire database locally

Solution

1. Step 1: Identify proper data access method

   Microservices should not access each other's databases directly to avoid tight coupling.

2. Step 2: Recognize communication via APIs or messages

   Services communicate data through APIs or messaging systems to maintain independence.

3. Final Answer:

   Using APIs or messaging to request data -> Option C

4. Quick Check:

   Data access via APIs/messages = B [OK]

Hint: Remember: no direct DB access, use APIs or messages [OK]

Common Mistakes:

• Trying to query another service's database directly
• Assuming shared schema is best practice
• Copying entire databases unnecessarily

3. Consider two microservices: Service A owns customer data, and Service B owns order data. Service B needs customer info to process orders. Which approach correctly respects data ownership?

medium

A. Service B queries Service A's database directly for customer info

B. Service B calls Service A's API to get customer info

C. Service B duplicates customer data in its own database

D. Service B uses a shared database for both customer and order data

Solution

1. Step 1: Identify correct data access respecting ownership

   Service B should not access Service A's database directly or share databases.

2. Step 2: Use API calls for data retrieval

   Calling Service A's API allows Service B to get needed data without breaking ownership rules.

3. Final Answer:

   Service B calls Service A's API to get customer info -> Option B

4. Quick Check:

   API calls respect ownership = A [OK]

Hint: Use APIs to get data from other services, not direct DB access [OK]

Common Mistakes:

• Direct DB queries across services
• Duplicating data causing inconsistency
• Using shared databases breaking independence

4. A team notices that two microservices share a database schema and directly query each other's tables. What is the main problem with this design?

medium

A. It causes tight coupling and reduces service independence

B. It improves scalability by sharing data

C. It simplifies API design between services

D. It reduces the need for data synchronization

Solution

1. Step 1: Analyze impact of shared database schema

   Sharing schema and direct queries create tight coupling between services.

2. Step 2: Understand consequences on independence

   Tight coupling reduces the ability to change or scale services independently.

3. Final Answer:

   It causes tight coupling and reduces service independence -> Option A

4. Quick Check:

   Tight coupling problem = C [OK]

Hint: Shared DB means tight coupling, which is bad for microservices [OK]

Common Mistakes:

• Thinking shared DB improves scalability
• Assuming it simplifies API design
• Believing it removes sync needs

5. You are designing a microservices system with three services: User, Inventory, and Order. Each service owns its data. How should you handle a scenario where the Order service needs to confirm inventory availability before placing an order?

hard

A. All services share a single database to simplify data access

B. Order service queries Inventory service's database directly to check stock

C. Order service duplicates inventory data locally and updates it periodically

D. Order service calls Inventory service's API to check stock availability

Solution

1. Step 1: Respect data ownership in design

   Each service must own and manage its own data; direct DB queries or shared DB break this.

2. Step 2: Use API calls for inter-service communication

   Order service should call Inventory service's API to get real-time stock info, ensuring data consistency and independence.

3. Final Answer:

   Order service calls Inventory service's API to check stock availability -> Option D

4. Quick Check:

   API communication respects ownership = A [OK]

Hint: Always use APIs for cross-service data, never direct DB access [OK]

Common Mistakes:

• Direct DB queries breaking independence
• Duplicating data causing stale info
• Using shared DB increasing coupling