Designing Data Architecture for Microservices: Principles, Database Choices, and Scaling Strategies

Microservices is a software architecture pattern that structures an application as a collection of small, independently deployable services, each running in its own process and communicating via lightweight HTTP APIs. This article discusses the key considerations for data design within a microservice architecture.

What is Microservices?

According to Martin Fowler, microservices are a way of building applications by developing a series of small services, each bounded by business capabilities, deployed independently, and often released using automated deployment tools. This approach enables faster product delivery and better alignment between development teams and business goals.

Advantages of Microservices

Microservices offer faster time‑to‑market, flexibility, resilience, consistency, and lower overall cost.

Faster Time‑to‑Market

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

Better Flexibility and Scalability

Only the services that need additional performance are scaled, allowing more efficient capacity planning and lower software licensing costs.

Resilience

Isolating services prevents a failure in one component from cascading to the entire application; only the failing service is degraded.

Easier Scaling of Teams

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

Technical Characteristics of Microservices

An example architecture shows four independent modules for collecting data from Facebook, Twitter, Google+, and Snapchat, each with its own database, combined by Feed Merge and Aggregate services for downstream analysis.

When a social platform becomes irrelevant (e.g., Google+), its container can be stopped without code changes or system downtime. New platforms (e.g., WhatsApp) can be added by deploying a new module, and scaling can be achieved by adding more containers for high‑traffic services like Snapchat.

Design Principles for Microservice Data Architecture

Decouple : Services focus on discrete business capabilities and communicate via network APIs, allowing independent development, testing, and deployment.

Lightweight APIs (Dump Pipes) : Use simple HTTP/RESTful APIs to keep inter‑service communication minimal and avoid heavyweight integration buses.

DevOps & Continuous Integration : Manage many service instances with CI/CD pipelines to automate testing and deployment.

Decentralized Data Governance : Each service owns its own database, enabling independent scaling and schema evolution.

Data Design Considerations for Microservices

Key questions include whether to use a single database or multiple databases, how to choose the right database per service, how to scale databases, the impact of schema changes, and how to keep the data model responsive to evolving requirements.

One Database per Service vs. Shared Database

Sharing a single database across multiple services (one‑database‑many‑services) creates a single point of failure, tight coupling, and limits independent optimization. The recommended pattern is "database per service," which aligns with microservice independence and enables polyglot persistence.

Polyglot Persistence vs. Multi‑Model Databases

Polyglot persistence lets each service use the most suitable database (e.g., Redis for sessions, MongoDB for flexible documents, Elasticsearch for full‑text search). Multi‑model databases provide similar flexibility with a single technology stack, simplifying operations for smaller teams.

Scaling Your Data

Scaling can be approached along three axes: X‑axis (horizontal replication), Y‑axis (functional decomposition into microservices), and Z‑axis (data sharding). Both application‑level partitioning and database‑level sharding are viable strategies.

Dynamic Schemas and Rapid Development

NoSQL databases such as MongoDB support schemaless or dynamic schemas, allowing services to evolve their data models without costly migrations, which is essential for agile, fast‑moving microservice development.

A Suitable Database for Microservice Architecture

MongoDB is highlighted as a strong candidate due to its multi‑model capabilities, native JSON storage, dynamic schema, change streams, and robust sharding support.

Multi‑model database

Native JSON API

Dynamic / schemaless design

Change streams for event‑driven architectures

Horizontal scaling via sharding

MongoDB Features for Microservices

Since version 3.4, MongoDB offers $graphLookup for graph‑like queries, $facet for faceted search, an in‑memory engine comparable to Redis, and full‑text search capabilities.

JSON Data Structure

MongoDB’s native JSON model aligns perfectly with the JSON payloads used in HTTP RESTful APIs between microservices.

Change Streams

MongoDB’s change streams act like a lightweight message queue, enabling event‑driven data coordination across services.

Horizontal Scaling (Sharding)

MongoDB sharding provides elastic scaling, seamless online expansion, and automatic data balancing without application involvement.

Reference Architecture Based on MongoDB

Speaker: TJ (Tang Jianfa), MongoDB Community Chair and Chief Architect for MongoDB in Greater China.

Community and Resources

Join the architecture exchange circle for knowledge sharing, technical articles, and case studies. Scan the QR code to join, and reply with keywords such as "architecture", "practice", "docker", "plan", or "Huawei" to receive free resources.

Disclaimer: The content is collected from the internet, the copyright belongs to the original authors, and the views expressed are personal and not affiliated with the public account. Use the material for learning and exchange only; contact the administrator for removal if any infringement is found.