Peak-hour trading UI: reliability as a product requirement

Trading platforms do not get to fail quietly at 9:15 AM. Users are not browsing — they are acting under time pressure, and a hung spinner is a business event.

Separate calm paths from hot paths

Not every screen needs the same reliability budget. Order entry, positions, and live quotes sit on a different plane than settings or help articles.

For Share.Market we treated the hot path as its own system boundary:

• Dedicated data contracts for market-critical views
• Explicit loading and degraded states (stale quotes labeled as stale)
• Client-side budgets for retries so a flaky dependency does not amplify load

Observability is part of the UX

If you cannot see p95 for key interactions during market open, you are guessing. Dashboards that only track HTTP 500s miss the failures users feel: empty states that never resolve, charts that paint late, websocket reconnect storms.

The architecture review for a trading frontend is incomplete without: what does the user see when X fails, and how do we know it happened?

Team shape matters

Owning system design across a small team means reviews are not style nits — they are where you protect the peak-hour bar. Cross-team sync exists so a backend change does not silently break the contract the UI depends on during the loudest hour of the day.