Can an old update restore a deleted account?
The latest arrival is not the latest source version.
The question
Lumen maintains a current-state account table. The source contract gives every account mutation a monotonically increasing version; a tombstone is a deletion that must persist across replay. An AI-generated merge keeps whichever row arrived last.
| accountId | Source version | Source state | Arrival | |
|---|---|---|---|---|
| Change A | a7 | 1 | Active | 09:00 |
| Change B | a7 | 3 | Deleted | 09:02 |
| Change C | a7 | 2 | Active | 09:05 |
Authored contract: versions order mutations for this account; no same-version conflicts exist in the packet.
For each accountId, overwrite current state with the last arriving row. The deletion branch removes the stored record completely.
“What should the retained state be, and what must a replay preserve?”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Use the entity grain
What would you do here? Open the move you’d make.
Append every delivery as another current account
Tempting, but it misses something. A delivery log is not a current-state table.
Merge current state by accountId
The strong move. A current-state model has a different grain from an immutable event count.
Deduplicate by arrival timestamp
Tempting, but it misses something. Arrival time does not identify the account or its authoritative version.
See how a strong candidate says it
“The current table has one row per accountId. eventId would identify delivery events, but it would not select the current account state. I compare source versions within a7.”
Why it works: A current-state model has a different grain from an immutable event count.
Step 2: Order by the source contract
What would you do here? Open the move you’d make.
Keep the last arrival
Tempting, but it misses something. This resurrects a deleted account from older source data.
Prefer active rows to avoid losing customers
Tempting, but it misses something. That changes the lifecycle contract.
Retain version3 despite the later version2 arrival
The strong move. The stated monotonic source version is the ordering authority in this packet.
See how a strong candidate says it
“Version3 is newer than version2, even though the active version2 arrives at09:05. I retain the deleted version3 and reject the older update. I do not use wall-clock arrival to order source mutations.”
Why it works: The stated monotonic source version is the ordering authority in this packet.
Step 3: Retain a deletion boundary
What would you do here? Open the move you’d make.
Retain the deletion version across replay
The strong move. A tombstone can be necessary state even when the visible current record is deleted.
Erase the key and version immediately
Tempting, but it misses something. The consumer then cannot reject an old replayed active snapshot.
Keep every deleted customer attribute forever
Tempting, but it misses something. The packet needs a deletion boundary, not indefinite retention of all personal data.
See how a strong candidate says it
“I keep an account-level deletion marker with version3 for at least the supported replay horizon. Removing all key/version state would let a replayed version1 look like a new account.”
Why it works: A tombstone can be necessary state even when the visible current record is deleted.
Step 4: Test older, equal and newer versions
What would you do here? Open the move you’d make.
Test replay and require the source policy for a later version
The strong move. Rejecting old data must not invent a policy for future mutations.
Guarantee that the account can never return
Tempting, but it misses something. The packet defines no behavior for a future valid version4.
Use a larger arrival-time delay as the fix
Tempting, but it misses something. A delay does not enforce source ordering.
See how a strong candidate says it
“I would replay versions1 and2 and verify that a7 stays deleted at3. An equal version3 is idempotent. A later version4 would follow the source’s explicit reopen policy; none is provided here.”
Why it works: Rejecting old data must not invent a policy for future mutations.
The answer, in short
- Decision
- Retain a7’s deletion at version3 and reject older versions.
- Because
- Arrival order puts version2 last; source order puts version3 last.
- What would change it
- A documented non-monotonic version scheme, conflict rule or valid later reopen event would require a different ordering contract.
Common traps
- Using processing arrival as source order.
- Deleting the version boundary before the supported replay horizon.
Check your answer
- Did you select accountId as current-state grain?
- Did version3 beat later-arriving version2?
- Did you retain the deletion version?
- Did you leave unknown version4 behavior to the source contract?
Last reviewed Nov 10, 2026