Question 1

How do you model escrow fund-holding so that money is neither accessible to buyer nor seller until release conditions are met?

Accepted Answer

Create a dedicated escrow ledger account per transaction. When a buyer initiates escrow, debit their wallet and credit the escrow account — funds are now in a state of HELD. The escrow account is owned by the platform, not either party, so neither can withdraw from it directly. The escrow record in the database carries a state machine: CREATED -> FUNDED -> RELEASED or REFUNDED or DISPUTED. Release conditions (delivery confirmation, time-based expiry, multisig approval) are evaluated by the escrow service before issuing a debit from escrow and a credit to the seller. All state transitions are logged immutably with timestamps and the actor who triggered them.

Question 2

What release conditions should an escrow service support, and how do you implement time-based automatic release?

Accepted Answer

Common release conditions include: explicit buyer confirmation, delivery webhook from a logistics provider, multisig approval from both parties, and time-based auto-release after a no-dispute window. For time-based release, store a release_at timestamp on the escrow record and run a periodic job (cron or a queue consumer reading a scheduled-events table) that queries for escrows where release_at

Question 3

How would you design the dispute resolution flow for an escrow service, including escalation to human review?

Accepted Answer

When a buyer raises a dispute, transition the escrow to DISPUTED and freeze it — neither auto-release nor seller withdrawal can proceed. Store a dispute record linked to the escrow with the claimant ID, reason code, supporting evidence URLs, and a deadline for the other party to respond. Implement tiered resolution: first offer a negotiation window where both parties can propose a split (e.g., 80% seller / 20% refund); if unresolved within N days, escalate to an internal agent queue. Agents see the escrow state, transaction history, and uploaded evidence. Their decision is recorded with an agent ID, ruling rationale, and timestamp, and the system executes the ruling by debiting the escrow account and crediting the appropriate parties. Maintain a full audit trail for regulatory compliance.

Question 4

How do you ensure escrow funds are safe against system failures mid-transaction — for example, a crash between debit and credit?

Accepted Answer

Use a write-ahead log (WAL) or an outbox pattern. Before performing any escrow state change, write the intended operation to an outbox table in the same database transaction as the state update. A separate relay process reads the outbox and executes downstream effects (crediting the seller, firing webhooks) with at-least-once delivery semantics. Each outbox event carries an idempotency key so replaying it is safe. For cross-service fund moves, adopt a saga: each step publishes a domain event; compensating transactions undo previous steps if a later step fails. Use a saga orchestrator or choreography log to track which steps completed, enabling recovery after a crash without orphaned funds sitting in limbo indefinitely.

Escrow Service Low-Level Design: Fund Holding, Release Conditions, and Dispute Resolution

Escrow Model

Escrow Transaction Schema

Funding

Release Conditions

Release Flow

Dispute Workflow

Partial Release for Milestones

Expiry Handling

Multi-Currency and FX Rate Locking

Audit Trail