A travel platform must be able to answer, months later, who changed a booking and what they saw. What does that require architecturally, and why is a log table insufficient?

Why a log table is insufficient

A log table records what the application chose to record, from the paths that remembered to record it. Auditability requires something stronger:

1. Completeness. Every mutation, from every path — the API, the internal admin tool, the batch job, the support correction, the integration. A single unlogged path makes the audit trail unreliable, and unreliability is contagious: an auditor who finds one gap discounts the whole record.

2. Attribution to a real principal. The acting human or system, carried through every layer including asynchronous work. The characteristic enterprise failure is that most mutations are attributed to a service account, so the system has an audit log and no auditability.

3. Immutability. If the application can modify or delete audit records, the record proves nothing. This means append-only storage with separate credentials, ideally in a system the application cannot write to destructively.

4. Before-and-after state, not just "record updated". "Who changed this price and from what" is the question actually asked.

5. Retention beyond the life of the record itself. A booking deleted last year still has an audit history, and that history must survive the deletion.

6. Authorisation context. Not only who acted but under what permission, because "were they allowed to" is usually the real question.

The additional requirement in the question

"What they saw" is a materially harder requirement than "what they changed", and it appears in regulated and support contexts more often than teams expect. It means logging reads of sensitive data, which is high volume and easy to under-scope. The workable approach is to define a class of sensitive reads — payment details, personal data, another customer's records — and log only those, rather than attempting to log everything.

The architectural consequences

• Audit emission is part of the transaction, not a best-effort side effect. Use a transactional outbox so the audit record and the change commit atomically and the record is published reliably.
• Identity propagates everywhere, including through queues and scheduled jobs. This is the same propagation problem as correlation identifiers and should reuse the same mechanism.
• The audit store is separate, with its own retention, access control and — critically — its own restricted write path.
• Reads of the audit log are themselves audited, since access to the audit trail is privileged.

Why this is architectural rather than a feature

Because it is a property of every write path, and the write path is everywhere. Retrofitting means touching every path, backfilling attribution that in many cases no longer exists, and reconciling the new history against reports already issued from the old state. That is a rebuild, not a sprint — which is why auditability belongs on page one of the architecture document rather than in a compliance appendix.