How to Design Data Architecture for Microservices: Best Practices & Choices

Introduction

Microservices are an architectural style that builds an application as a collection of small, independently deployable services. This article examines the data‑design considerations that arise when adopting a microservice architecture and offers practical guidance for choosing databases and structuring data.

What Is a Microservice?

According to Martin Fowler, a microservice is a small service that runs in its own process and communicates via lightweight HTTP APIs. Each service typically aligns with a business capability, can be developed and deployed independently, and often uses automated deployment tools.

Advantages of Microservices

Faster time‑to‑market : Individual services can be updated, tested, and deployed without affecting the whole system.

Improved flexibility and scalability : Only the services that need more resources are scaled, reducing cost and complexity.

Resilience : Failure of one service does not bring down the entire application.

Easier team scaling : Small, cross‑functional teams can own individual services, facilitating parallel development.

Technical Characteristics

Microservices rely on decoupled, lightweight APIs (typically RESTful HTTP) and require robust CI/CD pipelines because the number of services can range from dozens to hundreds.

Data Design Considerations in a Microservice Architecture

Key questions include:

Should a single database serve multiple services, or should each service have its own database?

If multiple databases are used, should each service use a different type of database or a uniform technology?

How can the database be scaled as the system grows?

Will schema changes in one service impact others?

Can the database respond quickly to evolving application requirements?

One Database per Service vs. Shared Database

Sharing a single database across services ("one‑database‑many‑services") is generally considered an anti‑pattern because it creates a single point of failure, encourages tight coupling, and prevents independent scaling. The recommended approach is database per service , which aligns with the independence and scalability goals of microservices.

Polyglot Persistence vs. Multi‑Model Databases

Polyglot persistence allows each service to use the most suitable database (e.g., Redis for caching, MongoDB for flexible documents, Elasticsearch for full‑text search). While powerful, it increases operational complexity. Multi‑model databases, such as MongoDB, provide many data models within a single technology stack, simplifying management while still supporting diverse use cases.

Why MongoDB Fits Microservice Data Needs

MongoDB offers several features that align well with microservice requirements:

Multi‑model support : Handles documents, key‑value, and graph‑like queries.

Native JSON storage : Matches the JSON payloads used in REST APIs.

Dynamic schema : Allows schema evolution without downtime, supporting rapid iteration.

Change streams : Provide an event‑driven mechanism similar to Kafka for inter‑service data coordination.

Sharding : Enables horizontal scaling without service interruption.

MongoDB Features in Detail

Since version 3.4, MongoDB includes aggregation operators such as $graphLookup (graph queries), $facet (faceted search), in‑memory engine for caching, and full‑text search capabilities. Starting with version 3.6, change streams allow services to listen to data changes, facilitating event‑sourcing patterns.

Sharding provides elastic, seamless, and automatic data balancing, allowing services to scale out by adding or removing shards without application changes.

Reference Architecture

The following diagram illustrates a typical microservice architecture built on MongoDB, showing independent service containers, each with its own database, and a feed‑merge service that aggregates data for downstream analytics.

Additional diagrams depict the one‑database‑many‑services anti‑pattern, the polyglot persistence model, and the multi‑model alternative.