Operation State Architecture
Model long-running transfers without lying to the user
This is the core on-chain finance frontend stage: distinguish user intent, wallet submission, local pending continuity, chain observation, backend records, and business reconciliation.
Design a transfer state model that survives reloads, prevents duplicate action, and explains uncertainty honestly.
State Machines
A single status string hides the important part of the system. Strong candidates can name each owner of truth and make transitions explicit.
Design the operation state machine for a transfer
ArchitectureSenior50mModel draft, signing, submitted, locally pending, chain finalized, reconciliation pending, reconciled, retryable failure, and terminal failure.
This is the first authored guide because it anchors the whole roadmap.
Make illegal transition states unrepresentable
CodingSenior45mUse TypeScript unions and transition functions so impossible UI states cannot compile.
This is where frontend architecture and TypeScript interview skills meet.
Pending Continuity
A user may refresh while a wallet transaction is pending. The frontend can own continuity without pretending to own the canonical business record.
Design IndexedDB pending-operation persistence
ArchitectureSenior45mChoose fields, expiry, schema versioning, conflict handling, and cleanup rules for pending transfer records.
The key phrase: frontend owns continuity; backend owns canonical records.
Merge local pending records with backend transfers
CodingSenior45mImplement deterministic merge rules that avoid duplicates and preserve user-visible progress after refresh.
Be explicit about matching keys: client operation ID, backend ID, tx hash, and timestamps.
Failure Semantics
Finance UI must distinguish rejected, unknown, retryable, finalized, and reconciled outcomes without encouraging unsafe repeated actions.
Classify transfer failures by owner and recovery
ArchitectureSenior35mSeparate wallet rejection, network mismatch, API timeout, duplicate operation, chain failure, and reconciliation delay.
The answer should drive UI copy, retry buttons, disabled states, and support escalation.
Design idempotency for a submit button
System DesignSenior40mSpecify client operation IDs, backend idempotency keys, disabled states, reload behavior, and audit visibility.
Never solve double-transfer risk with only a disabled button.