Database per service

Each service owns its schema and is the sole writer of its data. Other services access data only through APIs or events, not shared tables. This enables independent schema evolution but complicates cross-service queries, joins, and transactional consistency.

Trade-off: autonomy and encapsulation versus reporting, analytics, and immediate read-your-writes across aggregates.

On interviews: explain how you would show a dashboard that spans order and inventory data without joining databases.

Common pitfalls: shared database with "logical" separation; read replicas used as integration layer; breaking encapsulation for convenience SQL.

Checklist:

• Enforce write ownership per service schema.
• Expose query needs via APIs, events, or read models.
• Plan migrations without cross-schema locks.
• Accept eventual consistency for cross-domain reads.