Bounded context concept in Microservices - System Design Exercise

Design: E-commerce Microservices Platform

Design the system architecture focusing on how to split the system into bounded contexts and how they communicate. Out of scope: detailed UI design and deployment specifics.

Functional Requirements

FR1: Support multiple business domains like ordering, inventory, and payment

FR2: Each domain should evolve independently without affecting others

FR3: Clear separation of data and logic per domain

FR4: Allow teams to work autonomously on different domains

FR5: Enable integration between domains with minimal coupling

Non-Functional Requirements

NFR1: Handle 10,000 concurrent users

NFR2: API response latency p99 under 300ms

NFR3: Availability target 99.9% uptime

NFR4: Data consistency within each domain, eventual consistency across domains

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Domain services for each bounded context

APIs or message brokers for inter-context communication

Databases scoped per bounded context

API gateways or service mesh for routing

Monitoring and logging per context

Design Patterns

Domain-Driven Design (DDD)

Event-driven architecture

API Gateway pattern

Database per service pattern

Saga pattern for distributed transactions

Reference Architecture

                    +---------------------+
                    |  API Gateway        |
                    +----------+----------+
                               |
        +----------------------+-----------------------+
        |                      |                       |
+-------v-------+      +-------v-------+       +-------v-------+
| Order Context |      | Inventory     |       | Payment       |
| Service       |      | Context       |       | Context       |
+-------+-------+      +-------+-------+       +-------+-------+
        |                      |                       |
+-------v-------+      +-------v-------+       +-------v-------+
| Order DB      |      | Inventory DB  |       | Payment DB    |
+---------------+      +---------------+       +---------------+

Communication between contexts via async events or REST APIs

Components

Order Context Service

Spring Boot microservice

Handles order creation, updates, and queries within the order domain

Inventory Context Service

Node.js microservice

Manages stock levels and product availability

Payment Context Service

Python Flask microservice

Processes payments and manages payment status

API Gateway

Kong or AWS API Gateway

Routes external requests to appropriate bounded context services

Message Broker

Apache Kafka or RabbitMQ

Enables asynchronous communication and event propagation between contexts

Databases

PostgreSQL per context

Stores data isolated per bounded context to maintain independence

Request Flow

1. Client sends order request to API Gateway

2. API Gateway routes request to Order Context Service

3. Order Service validates and stores order in Order DB

4. Order Service publishes 'OrderCreated' event to Message Broker

5. Inventory Service listens to 'OrderCreated' event and updates stock in Inventory DB

6. Inventory Service publishes 'InventoryUpdated' event if stock changes

7. Payment Service listens to relevant events and processes payment

8. Each service updates its own database independently

9. Clients query each context via API Gateway for domain-specific data

Database Schema

Entities: - Order Context: Order (id, customer_id, status, total_amount, created_at) - Inventory Context: Product (id, name, stock_quantity, price) - Payment Context: Payment (id, order_id, payment_status, amount, payment_method) Relationships: - Order references customer_id but customer data managed elsewhere - Payment references Order by order_id - No direct foreign keys across contexts to maintain independence

Scaling Discussion

Bottlenecks

API Gateway becoming a single point of failure under high load

Message Broker overload with high event volume

Database write contention in high traffic contexts

Data consistency challenges across asynchronous boundaries

Solutions

Deploy API Gateway in a cluster with load balancing and failover

Partition message topics and scale brokers horizontally

Use database sharding or read replicas per context

Implement Saga pattern and idempotent event handlers for eventual consistency

Interview Tips

Time: 10 minutes to clarify requirements and define bounded contexts, 15 minutes to design architecture and data flow, 10 minutes to discuss scaling and trade-offs, 10 minutes for questions

Explain the importance of clear domain boundaries to reduce coupling

Describe how each bounded context owns its data and logic

Discuss communication methods and consistency models

Highlight how this design supports team autonomy and scalability

Address potential bottlenecks and mitigation strategies