Database-per-Service Lab (Interactive)
Pick tables, schemas, instances, or dedicated clusters per service, then pick engines per domain and score the fit. Isolation level sets cost multiplier, blast radius, and schema freedom. Choose Postgres for billing, Neo4j for fraud graphs, Redis for sessions, and watch the fit score.
Database-per-Service Isolation & Polyglot Fit
Pick the physical isolation tier and the storage engine each domain deserves, then try sneaking a cross-service JOIN.
Billing Service
ACID transactions, foreign keys, ledger integrity
Private store: PostgreSQL · unit $400/mo
Fraud Ring Detection
Deep graph traversals across account relationships
Private store: Neo4j · unit $450/mo
Session / Leaderboard
Sub-millisecond in-memory lookups, TTL expiry
Private store: Redis · unit $300/mo
Full CPU, RAM, connection-pool and failure isolation: drop a column Tuesday 2 PM, only the owning team can notice. Bezos's 2002 mandate in one sentence: if two services read the same table, they are one service wearing a costume.
How It Works Under the Hood
Database-per-service is the microservices pattern most teams half-implement: shared tables with foreign keys across services silently recreate the monolith, because a schema change or a backdoor JOIN couples deployments at the weakest link. True isolation ranges from shared instance with separate schemas to dedicated clusters per service, trading cost multiplier and blast radius against schema freedom. Polyglot persistence is the payoff: append-only ledgers want Postgres, fraud graphs want Neo4j traversal, session lookups want Redis microsecond reads — each engine fit scored against the actual access pattern.
Core Architectural Principles
- Isolation tiers trade cost multiplier and blast radius for schema freedom across services.
- Backdoor JOINs are only possible at the shared-table tier — the exact coupling that breaks deployments.
- Engine fit scoring: relational ledger, graph traversal, and key-value lookups each pick different databases.
State the rule plainly: services own their data, cross-service access goes through APIs or events, never foreign keys into another service's tables. Then show maturity — full dedicated clusters are ideal but expensive, so schema-level isolation with a no-JOIN policy is the pragmatic start. Mention CQRS or materialized views as the answer for legitimate cross-service query needs.
Data autonomy and polyglot engines versus duplicated data, no cross-service JOINs, and more database instances to operate.