Database decomposition strategy in Microservices - System Design Exercise

Design: Database Decomposition Strategy for Microservices

Focus on strategies to split a monolithic database into multiple databases owned by microservices. Out of scope: detailed microservice business logic, UI design, or deployment infrastructure.

Functional Requirements

FR1: Support multiple microservices each owning its own data

FR2: Ensure data consistency within each microservice

FR3: Allow microservices to evolve independently

FR4: Enable efficient querying within each microservice

FR5: Support communication between microservices for cross-service data needs

Non-Functional Requirements

NFR1: Handle up to 10,000 concurrent requests across services

NFR2: API response latency p99 under 300ms

NFR3: Availability target of 99.9% uptime

NFR4: Data consistency within a microservice must be strong; eventual consistency allowed across services

NFR5: Data storage must be scalable and maintainable

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Service-specific databases

API gateways or service mesh for communication

Event-driven messaging or asynchronous communication

Data replication or caching for cross-service queries

Database per service pattern

Design Patterns

Database per service

Shared database anti-pattern

Event sourcing and CQRS for cross-service data

Saga pattern for distributed transactions

API composition for aggregating data

Reference Architecture

                +---------------------+
                |   API Gateway       |
                +----------+----------+
                           |
        +------------------+------------------+
        |                                     |
+-------v-------+                     +-------v-------+
| User Service  |                     | Order Service |
| +-----------+|                     | +-----------+|
| | User DB   ||                     | | Order DB  ||
| +-----------+|                     | +-----------+|
+---------------+                   +---------------+
        |                                     |
        +------------------+------------------+
                           |
                +----------v----------+
                | Event Bus / Message  |
                | Queue               |
                +---------------------+

Components

API Gateway

Nginx or Kong

Route client requests to appropriate microservices

User Service

Node.js/Java/Spring Boot

Handles user-related business logic and owns User database

Order Service

Node.js/Java/Spring Boot

Handles order-related business logic and owns Order database

User DB

PostgreSQL or MongoDB

Stores user data, owned exclusively by User Service

Order DB

PostgreSQL or MongoDB

Stores order data, owned exclusively by Order Service

Event Bus / Message Queue

Kafka or RabbitMQ

Facilitates asynchronous communication and eventual consistency between services

Request Flow

1. Client sends request to API Gateway

2. API Gateway routes request to appropriate microservice

3. Microservice processes request using its own database

4. If data needed by another service, microservice publishes event to Event Bus

5. Other microservices subscribe to relevant events and update their own data or caches

6. Microservices respond back to API Gateway

7. API Gateway sends response to client

Database Schema

Entities are split by service ownership. For example, User Service owns User entity with attributes like user_id, name, email. Order Service owns Order entity with order_id, user_id (foreign key reference by ID only, not enforced by DB), product details, status. No shared tables. Relationships across services handled via events and IDs.

Scaling Discussion

Bottlenecks

Single database per service can become a bottleneck under heavy load

Cross-service data queries can be slow or inconsistent

Distributed transactions are complex and can reduce performance

Eventual consistency may cause stale data issues

Message queue can become a bottleneck if overloaded

Solutions

Scale databases vertically or horizontally (read replicas, sharding) per service

Use caching and CQRS pattern to optimize cross-service queries

Implement Saga pattern to manage distributed transactions reliably

Design services to tolerate eventual consistency and provide user feedback

Scale message queue cluster and partition topics to handle load

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying scope, 20 minutes designing the decomposition strategy and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain importance of bounded contexts and service ownership of data

Discuss pros and cons of database per service pattern

Highlight how asynchronous communication supports eventual consistency

Mention challenges of distributed transactions and solutions like Saga

Show awareness of scaling bottlenecks and mitigation strategies