Operations guide

Degrade optional work.
Protect transaction truth.

“Keep running” should mean isolating non-critical failures—not pretending payment, inventory or security work succeeded.

TH / DOCS
Principle→Boundary→Verification
implementation guidance · not a public API guarantee
01 / FAILURE CLASSES

Decide what may degrade

Analytics, recommendation feeds or non-essential notifications can often fail asynchronously. Payment verification, stock reservation and security checks should fail explicitly when correctness cannot be guaranteed.

02 / OBSERVABILITY

Give every incident a reference

Log structured context and a stable reference without leaking credentials. Track latency, database time, queue age and provider error classes before guessing at root causes.

03 / RECOVERY

Retry behind safe boundaries

Use queues, idempotency keys and reconciliation jobs where recovery is expected. Keep operator tools for replay or repair auditable.

Project-specific contracts win.

These pages describe Thonem implementation patterns. Exact endpoints, payloads, credentials, retry rules and provider capabilities must be taken from the deployed project and its provider documentation.