Trade TerminalI kept nodding in meetings. Then I drew it out.
You know that moment when someone drops “WebSocket”, “REST”, “balance locking” — and you go mm-hmm even though you're not totally sure how the pieces connect? That was me. Not because I didn't care. I just learn better when I can sketch it and click it. So I mapped a trading-terminal-style system on paper, then built a small mock I could break on purpose. Not to become a backend engineer overnight — just to stop faking fluency in the room next time.
A trading screen looks like dark UI and numbers. Underneath it's messier: things updating live all the time, orders that have to stay correct, and awkward moments when the connection hiccups. My gap wasn't Figma — it was vocabulary. And honestly, the confidence to ask what felt like dumb questions.
I kept the scope small on purpose. If I could explain the architecture without googling every other word, and the mock behaved when the feed dropped or I ran out of balance — that counted as a win for me.
The split that finally clicked
Someone drew this for me, basically: stuff that never stops moving (prices, order book) vs stuff that should happen once, correctly (place order, check balance). Live streams → WebSockets. Transactions → REST. Once I saw it that way, the keywords stopped feeling random.
Early layout sketch: WSS streams for chart and depth, REST for POST /order. Validation notes baked in before I wrote a line of mock code.
Database before pretty pixels
I know — designers usually sketch UI first. I did the opposite here: users, wallets, locked balances, minimum order sizes. The rule that stuck: lock the money before you mint an order ID. Otherwise the interface can look fine while the system is lying to you. I learned that one by breaking my own mock.
Schema + architecture in one view: tables and constraints up top, REST vs WSS split below — including the 4 fps throttle note so the browser doesn't freeze.
Balance locking
Money gets set aside before an order ID even exists.
Price precision
Prices snap to the allowed increment — I felt that one in the mock.
Circuit breaker
When trading pauses, the UI should say no — not go quiet.
1:N relations
One user, many orders. One pair, many orders. Keeps the story straight.
When the feed drops
Real-time UX is also “what do we show when things break?” Short blip? A small orange nudge is enough — don't panic the user. Longer than about two seconds? Blur the book, kill submit, show a clear banner. Once I tried trading on stale silence in the mock, it felt obviously wrong.
What I implemented: quick lag → orange warning, submit still works. Long disconnect → suspended state. Form checks balance first, then minimum size, then lets you submit.
Connected
Live book, prices moving. Submit when the form checks out.
Brief lag
Under ~2s — a nudge, not a meltdown. Submit still OK.
Suspended
Blur, RECONNECTING…, banner up. Don't trade on silence.
What this is (and isn't)
✓ Me figuring things out — diagrams first, then a sandbox I could break on purpose.
✓ Product and UX thinking on a problem that's usually backend-heavy.
✗ Not a real exchange. Not financial advice. Please don't trade your rent money here.
✗ Not me claiming I'm a senior backend person — just someone curious who did the homework.