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

Practice

1. What is the main purpose of a bounded context in microservices architecture?

easy

A. To combine all services into one large database

B. To make all microservices share the same data model

C. To clearly separate different parts of a system with their own rules and data

D. To reduce the number of microservices by merging them

Solution

1. Step 1: Understand the concept of bounded context

   A bounded context defines a clear boundary where a specific model and rules apply, separating it from others.

2. Step 2: Identify the purpose in microservices

   This separation helps manage complexity by isolating data and responsibilities within each context.

3. Final Answer:

   To clearly separate different parts of a system with their own rules and data -> Option C

4. Quick Check:

   Bounded context = clear separation [OK]

Hint: Bounded context means clear boundaries for data and rules [OK]

Common Mistakes:

• Thinking all microservices share the same data model
• Believing bounded context merges services
• Confusing bounded context with database design

2. Which of the following best describes a correct way to define a bounded context in a microservices system?

easy

A. A service that shares its database schema with all other services

B. A service that handles all user authentication and authorization globally

C. A service that duplicates data from all other services

D. A service with its own data model and business rules isolated from others

Solution

1. Step 1: Review bounded context definition

   A bounded context owns its data model and business rules, isolated from other contexts.

2. Step 2: Match the option to this definition

   A service with its own data model and business rules isolated from others describes a service with isolated data and rules, fitting the bounded context concept.

3. Final Answer:

   A service with its own data model and business rules isolated from others -> Option D

4. Quick Check:

   Isolated data and rules = bounded context [OK]

Hint: Bounded context means isolated data and rules per service [OK]

Common Mistakes:

• Assuming shared database means bounded context
• Confusing global services with bounded contexts
• Thinking data duplication defines bounded context

3. Consider a microservices system with two bounded contexts: Order and Inventory. If the Order service needs product details, which is the best practice?

medium

A. Use an API call from Order service to Inventory service

B. Directly query the Inventory database from Order service

C. Duplicate the entire Inventory database inside Order service

D. Ignore product details in Order service

Solution

1. Step 1: Understand bounded context boundaries

   Each bounded context owns its data and should not be accessed directly by others at the database level.

2. Step 2: Identify proper communication method

   Services communicate via APIs to respect boundaries and maintain loose coupling.

3. Final Answer:

   Use an API call from Order service to Inventory service -> Option A

4. Quick Check:

   API calls respect bounded context boundaries [OK]

Hint: Use APIs, not direct DB access between bounded contexts [OK]

Common Mistakes:

• Accessing another service's database directly
• Duplicating entire databases unnecessarily
• Ignoring data needs between services

4. A team designed two microservices with overlapping data models and shared database tables. What is the main problem with this design regarding bounded contexts?

medium

A. It violates bounded context principles by sharing data models and storage

B. It improves scalability by sharing data

C. It reduces complexity by merging contexts

D. It ensures data consistency perfectly

Solution

1. Step 1: Analyze the design against bounded context rules

   Bounded contexts require separate data models and storage to avoid tight coupling.

2. Step 2: Identify the problem with shared data models and tables

   Sharing data models and tables causes coupling and breaks bounded context boundaries.

3. Final Answer:

   It violates bounded context principles by sharing data models and storage -> Option A

4. Quick Check:

   Shared data models break bounded context [OK]

Hint: Bounded contexts must not share data models or storage [OK]

Common Mistakes:

• Thinking shared data improves scalability
• Believing merging contexts reduces complexity
• Assuming shared storage ensures perfect consistency

5. You are designing a large e-commerce platform with multiple teams. How should you apply bounded contexts to improve scalability and team autonomy?

hard

A. Create one big service handling all features to avoid communication overhead

B. Divide the system into contexts like Catalog, Order, and Payment, each with separate data and APIs

C. Share a single database schema among all teams to keep data consistent

D. Let teams share code and data models freely to speed development

Solution

1. Step 1: Identify the benefits of bounded contexts in large systems

   Bounded contexts help split large systems into manageable parts owned by different teams.

2. Step 2: Apply separation with independent data and APIs

   Each context should have its own data and communicate via APIs to maintain autonomy and scalability.

3. Final Answer:

   Divide the system into contexts like Catalog, Order, and Payment, each with separate data and APIs -> Option B

4. Quick Check:

   Separate contexts with own data and APIs = scalable teams [OK]

Hint: Split by domain areas with separate data and APIs [OK]

Common Mistakes:

• Building one big service for all features
• Sharing database schema across teams
• Allowing free sharing of code and data models