# Orders architecture decision context

The orders service currently stores mutable order rows and emits best-effort
webhooks. Auditors need a complete history of state transitions, and support
must be able to reconstruct an order at a prior point in time.

Options discussed:

1. Keep the current model and add an append-only audit table.
2. Adopt event sourcing for orders and build read projections.
3. Use database change-data capture as the audit history.

Event sourcing improves traceability and replay, but adds projection rebuilds,
event versioning, eventual consistency, and operational complexity. The team
has event-stream experience, but the reporting service expects synchronous
reads. The decision applies only to the orders bounded context.