Database-per-Service Pattern in Microservices

Each microservice should own its database exclusively.

• The moment two services share a database, schema changes require coordination, storage technology choices are coupled, and you've recreated the monolith at the data layer.
• In practice, separate schemas with strict access grants enforce the boundary without requiring separate database instances on day one.

Cross-service data access patterns:

• Synchronous API call — gives you fresh data but creates a runtime dependency; if inventory is down, the order service can't display product names
• Event-driven denormalization — the order service maintains a local read replica updated by consuming inventory events; fast and resilient, but data can lag by 100ms to a few seconds
• Choose by consistency requirement: synchronous for writes and low-volume fresh reads, event-driven for high-traffic read paths where slight staleness is acceptable

The dual-write problem:

• Saving to the database and then publishing to Kafka creates a crash window — if the application crashes between those two operations, the event is lost forever
• The Outbox pattern solves this: write the event to an outbox table in the same database transaction as the business entity; a separate process relays outbox rows to Kafka
• Polling is simpler (a @Scheduled method); Debezium WAL tailing delivers in under 100ms but requires a Kafka Connect cluster

I recommend the Outbox pattern at every point where state changes need reliable event publishing — it's the only way to guarantee atomicity between the database write and the event.