Identifying service boundaries in Microservices - System Design Exercise

Design: Microservices Service Boundary Identification

Focus on identifying and defining service boundaries and their interactions. Out of scope: detailed implementation of each microservice, infrastructure setup, and deployment pipelines.

Functional Requirements

FR1: Decompose a monolithic application into multiple microservices

FR2: Each microservice should own a distinct business capability

FR3: Services should have clear, minimal dependencies on each other

FR4: Support independent deployment and scaling of services

FR5: Ensure data consistency within each service boundary

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: Services must communicate asynchronously where possible

NFR5: Data duplication across services should be minimized

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Domain-driven design concepts (bounded contexts)

API gateways or service mesh for communication

Event-driven messaging systems

Databases owned per service

Service registry and discovery

Design Patterns

Bounded Context pattern

Database per service pattern

Event sourcing and CQRS

API Gateway pattern

Saga pattern for distributed transactions

Reference Architecture

                +---------------------+
                |     API Gateway      |
                +----------+----------+
                           |
      +--------------------+--------------------+
      |                    |                    |
+-----v-----+        +-----v-----+        +-----v-----+
| User      |        | Order     |        | Inventory |
| Service   |        | Service   |        | Service   |
+-----------+        +-----------+        +-----------+
      |                    |                    |
+-----v-----+        +-----v-----+        +-----v-----+
| User DB   |        | Order DB  |        | Inventory |
|           |        |           |        | DB        |
+-----------+        +-----------+        +-----------+

Services communicate asynchronously via events for eventual consistency.

Components

API Gateway

Nginx or Kong

Single entry point routing requests to appropriate microservices

User Service

Spring Boot / Node.js

Manages user profiles and authentication

Order Service

Spring Boot / Node.js

Handles order creation, updates, and status

Inventory Service

Spring Boot / Node.js

Manages product stock levels and availability

Databases

PostgreSQL per service

Each service owns its own database to ensure data encapsulation

Event Bus

Apache Kafka or RabbitMQ

Enables asynchronous communication and event-driven updates between services

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 needed, microservice publishes events to Event Bus

5. Other services subscribe to relevant events and update their state asynchronously

6. Microservice returns response to API Gateway

7. API Gateway sends response back to client

Database Schema

User Service: User(id PK, name, email, password_hash) Order Service: Order(id PK, user_id FK, status, total_amount) Inventory Service: Product(id PK, name, stock_quantity) Relationships: User Service owns user data; Order Service references user_id but does not modify User data; Inventory Service owns product stock data. No shared databases; communication via events.

Scaling Discussion

Bottlenecks

API Gateway becoming a single point of failure under high load

Database contention within a single service as user base grows

Tight coupling causing cascading failures between services

Event bus overload with high event volume

Data consistency challenges across services

Solutions

Deploy multiple API Gateway instances behind a load balancer

Use database sharding or read replicas per service

Design services with clear boundaries and fallback mechanisms

Partition event topics and scale event bus clusters horizontally

Implement eventual consistency with compensating transactions and sagas

Interview Tips

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

Explain how you identify bounded contexts from business domains

Discuss importance of data ownership per service

Highlight asynchronous communication benefits and challenges

Mention patterns like Saga for distributed transactions

Address scaling bottlenecks and mitigation strategies