A capability stays maintainable only when the team can explain every state, retry, and piece of residual data—not merely show one successful run. Deletion is a workflow, not one SQL statement. Mark inaccessible with deletionId, publish through outbox, and retain tombstones against late resurrection.
Data design covers atomic writes, concurrent access, schema migration, crash recovery, and cleanup. One successful save says nothing about power loss, full storage, or reopening with an older version.
Questions the design must answer
List non-negotiable invariants before selecting performance knobs. Tuning can roll out gradually; identity, permission, and terminal-state rules cannot drift at runtime.
- Each processor reports deletionId, scope, and completion time; the coordinator waits or escalates by policy, and retries without rereading deleted payload.
- Give state one owner, a version, and terminal states; callbacks may mutate only the version that created them.
- Ship conservative defaults, server-side ceilings, and a rollout switch instead of trusting browser-provided numbers as resource budgets.
The delivery standard for Propagating Deletion Across Databases, Caches, and Objects is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Edge cases are part of the feature
Failure and success must share one state model. An error toast that neither releases resources nor propagates a terminal state leaves dirty work for the next recovery attempt.
- Deleting the primary row before emitting loses keys needed downstream, while waiting on a long cache TTL violates the user promise.
- Refresh and network change start two recovery paths, and duplicate side effects look like two genuine user actions.
- User or task IDs in metric labels create high-cardinality cost and leak unnecessary identity into diagnostics.
Prove that it works with evidence
Write the expected state trace before injecting faults. At every phase, reconcile user-visible outcome, both protocol endpoints, persistent records, and resource counts to prove the loop.
- Create a canary across every copy, pause one consumer during deletion, and inject a stale update; after recovery the canary is unreadable with complete evidence.
- Race refresh, cancel, timeout, and remote completion in one scheduling window; assert one terminal state and one side effect.
- Cover direct, relayed, weak-network, background-tab, and mobile paths; do not rely on averages or one successful screenshot.
Completion is not one passing path. Every terminal state reconciles, automation stays below user intent, and every operational cost has an explicit ceiling.