Bird
Raised Fist0
Microservicessystem_design~7 mins

Bounded context concept in Microservices - System Design Guide

Choose your learning style10 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Problem Statement
When a large system grows, different teams and parts of the system start using the same terms but with different meanings. This causes confusion, bugs, and integration problems because the shared language is unclear and inconsistent.
Solution
Bounded context divides the system into clear, separate areas where each area has its own language and rules. Each context owns its data and logic, so teams can work independently without misunderstandings or conflicts over terms and behaviors.
Architecture
┌───────────────┐      ┌───────────────┐      ┌───────────────┐
│ Bounded       │      │ Bounded       │      │ Bounded       │
│ Context A     │─────▶│ Context B     │─────▶│ Context C     │
│ (Orders)      │      │ (Payments)    │      │ (Shipping)    │
└───────────────┘      └───────────────┘      └───────────────┘
       │                      │                      │
       │ Owns its data        │ Owns its data        │ Owns its data
       │ and language         │ and language         │ and language

This diagram shows three separate bounded contexts, each owning its own data and language. They communicate through well-defined interfaces but keep their internal models isolated.

Trade-offs
✓ Pros
→
Prevents confusion by isolating domain language within each context.
→
Allows teams to develop and deploy independently, speeding up delivery.
→
Reduces tight coupling, making the system easier to maintain and evolve.
✗ Cons
→
Requires careful upfront analysis to define clear boundaries.
→
Integration between contexts can add complexity and overhead.
→
May lead to duplicated concepts or data across contexts.
Use when building complex systems with multiple teams or domains, especially when terms or rules differ across parts of the system. Typically beneficial when the system has more than 10,000 lines of code or multiple business domains.
Avoid when the system is small or simple, with a single domain and team, as the overhead of defining contexts outweighs the benefits.
Real World Examples
Amazon
Amazon separates its ordering, payment, and shipping domains into bounded contexts to allow independent development and reduce integration errors.
Netflix
Netflix uses bounded contexts to isolate user management, content delivery, and billing, enabling teams to innovate without stepping on each other's toes.
Uber
Uber applies bounded contexts to separate rider, driver, and payment services, each with its own data and logic to handle domain-specific rules.
Alternatives
Monolithic architecture
All functionality and domain logic live in a single codebase without clear domain boundaries.
Use when: Choose when the system is small, simple, or early in development to reduce complexity.
Shared kernel
Multiple teams share a common subset of the domain model instead of fully isolated contexts.
Use when: Choose when teams need to share core domain concepts tightly but want some separation.
Microkernel architecture
Core system with plug-in modules instead of fully separate bounded contexts.
Use when: Choose when extensibility is key but domain separation is less critical.
Summary
Bounded context isolates domain models to prevent confusion and conflicts in large systems.
It enables teams to work independently by owning their own language and data.
Clear boundaries improve maintainability but require careful design and integration.

Practice

(1/5)
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