Why each service owns its data in Microservices - Design It to Understand It

Design: Microservices Data Ownership

Focus on data ownership principles in microservices architecture. Out of scope: detailed implementation of each service's business logic.

Functional Requirements

FR1: Each microservice must manage its own data independently

FR2: Services should not directly access other services' databases

FR3: Data consistency should be maintained across services

FR4: Services must communicate through well-defined APIs

FR5: Support independent deployment and scaling of services

Non-Functional Requirements

NFR1: Handle up to 10,000 concurrent users

NFR2: API response latency p99 < 200ms

NFR3: Availability target 99.9% uptime

NFR4: Data consistency eventual or strong depending on use case

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway or Service Mesh

Individual service databases

Event bus or message queue for async communication

Service registry and discovery

Data replication or synchronization mechanisms

Design Patterns

Database per service pattern

Event-driven architecture

Saga pattern for distributed transactions

API composition

CQRS (Command Query Responsibility Segregation)

Reference Architecture

          +-------------------+          
          |   API Gateway     |          
          +---------+---------+          
                    |                    
    +---------------+---------------+    
    |                               |    
+---v---+                       +---v---+
|Service|                       |Service|
|  A    |                       |  B    |
+---+---+                       +---+---+
    |                               |    
+---v---+                       +---v---+
| DB A  |                       | DB B  |
+-------+                       +-------+

Services communicate via APIs or events, each owns its DB.

Components

Service A

Any backend framework (e.g., Node.js, Spring Boot)

Handles specific business domain and owns its data

Service B

Any backend framework

Handles another business domain and owns its data

Database A

Relational or NoSQL DB (e.g., PostgreSQL, MongoDB)

Stores data exclusively for Service A

Database B

Relational or NoSQL DB

Stores data exclusively for Service B

API Gateway

Nginx, Kong, or AWS API Gateway

Routes client requests to appropriate services

Message Queue/Event Bus

Kafka, RabbitMQ, or AWS SNS/SQS

Enables asynchronous communication and eventual consistency

Request Flow

1. Client sends request to API Gateway

2. API Gateway routes request to Service A

3. Service A processes request and updates its own database

4. If needed, Service A publishes event to message queue

5. Service B subscribes to events and updates its own database accordingly

6. Services never access each other's databases directly

7. Data consistency is maintained via events or API calls

Database Schema

Service A owns tables/entities related to its domain (e.g., Orders). Service B owns its own tables/entities (e.g., Customers). No shared tables. Relationships between data in different services are managed via service APIs or events.

Scaling Discussion

Bottlenecks

Tight coupling if services share databases

Data inconsistency due to asynchronous updates

Increased latency for cross-service data queries

Complexity in managing distributed transactions

Solutions

Enforce database per service to avoid coupling

Use event-driven architecture with reliable messaging

Implement Saga pattern for distributed transactions

Use API composition or CQRS for read operations needing data from multiple services

Interview Tips

Time: Spend 10 minutes explaining the concept and benefits, 15 minutes on architecture and data flow, 10 minutes on scaling challenges and solutions, 10 minutes for questions.

Explain why each service owning its data reduces coupling and improves scalability

Discuss how data consistency is maintained without direct DB sharing

Highlight communication patterns between services

Mention patterns like Saga and event-driven design

Show awareness of trade-offs and complexity introduced

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