Designing Data Architecture for Microservices: Key Principles & Database Choices

What Is a Microservice?

According to Martin Fowler, a microservice is an architectural style that builds an application as a suite of small, independently deployable services, each running in its own process and communicating via lightweight HTTP APIs. Services are bounded by business capabilities, enabling autonomous development, deployment, and scaling.

Advantages of Microservices

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

Flexibility & Scalability : Only the services that need more resources are scaled, reducing cost and simplifying capacity planning.

Resilience : Service isolation prevents a failure in one component from cascading to the entire application.

Team Scaling : Small, cross‑functional teams can own single services, improving collaboration and reducing silos.

Technical Characteristics

Decoupling : Services are independent processes communicating over network APIs, often HTTP/REST.

Lightweight APIs : Minimal dependencies on complex middleware; services expose simple contracts.

DevOps & CI/CD : The large number of services requires automated build, test, and deployment pipelines.

Decentralized Data Governance : Each service typically owns its own data store, leading to multiple databases in a single system.

Case Study: A Social‑Media Monitoring Platform

An architect (Jonnathan) at a bank needs to collect public comments from Facebook, Twitter, Google+, and Snapchat, analyse them with AI, and respond to users. The solution splits each social‑media integration into its own microservice, adds a Feed‑Merge service and an Aggregate service, and deploys each service in an isolated container with its own database.

When Google+ activity drops, the Google+ container is stopped without code changes or downtime. Later, a new WhatsApp module is added, and additional containers are provisioned for a high‑traffic Snapchat service, demonstrating the flexibility of the architecture.

Data Design Considerations for Microservices

Key questions to ask when designing data for microservices include:

Should I use a single database for all services or multiple databases?

If multiple databases, should each service have its own best‑fit database or share a common type?

How will I scale the database as the service grows?

Will schema changes in one service impact others?

Can the data layer adapt quickly to evolving business requirements?

One Database per Service vs. Shared Database

A shared database ("one‑database‑many‑services") creates a single point of failure, encourages tight coupling, and makes it hard to optimise or scale individual services. The recommended pattern is database per service , which preserves service independence, enables isolated upgrades, and supports polyglot persistence.

Polyglot Persistence vs. Multi‑Model Databases

Polyglot persistence lets each service choose the most suitable database technology (e.g., Redis for sessions, MongoDB for flexible documents, Elasticsearch for full‑text search). While powerful, it adds operational complexity and requires more resources.

Multi‑model databases provide a middle ground: a single database engine (often a NoSQL system) that supports multiple data models, reducing management overhead while still allowing per‑service isolation.

Scaling Data in a Microservice System

Following the Scale‑Cube model, scalability can be addressed along three axes:

X‑axis : Horizontal replication of the entire system.

Y‑axis : Decomposition into independent microservices.

Z‑axis : Data partitioning (sharding).

Data partitioning can be performed at the application level (routing users to specific database instances) or at the database level (native sharding). Choosing the right approach depends on traffic patterns and operational capabilities.

Dynamic Schemas and Rapid Development

Microservice teams need a data store that can evolve without costly schema migrations. NoSQL databases, which support dynamic or schemaless designs, enable rapid iteration and continuous delivery.

Why MongoDB Fits Microservice Architectures

MongoDB offers several features that align with microservice needs:

Multi‑model capabilities (graph lookup, facet search, in‑memory engine).

Native JSON document model, matching the payload format of REST APIs.

Dynamic schema, allowing on‑the‑fly changes without downtime.

Change Streams for event‑driven architectures, similar to Kafka.

Robust sharding for horizontal scaling, with automatic balancing and zero‑downtime expansion.

These attributes make MongoDB a strong candidate for the "one‑database‑per‑service" pattern, especially when combined with a multi‑model approach.

Reference Architecture Diagram

The diagram illustrates a typical microservice deployment where each service runs in its own container, owns an independent MongoDB instance, and communicates via lightweight APIs.

Author: Tang Jianfa (Mongoing Chinese Community)