Part 2 · 2 chapters · ~18 min

Frontend System Design on a Deriv Surface

Round one's high-traffic onboarding question answered again with a method (clarify, measure, fix, add resilience, then the AI assistant as a guarded layer that must beat the fixed baseline), then the incremental method on a cashier, KYC and a trade ticket with streamed prices and staleness rules.

4

The onboarding question, answered properly

Your round-one answer had the right instinct: an AI assistant does not fix a slow, error-prone flow, and the errors would just move into the chat. What it needed was a method, so that the instinct reads as judgement rather than objection.

the answer's skeleton
  1. Restate the problem and ask three questions. State your assumptions.
  2. Measure: per-step RUM, joined traces, an error taxonomy.
  3. Fix in order of impact: first load, the slow step, the inconsistent errors.
  4. Resilience: drafts, idempotency, designed degraded states.
  5. The AI layer sits inside the validated form, and the model never submits.
  6. Rollout with four metrics. The assistant has to beat the fixed baseline.
what to keep from round one
Keep these: a provider-agnostic model layer, Zod validation of model output, SSE for streaming the assistant's responses, and structured UI blocks the model can emit. Present them in the AI-layer step, after the measurement and the fixes, as the safe way to add the assistant rather than the first thing you reach for.
THE ONBOARDING QUESTION, ANSWERED AGAIN
round one's question: a high-traffic onboarding flow, slow, with inconsistent errors, and Product wants an AI assistant
swipe the figure sideways, or tap expand for full screen
1/6
restate, ask
Restate and ask: "Before redesigning, three questions. Slow where: the first load, a particular step, or submission? Which errors: client exceptions, API 4xx or 5xx, third-party KYC failures? What outcome is the AI assistant meant to change: completion rate, time to complete, support contacts?" Then say what you would assume if they do not know.
5

Cashier, KYC and trading, incrementally

clarify, core, then grow
  1. Clarify users, devices, never-events and numbers.
  2. Build the core: one API with an idempotency key.
  3. Money states, shown honestly, plus holds.
  4. KYC and limits: asynchronous, step-up, configuration-driven.
  5. The trade ticket: streamed prices, visible age, stale prices disable buying.
  6. Platform concerns, each stated as a trade-off.
code
// the trade ticket's core rule, small enough to write live
function canBuy(q: { price: number; ts: number }, now = performance.now(), maxAgeMs = 1_500) {
  return now - q.ts <= maxAgeMs;                         // a stale price never buys
}
// render: show the age, disable the button, announce politely (throttled) for screen readers
<button disabled={!canBuy(quote)} aria-describedby="price-age">Buy at {fmt(quote.price)}</button>
<span id="price-age">{ageLabel(quote.ts)}</span>
// send the price the user saw plus a tolerance; the server decides
api.placeOrder({ symbol, side: 'buy', seenPrice: quote.price, maxSlippageBps: 20, idempotencyKey });
depth on demand
Each increment links to a full course part: Trust P3 to P5 (cashier, wallets, trading UIs), FSD P8 and P9 (real time and trading), Platformization P4 (regulatory variance). If the interviewer goes deep on one increment, go deep there. If not, keep growing the design.
SYSTEM DESIGN ON A DERIV SURFACE
the incremental method applied to a cashier, KYC and a trade ticket, each grown from a working core
swipe the figure sideways, or tap expand for full screen
1/6
clarify
Clarify (two minutes): who uses it, on what devices (many traders on mid-range Android, web and the app's WebView), which payment methods and countries, what must never happen (a double withdrawal, a trade at a stale price), and the numbers (deposits per minute at peak, price ticks per second).