Microservices and Bounded Contexts: Data Ownership, Isolation, and Architectural Implications

An essential rule of microservice architecture is that each microservice must own its own domain data and logic, operating with an independent lifecycle and deployment.

This implies that domain models differ across subsystems; for example, a CRM system, a transactional procurement subsystem, and a customer‑support subsystem each expose unique customer entity attributes within their own bounded contexts.

This principle mirrors Domain‑Driven Design (DDD): each bounded context or autonomous subsystem must have its own domain model (data plus behavior). Each DDD context corresponds to one or more business microservices, and the bounded‑context pattern will be explored further in the next section.

In many traditional (monolithic) applications a single centralized database—or only a few databases—is used, typically a standardized SQL database that serves the entire application and all its internal subsystems.

Traditional data management

Microservice data management

In the traditional approach all services share a single database, usually within a layered architecture. The microservice approach gives each service its own model and data. While a centralized database may appear simpler and allow reuse of entities across subsystems, it often leads to a proliferation of tables containing many unnecessary columns, akin to using a single physical map for a short walk.

A monolithic application that uses a single relational database enjoys two major benefits: ACID transactions and the SQL language, which can operate across all tables and data related to the application, making query writing straightforward.

When moving to a microservice architecture, data access becomes more complex. Even if ACID transactions are used within a microservice or bounded context, the data owned by that microservice is private and must be accessed only through its API endpoints (REST, gRPC, SOAP, etc.) or via asynchronous messaging (AMQP or similar).

Encapsulating data ensures loose coupling and allows services to evolve independently. If multiple services access the same data, any architectural change requires coordinated updates across all services, breaking the autonomy of microservice lifecycles. Distributed data structures also mean you cannot perform a single ACID transaction across microservices, forcing the use of eventual consistency for business processes that span multiple services—a far more challenging task than simple SQL joins.

Different microservices often use different types of databases. Modern applications store and process diverse data types, and relational databases are not always the optimal choice. For some use cases, NoSQL databases such as Azure Cosmos DB or MongoDB provide more convenient data models and better performance and scalability. In other cases, relational databases remain the best option. Consequently, microservice‑based applications frequently employ a mix of SQL and NoSQL databases, a practice known as polyglot persistence.

A partitioned, multi‑tenant persistence architecture offers many benefits, including loosely coupled services, improved performance, scalability, cost efficiency, and manageability, but it also introduces distributed data‑management challenges as described later in the chapter.

Microservices and the Bounded Context Pattern

The concept of microservices originates from the bounded‑context (BC) pattern in Domain‑Driven Design. DDD handles large models by splitting them into multiple bounded contexts with explicit boundaries. Each BC must have its own model and database; similarly, each microservice owns its related data and typically its own ubiquitous language to facilitate communication between developers and domain experts.

Terms (mainly domain entities) can have different names in different bounded contexts even if they share the same identifier used to read the entity from storage.

Thus, a microservice resembles a bounded context, but it also specifies that it is a distributed service. It is built as a separate process for each BC and must use distributed protocols such as HTTP/HTTPS, WebSockets, or AMQP. The bounded‑context pattern itself does not dictate whether a BC is a distributed service or merely a logical boundary within a monolithic deployment.

Defining a service for each bounded context is a good starting point, but it is not mandatory; sometimes a BC may be implemented by multiple physical services or a business microservice may span several BCs. Ultimately, the pattern ties the concepts of context and service closely together.

DDD gains real boundaries by being realized as distributed microservices, yet in limited contexts you may intentionally avoid sharing models between microservices.

Additional Resources

Chris Richardson – "Database per Service" pattern

https://microservices.io/patterns/data/database-per-service.html

Martin Fowler – Bounded Context

https://martinfowler.com/bliki/BoundedContext.html

Martin Fowler – Polyglot Persistence

https://martinfowler.com/bliki/PolyglotPersistence.html

Alberto Brandolini – Context Mapping in Strategic DDD

https://www.infoq.com/articles/ddd-contextmapping