You are designing checkpoint-and-rollback for a component whose work includes writing files, calling remote services, and holding open connections. Where does the approach of snapshotting and restoring an object's internal state stop working, and what do you do instead?

## What a memento can and cannot reach A memento is a copy of the originator's *own in-memory state*. Restoring it rewinds exactly that and nothing else. Anything that already crossed a boundary — the process boundary, the disk, the network, another object's reference graph — is outside its reach. Interviewers use this to separate people who know the pattern from people who have shipped rollback. ## Failure class 1 — externally visible side effects If the operation wrote a file, sent an email, published an event, charged a card, or updated a row another service already read, restoring the snapshot leaves the world inconsistent: internal state says "never happened", the world says otherwise. The remedy is not restoration but **compensation** — an explicit action that approximately reverses the effect: | Effect | Compensation | Caveat | |---|---|---| | File written | Delete or restore prior version | Someone may have read it | | Event published | Publish a reversal/cancellation event | Consumers must handle it | | Payment charged | Refund | Fees, timing, ledger shows both entries | | Email sent | Send a correction | Cannot unsee it | This is the **saga** model: a long-running operation is a sequence of local steps, each with a compensating step, executed in reverse on failure. Compensation is *semantic* rather than exact — the system reaches a consistent state, not the identical prior state. Design moves that shrink the problem: - **Defer effects past the point of no return.** Accumulate intended effects, snapshot freely while everything is in memory, and flush the effects only when the operation commits. This is the outbox idea and the reason "pure core, effectful shell" architectures are easy to checkpoint. - **Make effects idempotent and keyed.** With an idempotency key, a retry after rollback does not double-charge. - **Two-phase style staging.** Write to a temp file and rename atomically on commit; hold messages in an outbox table committed with the state change and published after. ## Failure class 2 — live resources in the snapshot Sockets, file handles, database connections, GPU buffers, thread-local context, open transactions, timers, and subscriptions are *identities of live things*, not values. Capturing one is a bug in waiting: by restore time it may be closed, expired, or owned by someone else; restoring installs a stale handle that fails on first use, sometimes much later. The rule: **exclude non-value state from the memento and re-acquire it on restore.** Capture the descriptor (path, URL, offset, query parameters), not the handle. Have the originator expose an explicit `reattach()`/`rehydrate()` step, and document which fields are transient — this is also why serialization frameworks have transient/ignore markers. ## Failure class 3 — shared and aliased state If other objects hold references *into* the originator's structures, or the originator already notified observers, restoring it alone breaks the graph: caches and indexes elsewhere still describe the newer state, observers acted on an event that is now un-happened, and a parent may hold a child that the restored state no longer contains. Implications: - The snapshot boundary must be a **consistency unit** — the whole aggregate that must move together — not a convenient single object. - After restore, **invalidate or rebuild** dependents: clear derived caches, re-emit a coarse "state replaced" notification rather than fine-grained diffs, and re-establish parent/child links. - Prefer value semantics inside the snapshot boundary so no external aliases exist in the first place. ## Concurrency Capturing a snapshot of state that other threads are mutating yields a torn, never-actually-existed state. Capture under the same lock or consistency scope as the mutation, or make the state immutable so a reference *is* a consistent snapshot. Similarly, a restore that lands while another thread is mid-operation can clobber that work; restore usually needs to be a quiescent, exclusive operation. ## Persistence and lifetime Once mementos are written to disk or shipped elsewhere, they inherit every persistence concern: schema evolution (an old snapshot describes a state shape that no longer exists — version-stamp and migrate or reject), retention and cleanup, and data governance if the state holds personal data or secrets (encryption, deletion requests, audit). ## The honest product answer Decide, per action, which of three categories it falls into and make the UI reflect it: **undoable** (pure in-memory, snapshot works), **compensatable** (we can issue a reversal — offer "undo" with a delay window or an explicit "cancel" that emits compensation), and **irreversible** (require confirmation, never label it undo). The frequent real-world design is a **grace window**: hold the effect for a few seconds, expose undo during that window, then commit — which converts an irreversible effect into a snapshot-restorable one for as long as it has not escaped.