Bounded context mapping in Microservices - System Design Exercise

Design: Bounded Context Mapping for Microservices

Focus on designing the bounded context boundaries, communication patterns, and data ownership. Out of scope: detailed implementation of each microservice business logic.

Functional Requirements

FR1: Identify clear boundaries between different business domains in a microservices architecture

FR2: Define how different bounded contexts communicate and share data

FR3: Support independent development and deployment of services

FR4: Ensure data consistency within each bounded context

FR5: Handle integration between contexts with minimal coupling

Non-Functional Requirements

NFR1: System must support up to 100 microservices

NFR2: Latency for inter-service communication should be under 100ms p99

NFR3: Availability target of 99.9% uptime for critical services

NFR4: Data consistency within bounded contexts must be strong; eventual consistency allowed across contexts

NFR5: Scalable to handle 10,000 concurrent users

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway or Service Mesh for routing and communication

Event Bus or Message Broker for asynchronous integration

Databases owned by each bounded context

Domain Models encapsulated within each context

Anti-Corruption Layers to translate between contexts

Design Patterns

Domain-Driven Design (DDD) for defining bounded contexts

Event-Driven Architecture for integration

Saga Pattern for distributed transactions

API Composition for query aggregation

Anti-Corruption Layer to isolate contexts

Reference Architecture

  +----------------+       +----------------+       +----------------+
  |  Bounded       |       |  Bounded       |       |  Bounded       |
  |  Context A     |       |  Context B     |       |  Context C     |
  |  (Microservice)|       |  (Microservice)|       |  (Microservice)|
  +-------+--------+       +-------+--------+       +-------+--------+
          |                        |                        |
          | REST/gRPC              | Event Bus (Kafka)      | REST/gRPC
          |                        |                        |
  +-------v--------+       +-------v--------+       +-------v--------+
  | Database A     |       | Event Broker   |       | Database C     |
  +----------------+       +----------------+       +----------------+

Legend:
- Each bounded context owns its database
- Communication between contexts uses sync or async methods
- Anti-Corruption Layer (not shown) translates data formats

Components

Bounded Context Microservices

Any microservice framework (Spring Boot, Node.js, etc.)

Encapsulate business logic and data for a specific domain

Databases per Context

Relational or NoSQL databases (PostgreSQL, MongoDB)

Store data owned exclusively by each bounded context

API Gateway / Service Mesh

Kong, Istio, or Envoy

Route requests and manage communication between services

Event Bus / Message Broker

Kafka, RabbitMQ

Enable asynchronous communication and event-driven integration

Anti-Corruption Layer

Adapter or Translator components

Translate and protect bounded contexts from external models

Request Flow

1. Client sends request to API Gateway

2. API Gateway routes request to appropriate bounded context microservice

3. Microservice processes request using its own database

4. If data from another context is needed, microservice calls that context via API or listens to events

5. For asynchronous updates, microservices publish events to Event Bus

6. Other contexts subscribe to relevant events and update their own data accordingly

7. Anti-Corruption Layer translates data formats between contexts to avoid leakage

Database Schema

Entities are defined per bounded context with no shared tables. Example: - Context A: Customer(id, name, contact_info) - Context B: Order(id, customer_id, order_date, status) - Context C: Inventory(id, product_id, quantity) Relationships between contexts are handled via IDs and events, not direct foreign keys.

Scaling Discussion

Bottlenecks

Tight coupling between bounded contexts causing deployment delays

Synchronous calls causing high latency and cascading failures

Event bus overload with high event volume

Database contention within a single context

Data inconsistency across contexts due to eventual consistency

Solutions

Enforce strict bounded context boundaries and use Anti-Corruption Layers

Prefer asynchronous communication with retries and circuit breakers

Partition event topics and scale brokers horizontally

Use database sharding or read replicas within contexts

Implement Saga pattern and idempotent event handlers to maintain consistency

Interview Tips

Time: Spend 10 minutes understanding domain boundaries, 15 minutes designing communication and data ownership, 10 minutes discussing scaling and consistency, 10 minutes for Q&A

Explain importance of clear bounded contexts for team autonomy

Discuss trade-offs between synchronous and asynchronous communication

Highlight data ownership and isolation per context

Describe patterns like Anti-Corruption Layer and Saga for integration

Address scaling challenges and solutions realistically