Database per service pattern in Microservices - System Design Exercise

Design: Database per Service Pattern Implementation

Design focuses on the database per service pattern within a microservices architecture. It excludes detailed implementation of individual microservices business logic and UI design.

Functional Requirements

FR1: Each microservice must have its own dedicated database.

FR2: Services should be loosely coupled and independently deployable.

FR3: Data consistency should be maintained across services where needed.

FR4: Support for service-specific data models and storage technologies.

FR5: Allow services to evolve their database schema independently.

Non-Functional Requirements

NFR1: System should handle 10,000 concurrent users.

NFR2: API response latency p99 under 300ms.

NFR3: Availability target of 99.9% uptime.

NFR4: Data synchronization between services should tolerate eventual consistency.

NFR5: Databases must be isolated to prevent cross-service data leaks.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway

Individual Microservices

Dedicated Databases per Service

Service Communication Layer (REST/gRPC/Message Queue)

Event Bus or Message Broker for asynchronous updates

Service Registry and Discovery

Design Patterns

Database per Service Pattern

Event-Driven Architecture

Saga Pattern for distributed transactions

CQRS (Command Query Responsibility Segregation)

API Gateway Pattern

Reference Architecture

          +----------------+          +----------------+
          |  Microservice  |          |  Microservice  |
          |      A         |          |      B         |
          +-------+--------+          +-------+--------+
                  |                           |
          +-------v--------+          +-------v--------+
          |  Database A    |          |  Database B    |
          +----------------+          +----------------+
                  |                           |
                  +------------+--------------+
                               |
                       +-------v-------+
                       |  Message Bus  |
                       +---------------+
                               |
                       +-------v-------+
                       | API Gateway   |
                       +---------------+

Components

Microservice A

Any suitable language/framework

Handles specific business logic and owns Database A

Microservice B

Any suitable language/framework

Handles different business logic and owns Database B

Database A

Relational or NoSQL database

Stores data exclusively for Microservice A

Database B

Relational or NoSQL database

Stores data exclusively for Microservice B

Message Bus

Kafka, RabbitMQ, or similar

Enables asynchronous communication and event propagation between services

API Gateway

Nginx, Kong, or custom

Single entry point for clients, routes requests to appropriate microservices

Request Flow

1. Client sends request to API Gateway.

2. API Gateway routes request to the appropriate microservice.

3. Microservice processes request using its own database.

4. If data changes affect other services, microservice publishes event to Message Bus.

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

6. Microservices respond back to API Gateway, which returns response to client.

Database Schema

Each microservice has its own schema tailored to its domain. For example, Microservice A's database contains tables/entities related only to its business domain, isolated from Microservice B's schema. There are no shared tables or direct cross-service foreign keys.

Scaling Discussion

Bottlenecks

Cross-service data consistency delays due to asynchronous event propagation.

Increased complexity managing distributed transactions.

Message Bus becoming a single point of failure or bottleneck.

API Gateway overload under high traffic.

Database scaling limits for individual services.

Solutions

Implement Saga pattern to manage distributed transactions with compensating actions.

Use highly available and partitioned message brokers to handle load and failures.

Scale API Gateway horizontally with load balancers.

Use database sharding or read replicas for scaling individual service databases.

Design services to tolerate eventual consistency where possible to reduce tight coupling.

Interview Tips

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

Explain why each service needs its own database for loose coupling and independent deployment.

Discuss trade-offs between strong and eventual consistency.

Describe how asynchronous messaging helps maintain data synchronization.

Highlight patterns like Saga for distributed transactions.

Address scaling challenges and solutions clearly.