Logical Database-per-Service (Shared Cluster)

Metadata

ID: RA-002-LOGICAL-DB-PER-SERVICE
Status: Stable / Production-Proven
Authors: Vladyslava Prykhodko, Ivan Baha (ORCID: 0009-0005-7024-7724)
Published Date: 2026-03-13
Tags: #microservices #database #architecture #mongodb #bounded-context

1. Executive Summary

This architecture defines a pragmatic implementation of the "Database per Service" microservices pattern. It utilizes a single, shared database cluster to host multiple logically isolated databases.

A common anti-pattern in microservices is allowing a single service to connect to and manage multiple databases simultaneously, which breaks atomicity, complicates development, and leads to distributed transaction issues. This architecture clearly addresses this by enforcing a strict 1:1 relationship between a microservice and its logical database, ensuring data-processing isolation while significantly reducing the infrastructure maintenance overhead associated with managing multiple physical clusters.

2. Applicability Criteria

Use this pattern when

• Domain-Driven Design is Enforced: The system's data should be divided into proper, atomic, and independent bounded contexts.
• Infrastructure Consolidation: The engineering team needs to reduce operational maintenance, provisioning, and billing costs associated with managing separate physical DB clusters for each service.
• Strict Ownership is Necessary: You must enforce data-processing isolation, ensuring that a dedicated microservice is the sole controller of its logical data partition.

Do NOT use this pattern when

• Poor Data Boundaries: The system's data is highly relational across domains and cannot be split into atomic units. If services constantly need to perform complex data aggregations across domain boundaries, this pattern will introduce severe latency.
• Extreme Noisy Neighbors: One service has massive, unpredictable analytical workloads that could consume all shared cluster compute/RAM, starving other services.
• Polyglot Persistence Needs: Specific services fundamentally require different database engines (e.g., mixing Graph, Time-Series, and Relational models).

3. Architecture Overview

The "Shared Cluster, Logical Isolation" Pattern

While DB-agnostic (applicable to PostgreSQL, MySQL, etc.), this pattern is easily visualized using MongoDB as an example.

• Shared Infrastructure: A single MongoDB Replica Set provides the underlying compute, memory, and storage.
• Logical Boundaries: Each microservice connects strictly to its own logical database within that cluster (e.g., use orders_db, use inventory_db).
• Absolute Ownership: Only the orders service has the credentials to read/write to orders_db. No other service can connect to it.

The Rule of Atomicity

To make this work, data must be split properly. The data modeling phase must ensure that each logical database contains everything its owning microservice needs to perform its primary business functions independently. If a service requires synchronous reads from another service to complete a standard transaction, the data split is flawed.

4. Implementation Details

4.1. Enforcing Isolation

• Access Control (RBAC): Cross-database queries are physically blocked at the database IAM/Role level. The inventory-service user account is explicitly denied access to orders_db.
• Single Connection String: A microservice's configuration must accept only a single database connection string. Bootstrapping a service with multiple DB connections is treated as a critical architectural violation.

4.2. Handling Cross-Domain Data

Because direct DB-to-DB joins are prohibited, and multi-DB transactions within a service break atomicity, cross-domain data needs must be handled via:

• Eventual Consistency: Services publish domain events (e.g., via Kafka/RabbitMQ). Other services consume these events to build local, read-optimized projections of the data in their own isolated DBs.
• API Aggregation: An API Gateway or a dedicated Backend-For-Frontend (BFF) orchestrates concurrent HTTP/gRPC calls to multiple services and aggregates the responses into a single payload for the client.

5. Scalability & Evolution Path

Surgical Service Extraction

Because strict logical isolation and access controls are enforced from day one, extracting a high-traffic service is trivial. If the inventory_db begins monopolizing the shared MongoDB cluster's resources, it can be migrated to its own dedicated physical cluster with zero application code changes—only a data migration and a connection string update are required.

6. Trade-off Analysis

Feature	Benefit	Drawback
Data Isolation	Enforces strict bounded contexts and absolute service ownership.	Requires mature domain modeling; bad data splits lead to massive API overhead.
Maintenance	Centralized backups, patching, and monitoring on one cluster.	Single Point of Failure at the infrastructure level.
Development	Simplifies service logic (no distributed transactions to manage).	Forces engineers to solve cross-domain data needs via asynchronous events.
Cost	Highly efficient use of baseline compute resources.	Susceptible to the "noisy neighbor" problem affecting all services simultaneously.

7. Conclusion

This architecture prevents the complexity of microservices by strictly banning multi-database dependencies within a single service. By logically dividing data within a single cluster, teams gain the operational simplicity of a monolith while maintaining the strict domain separation required for true microservice independence.