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