Data ownership and consistency

Do not share writable tables

A private database prevents another service from bypassing rules and coupling itself to storage details. Database-per-service is a logical ownership rule; services may share infrastructure when isolation, permissions, backups, and operational needs permit it.

Consumers obtain data through a contract or maintain a local projection from events. Duplication is deliberate in distributed systems because autonomy is often more valuable than a perfectly normalised global schema.

Name the consistency the product needs

Strong consistency is appropriate inside a service transaction. Across services, eventual consistency is common: changes become visible after propagation. Translate that technical fact into product behaviour, such as showing ‘payment processing’ rather than claiming completion prematurely.

Not every field deserves immediate propagation. Inventory reservation may be urgent; an analytics dashboard can lag. State acceptable staleness per use case.

Coordinate long-running work with a saga

A saga is a sequence of local transactions. Choreography lets services react to events; orchestration gives one workflow component responsibility for the next command. Neither creates a distributed ACID transaction.

Define compensating actions before implementation. A refund is not literally an undo of a captured payment—it is a new auditable business action that can also fail.

• Durable workflow state
• Idempotent steps
• Timeouts and retries
• Compensating actions
• Manual recovery path
• Visible business status

Make partial progress visible

Evolve data without stopping consumers

Use expand-and-contract changes: add the new representation, make producers and consumers compatible, migrate data, switch reads and writes, then remove the old shape. Deployments between those steps must remain safe.

For events, prefer additive changes and tolerant readers. A schema registry can enforce compatibility, but teams still need semantic discipline.