Polyglot Persistence in Microservices: Let the Domain Choose the Database The article explains that polyglot persistence in microservices involves using different databases for different services, each chosen to match the specific data needs of its domain. It describes a concrete e-commerce example where an Order Service uses a relational database with ACID guarantees for financial records, while a document database is used for products with heterogeneous attributes. This approach, known as the Database per Service pattern, enforces loose coupling by ensuring each service owns its database exclusively. Introduction One of the most consequential decisions in microservices architecture is data storage. Monolithic systems traditionally rely on a single relational database to service all needs — a model that worked well for decades but creates tight coupling, limits scalability, and forces every domain to conform to the same persistence paradigm regardless of whether it is the right fit. Modern distributed systems have embraced a concept known as polyglot persistence — the practice of using different data storage technologies within the same system, each chosen to match the access patterns and characteristics of the domain it serves. A MVP e-commerce project https://github.com/dancodingbr/ecommerce examined in this document demonstrates this pattern in a concrete way: three different databases, each serving a distinct microservice, each chosen deliberately. The Three-Database Architecture The platform studied here organizes data across three specialized stores: | Service | Database | Type | Rationale | |---|---|---|---| | Order Service | PostgreSQL | Relational ACID | Transactional consistency, financial data | | Product Service | MongoDB | Document NoSQL | Flexible schemas, rich catalog data | | Cart Service | Redis | In-memory K/V | Sub-millisecond speed, ephemeral state | This is the Database per Service pattern 1 ref-1 . Each service owns its database exclusively — no service reads directly from another's store. This boundary enforces loose coupling and allows each team to evolve the schema independently without risk of cross-service breakage. PostgreSQL for the Order Service: ACID as a Requirement A relational database organizes data into tables — structured grids where every row is a record and every column is a typed, constrained attribute. Relationships between tables are expressed through foreign keys : a column in one table that references the primary key of another, letting the engine enforce referential integrity automatically. This rigid schema is not a limitation but a deliberate guarantee: every row must conform to the same structure, and the engine validates constraints at write time. The payoff is ACID — the ability to group multiple writes into a single all-or-nothing transaction that either commits fully or rolls back completely, leaving the database in a consistent state regardless of failures. The Order Service persists financial records. An order is not just data — it is a legal artifact, a commitment. This makes ACID guarantees non-negotiable. The service uses Spring Data JPA with Flyway for schema migrations. The schema reflects classical relational design: parent orders table with a child order items table linked by a foreign key with ON DELETE CASCADE . CREATE TABLE orders id BIGSERIAL PRIMARY KEY, user id VARCHAR 255 NOT NULL, total DECIMAL 19, 2 NOT NULL, status VARCHAR 50 NOT NULL, order date TIMESTAMP NOT NULL ; CREATE TABLE order items id BIGSERIAL PRIMARY KEY, order id BIGINT NOT NULL, product id VARCHAR 255 NOT NULL, price DECIMAL 19, 2 NOT NULL, quantity INTEGER NOT NULL, CONSTRAINT fk order FOREIGN KEY order id REFERENCES orders id ON DELETE CASCADE ; The OrderService.placeOrder method is annotated with @Transactional . This ensures that if any step in the checkout flow fails — building the item list, calculating the total, persisting the record — the database rolls back to a consistent state. The JPA cascade configuration ensures that saving the parent Order entity also persists all child OrderItem entities in a single atomic operation. Flyway provides versioned, reproducible migration scripts. On startup the service validates that the running schema matches the expected baseline, preventing "works on my machine" drift between environments 2 ref-2 . MongoDB for the Product Service: Schema Flexibility at Catalog Scale A document database stores data as self-describing records — typically JSON or BSON objects — where each document can carry a different set of fields. There is no enforced column list; a document simply contains whatever the application writes into it. Documents that represent the same concept live in a collection , but the engine does not require them to be structurally identical. This makes document databases well-suited to domains where the data model is heterogeneous. Products have heterogeneous attributes: a laptop has RAM and storage, a t-shirt has size and color, a book has an ISBN and author. Fitting all of these into rigid relational columns requires either complex EAV Entity-Attribute-Value schemes or sparse nullable columns — both are maintenance burdens. MongoDB's document model stores each product as a self-describing JSON document. When the catalog team needs to add a new attribute category, no schema migration is required. The application code simply begins writing the new field, and existing documents remain valid. The Product Service uses Spring Data MongoDB with repository abstraction: @Document collection = "products" public class Product { @Id private String id; private String name; private String description; private BigDecimal price; private Integer stockQuantity; private String skuCode; private String category; } The @Document annotation maps the Java class to a MongoDB collection. Spring Data's MongoRepository provides CRUD operations and dynamic query derivation without boilerplate SQL. Redis for the Cart Service: Ephemeral State at Memory Speed A key-value store is the simplest of all database models: every entry is a pair of a unique key and an associated value , with no enforced structure beyond that. There is no schema, no query language, and no relational machinery — retrieval is always by key, and the engine does nothing more than store and fetch the associated value as fast as possible. That simplicity is what makes key-value stores fast: without the overhead of parsing queries, enforcing constraints, or managing transaction logs, the engine can serve reads and writes at memory speed. A shopping cart is session-like: it changes frequently, needs sub-millisecond read/write response times, and is inherently transient — if a cart is lost, the customer can simply re-add items. These characteristics make a relational database an inappropriate choice too much transactional overhead for short-lived state and a document database acceptable but not optimal. Redis was designed precisely for this use case. As an in-memory data structure store, it delivers microsecond latency for key-value operations 3 ref-3 . The Cart Service models cart data as a Redis Hash where the top-level key is cart:{userId} and the value is a JSON-serialized Cart object. The custom RedisConfig configures a RedisTemplate with explicit serializers: @Bean public RedisTemplate