When my team broke apart a large monolithic application into microservices a few years ago, one of the most contentious early debates wasn’t about service boundaries or API contracts — it was about data. Should every service share the same database? Should each service get its own? And if so, does that mean picking one database technology for everything, or something different for each service based on what it actually needs? Those conversations led me deep into two concepts that have shaped how I design distributed systems ever since: polyglot persistence and event sourcing. This article covers both, along with the patterns that make NoSQL databases such a natural fit for microservices architectures.
The Database-Per-Service Principle
A foundational pattern in microservices architecture is that each service owns its own data, exclusively, with no other service allowed to access that data directly — every interaction has to go through the owning service’s API. This is often summarized as “database per service.” The reasoning is straightforward: if multiple services shared direct access to the same underlying database, you’d end up with hidden coupling between services at the schema level, meaning a change to one service’s data model could silently break another service that reaches directly into that same database. Enforcing access only through APIs keeps services genuinely independent and deployable on their own schedules.
This principle is what makes polyglot persistence both possible and sensible in the first place — since each service’s data is private to that service, nothing stops different services from using entirely different database technologies suited to their individual needs.
Polyglot Persistence: The Right Tool for Each Job
Polyglot persistence means using different types of databases for different services (or even different components within a service), chosen based on each one’s specific data access patterns, rather than forcing every part of a system into a single, one-size-fits-all database technology.
Why This Matters
A monolithic application tends to gravitate toward a single relational database for everything, simply because that’s what was chosen at the start and migrating away is painful. But different parts of an application genuinely have very different data needs. A product catalog service might benefit from a document database’s flexible schema. A recommendation service might be far better served by a graph database like Neo4j, given how naturally connection-based recommendation queries map onto graph traversals. A session or caching layer clearly wants something like Redis, optimized for low-latency in-memory access. A high-volume clickstream or event-ingestion service might be best served by Cassandra’s write-optimized, horizontally scalable architecture. An order-processing service with genuinely relational, transactional needs might still be best served by a traditional relational database.
In a microservices architecture, since each service owns its data independently, there’s no structural reason to force all of these different needs into one database technology — and real benefits to not doing so.
Practical Examples from Real Systems
In an e-commerce platform I worked on, we ended up with a genuinely polyglot setup: the product catalog service used a document database for flexible, evolving product attributes across many different product categories; the shopping cart and session service used Redis for speed and natural TTL-based expiration; the order service used a relational database, since order processing had genuine multi-table transactional requirements; the recommendation service used Neo4j to model customer-product-category relationships; and a clickstream analytics service used Cassandra to ingest and store massive volumes of user behavior events with predictable write throughput.
Each choice was driven by that specific service’s actual access patterns, not by a company-wide “we use X for everything” policy — and each service’s database could be scaled, tuned, and operated independently of the others.
The Real Costs of Polyglot Persistence
Polyglot persistence isn’t free, and I want to be honest about the tradeoffs. Operating several different database technologies means your team needs genuine expertise across all of them — backup strategies, monitoring approaches, failure modes, and performance tuning all differ meaningfully between, say, Cassandra and Neo4j. Smaller teams in particular can end up spread too thin trying to properly operate five different database technologies well, and I’ve seen teams get real value from deliberately limiting their polyglot sprawl to two or three well-understood technologies rather than adopting a new one for every new service without real justification.
Event Sourcing: Storing Change, Not Just State
Event sourcing is a pattern that fits particularly well with certain NoSQL databases, especially those with strong append-only, ordered-log capabilities like Cassandra, Kafka (which, while not strictly a database, plays a central role in most event-sourced architectures), and Redis Streams.
The Core Idea
In a traditional data model, you store the current state of an entity and overwrite it as it changes — an order’s status field just gets updated from “pending” to “shipped” to “delivered,” with each update replacing the last, and no history retained (unless you build that separately). In event sourcing, you instead store every state-changing event as an immutable record — OrderPlaced, OrderShipped, OrderDelivered — and the current state is derived by replaying those events in order, rather than being stored directly as the primary source of truth.
Why This Matters for Microservices
Event sourcing pairs naturally with microservices for a few reasons. It provides a complete, auditable history of everything that happened to an entity, which is valuable for debugging, compliance, and analytics in ways a simple “current state” model can’t offer, since the current-state model has already discarded the path that led there. It also enables event-driven communication between services — when one service records an event, other services can subscribe to that event stream and react to it asynchronously, without tight coupling or synchronous API calls between services.
Event Sourcing and CQRS
Event sourcing is frequently paired with CQRS (Command Query Responsibility Segregation) — separating the model used for writes (the event log itself) from the model used for reads (one or more denormalized “read models,” often called projections, optimized for specific query needs). This pairing maps very naturally onto the NoSQL modeling philosophy covered throughout this series: instead of trying to query the raw event log directly for every need, you build purpose-specific, denormalized read models — potentially using different NoSQL databases for different projections, depending on their query characteristics. A orders_by_customer projection might live in Cassandra for fast lookups; a order_search projection might live in a search-optimized store for flexible filtering.
Practical Event Sourcing Example
Consider an order service using event sourcing. Instead of an orders table with a mutable status column, you’d have an append-only event store (in Cassandra, this might be a table partitioned by order_id with a clustering column of event_timestamp, storing each event as a row):
PK: order_id, CK: event_timestamp
Events: OrderPlaced, PaymentReceived, OrderShipped, OrderDelivered
To get the current state of an order, you replay all events for that order_id in order and apply each one’s effect. For performance, most event-sourced systems periodically create “snapshots” of derived state, so you don’t need to replay potentially thousands of events from the very beginning every single time — you load the most recent snapshot and only replay events that occurred after it.
Saga Pattern: Managing Distributed Transactions
A related challenge in microservices architectures is handling operations that span multiple services, where you can’t rely on a traditional single-database ACID transaction. The saga pattern addresses this by breaking a distributed operation into a sequence of local transactions, each within a single service, coordinated either through choreography (services react to each other’s events, often published to something like Kafka or Redis Streams) or orchestration (a central coordinator explicitly directs each step).
If a step in the saga fails, compensating actions are triggered to undo the effects of previously completed steps — canceling a reservation, refunding a payment, and so on — rather than relying on a database-level rollback that simply isn’t possible across independently-owned databases. This pattern relies heavily on reliable event delivery, which is another reason durable, ordered NoSQL structures like Cassandra tables or Redis Streams (rather than fire-and-forget pub/sub) tend to underpin production saga implementations.
Data Consistency Across Services
Without a shared database and cross-service transactions, microservices architectures generally have to accept eventual consistency between services — a change made in one service will, sooner or later, be reflected in dependent read models or other services, but not necessarily instantaneously. This is a genuine tradeoff that needs to be communicated clearly to whoever is designing the user-facing product experience, since “eventually consistent” can surface as visible, if usually brief, inconsistencies to end users (an order that briefly shows as “processing” in one part of the UI and “confirmed” in another, for instance).
Choosing which NoSQL database each service uses often comes back to exactly how much consistency that service genuinely needs — as covered in the scalability article in this series, tunable consistency levels let you make this tradeoff deliberately, on an operation-by-operation basis, rather than accepting a single fixed consistency posture across your entire distributed system.
Real-World Use Cases
Beyond e-commerce, this combination of patterns shows up heavily in financial services (event sourcing for a fully auditable transaction history, often paired with a graph database for fraud detection, as covered in the Neo4j articles in this series), IoT platforms (Cassandra or DynamoDB for high-volume device event ingestion, feeding into event-driven downstream processing), and social platforms (a mix of graph databases for the social graph itself, wide-column stores for activity feeds, and Redis for real-time presence and caching).
Advantages and Limitations
The advantage of combining polyglot persistence with event sourcing in a microservices architecture is a system where each component is optimized for its actual job, genuinely decoupled from its neighbors, and equipped with a durable, replayable history of everything that’s happened — which is enormously valuable for debugging, auditing, and building new features (new read-model projections) without needing to touch the services that originally produced the events.
The limitations are real operational and cognitive complexity. More database technologies mean more operational surface area to secure, monitor, and staff for, as discussed in the security article in this series. Event sourcing adds genuine complexity to what might otherwise be a simple CRUD service, and it’s not the right fit for every service — I generally reserve it for entities where history, auditability, or event-driven integration with other services provides clear, tangible value, rather than applying it universally out of architectural purity.
API Composition and Read-Model Aggregation
A practical challenge that comes up constantly once each service owns its own database is how to answer queries that naturally span multiple services’ data — displaying an order alongside the customer’s profile information and product details, for instance, when those three pieces of data live in three entirely separate services and databases. A common pattern for this is API composition, where a dedicated aggregating service (sometimes called a backend-for-frontend, or BFF) calls each relevant service’s API and combines the results before returning a unified response to the client.
This works well for simple cases, but it introduces real latency (since you’re now making several sequential or parallel API calls instead of one) and availability coupling (since the composed response can only be as reliable as the least reliable individual service it depends on). For more demanding cases, I’ve built dedicated, precomputed read-model services specifically to avoid this composition overhead at request time — a service that subscribes to relevant events from several other services and maintains its own denormalized, purpose-built view (often backed by exactly the kind of NoSQL database best suited for that specific view’s query pattern) that can answer the combined query directly, in a single fast lookup, without needing to call out to multiple other services synchronously for every single request.
Idempotency in Event-Driven Systems
Distributed, event-driven microservices architectures need to account for the reality that messages can occasionally be delivered more than once — a consumer might process an event successfully but crash before acknowledging it, causing the message broker to redeliver it later. This makes idempotency a genuine requirement, not an optional nicety, for any service consuming events as part of a saga or general event-driven workflow.
I generally design event handlers to be idempotent by tracking which specific event IDs have already been processed (often stored in the same NoSQL database the service already uses, keyed by event ID with a reasonable TTL) and short-circuiting if a duplicate is detected, rather than assuming exactly-once delivery is guaranteed by the underlying messaging infrastructure, since very few real-world messaging systems provide that guarantee without significant additional complexity and cost.
Schema Evolution Across Service Boundaries
Because each service’s data is genuinely private, evolving a service’s internal data model is much less risky than in a shared-database architecture — but the events and API contracts that service exposes to others still require careful, backward-compatible evolution, since other services depend on their shape. I follow a consistent discipline of only adding new, optional fields to event payloads and API responses, never removing or renaming existing fields without a coordinated, versioned migration across every consuming service, and maintaining explicit event schema versioning (embedding a version number directly in each event) so consumers can handle multiple schema versions gracefully during any transition period rather than breaking the moment a producer service evolves its internal model.
Observability Across Polyglot Systems
A genuinely underrated challenge of polyglot persistence in a microservices architecture is observability — tracing a single logical business operation (like placing an order) as it flows through several services, each backed by a different database technology, each with its own logging format and monitoring tooling. I’ve found distributed tracing (using a standard like OpenTelemetry, with a consistent trace ID propagated across every service and event boundary involved) to be essential for making sense of failures and performance issues in these systems, since without it, diagnosing a slow or failed operation means manually correlating logs across several genuinely different systems, which becomes prohibitively time-consuming as the number of services and database technologies involved grows.
Best Practices
- Enforce database-per-service strictly; never let a second service reach directly into another service’s database.
- Choose each service’s database technology based on that service’s actual access patterns, not a company-wide default.
- Limit the total number of distinct database technologies in play to what your team can genuinely operate well.
- Reserve event sourcing for entities where auditability, replay, or event-driven integration provide clear value, not as a default pattern for every service.
- Use snapshots to bound event replay cost as an event-sourced entity’s history grows.
- Communicate eventual consistency tradeoffs clearly to product and design teams, since they surface as real, visible behavior to end users.
- Use durable, ordered structures (Cassandra tables, Kafka, Redis Streams) rather than fire-and-forget messaging for anything a saga’s correctness depends on.
Final Thoughts
NoSQL databases and microservices architecture grew up together, in a sense — the same forces that pushed teams toward independently deployable, independently scalable services also pushed them toward databases that could be chosen and tuned per-service rather than forced into a single shared schema. Polyglot persistence and event sourcing aren’t mandatory companions to microservices, but where they fit, they let each part of a distributed system be genuinely well-suited to its actual job, at the cost of real operational complexity that deserves honest, deliberate management rather than being adopted reflexively because it sounds architecturally sophisticated.
