Managing Distributed Data
1. Implementing Database per Service
| Aspect | Detail |
|---|
| Goal | Independent schema and scale per service |
| Implementation | Separate schema, instance, or engine |
| No cross-DB joins | Use APIs / events / materialized views |
| Schema ownership | Service owns migrations, no external writes |
2. Understanding Shared Database Anti-Pattern
| Symptom | Consequence |
|---|
| Multiple services write same table | Hidden coupling, race conditions |
| Coordinated migrations | Lock-step releases |
| Shared ORM model | Library bumps force mass redeploy |
| Fix | Carve ownership; integrate via APIs/events |
3. Implementing Data Replication
| Type | Detail |
|---|
| Synchronous | Strong consistency; higher latency |
| Asynchronous | Eventual; replica lag |
| Logical (CDC) | Stream WAL/binlog into Kafka |
| Cross-region | Multi-master or single-writer + readers |
4. Handling Data Consistency
| Pattern | Detail |
|---|
| Local transaction | Within a single service |
| Saga | Across services with compensations |
| Outbox | Atomic write + event for reliable propagation |
| Idempotency | Tolerate retries safely |
5. Using Eventual Consistency
| Aspect | Detail |
|---|
| Convergence | State agrees after replication |
| UX | Mask via optimistic UI |
| Conflict resolution | Last-write-wins, vector clocks, CRDTs |
| Measurement | Track replication lag SLO |
6. Implementing Change Data Capture
| Tool | Source |
|---|
| Debezium | Postgres, MySQL, Mongo, SQL Server |
| Maxwell's daemon | MySQL binlog |
| AWS DMS | Many sources |
| Postgres logical decoding | Native via wal2json/pgoutput |
Note: CDC enables outbox-like patterns without app code changes.
7. Managing Data Ownership
| Principle | Detail |
|---|
| Single writer | One service is source of truth per dataset |
| Read replicas | Other services read via API or CDC |
| Schema authority | Owner approves schema changes |
| Catalog | Data catalog (DataHub, Atlan) lists ownership |
8. Handling Data Duplication
| Trade-off | Detail |
|---|
| Acceptable | Read-optimized copies, denormalized views |
| Risky | Multiple writers to same logical entity |
| Sync | Event-driven; track source-of-truth |
| Reconciliation | Periodic batch compare |
9. Implementing Polyglot Persistence
| Need | Database |
|---|
| Transactional/relational | Postgres, MySQL |
| Document | MongoDB, DynamoDB |
| Wide-column | Cassandra, ScyllaDB |
| Key-value / cache | Redis, Memcached |
| Search | Elasticsearch, OpenSearch |
| Graph | Neo4j, Neptune |
| Time series | InfluxDB, TimescaleDB |
| Vector | pgvector, Pinecone, Weaviate |
10. Implementing Database Sharding
| Strategy | Detail |
|---|
| Hash-based | Even spread; hard to rebalance |
| Range-based | Good for range queries; risk of hotspots |
| Directory | Lookup table; flexible, single point |
| Geo-sharding | Region-local data |
| Cross-shard ops | Avoid; or use scatter-gather |
11. Managing Data Migration
| Step | Detail |
|---|
| Versioned migrations | Flyway, Liquibase, Alembic |
| Expand/contract | Add new col → backfill → switch reads → drop old |
| Dual-write | Old + new during transition |
| Backfill | Batch jobs; track progress |
| Rollback | Forward-only with reverts |
12. Understanding Transaction Boundaries
| Boundary | Mechanism |
|---|
| Within service | ACID DB transaction |
| Across services | Saga (orchestration / choreography) |
| Within aggregate | Single transaction guaranteed |
| Across aggregates | Eventual consistency via events |