Designing Data Architecture for Microservices: Principles, Database Choices, and MongoDB as a Suitable Solution

Preface : Microservices are a software architecture pattern. Discussions often focus on containers or other technologies, but this article examines data‑design considerations in a microservice architecture.

What Is a Microservice?

According to Martin Fowler, a microservice is an architectural style that builds an application as a suite of small services, each running in its own process and communicating via lightweight HTTP APIs. Services are bounded by business domains, can be developed and deployed independently, and enable faster product releases.

Advantages of Microservices

Microservices provide faster time‑to‑market, flexibility, resilience, consistency, and relatively lower cost.

Faster Release Cycle

Changes to a single service can be built, tested, and deployed without affecting the rest of the system, reducing risk and complexity.

Better Flexibility and Scalability

Only the services that need additional capacity are scaled, allowing more efficient resource planning and lower total cost of ownership.

Resilience

Service isolation prevents a failure in one component from bringing down the entire application.

Easier Scaling of Teams

Small, cross‑functional teams can own individual services, improving collaboration and reducing silos.

Technical Characteristics of Microservices

An example architecture shows a bank collecting social‑media data from Facebook, Twitter, Google+, and Snapchat via separate modules, merging feeds, and providing data to an analytics platform. Each module runs in its own container with its own database, allowing independent deployment and scaling.

When a social platform becomes obsolete (e.g., Google+), the corresponding container can be stopped without code changes or system downtime.

New requirements (e.g., adding WhatsApp) are satisfied by deploying a new module.

Performance issues (e.g., Snapchat) are addressed by adding additional containers.

Design Principles for Microservice Data Architecture

Key principles include decoupling services, using lightweight APIs, continuous integration (DevOps), decentralized data governance, and considering data partitioning at the application or database level.

Decouple

Services should be independent, focused on specific business capabilities, and communicate via network APIs.

Lightweight APIs

Use HTTP RESTful APIs to minimize coupling between services.

DevOps & Continuous Integration

Microservice ecosystems require CI/CD pipelines to manage many independent services.

Decentralized Data Governance

Each service typically owns its own database, enabling independent scaling and evolution.

Microservice Data Design Considerations

When designing data for microservices, ask: Should each service have its own database? Which database type fits each service? How to scale databases? How to handle schema changes without affecting other services? How to respond quickly to evolving requirements?

One Database per Service vs. Shared Database

Sharing a single database across services creates a single point of failure and tight coupling. The recommended approach is “database per service,” which aligns with microservice independence and supports polyglot persistence.

Polyglot Persistence vs. Multi‑Model Databases

Polyglot persistence uses different databases (e.g., Redis for caching, MongoDB for flexible documents, Elasticsearch for search) to suit each service’s needs, at the cost of increased operational complexity. Multi‑model databases (e.g., MongoDB) provide multiple data models within a single system, simplifying management.

Scaling Data in Microservices

Scale horizontally (X‑axis), split non‑overlapping functionality (Y‑axis), and partition data (Z‑axis). Data can be partitioned at the application level or by the database itself (sharding).

Dynamic Schema Support

NoSQL databases like MongoDB allow schema‑less or dynamic schema designs, enabling rapid iteration without costly migrations.

A Suitable Database for Microservices

MongoDB is recommended due to its multi‑model capabilities, native JSON storage, dynamic schema, change streams, and strong sharding support.

Multi‑model database

Native JSON API

Dynamic / schemaless

Change streams for event‑driven architectures

Horizontal scaling via sharding

MongoDB Features

Aggregation framework, $graphLookup, $facet, in‑memory engine, full‑text search, and change streams make MongoDB versatile for microservice needs.

Sharding and Elastic Scaling

MongoDB sharding provides elastic, seamless, and automatic data balancing without downtime.

Author: TJ (Tang Jianfa), rotating chair of the MongoDB Chinese community and chief architect for MongoDB in Greater China.