"Place an order" and "an order placed during the market open surge is acknowledged within 200ms at p99" — Zerodha needs both. Which one actually constrains the architecture, and why is that not obvious?

Why the functional requirement constrains almost nothing

"Place an order" can be satisfied by a single script writing to one database on one box. It can be satisfied by a globally replicated event-sourced platform. A functional requirement tells you what to build; it very rarely tells you how to shape it. Nearly every structure satisfies it.

What the quality requirement removes from the table

"200ms at p99 during the open" deletes most of those options in one line:

• Synchronous calls to anything with variable latency leave the critical path, because p99 composes badly. Three dependencies at p99 = 100ms each do not give you 300ms; they give you a tail far worse.
• Shared infrastructure with unrelated workloads becomes a risk, because the analytics query that runs at 09:15 is now a trading incident.
• Garbage-collection pauses, connection-pool saturation and cold caches stop being operational trivia and become design inputs.
• The order path gets physically separated from portfolio views, statements, and everything else a customer might do while the market opens.

The judgement this teaches

The most useful reframing for a trading platform is that the market-open burst is not a load-testing scenario, it is the design point. A system built for average load and hardened later has the wrong shape: isolation cannot be retrofitted onto a codebase that assumed one database and one pool.

Note also that the p99 target is more demanding than an average target and cheaper than a p99.99 target. Which percentile is chosen is itself an architectural decision, and it should be argued from what a customer actually experiences when it is missed.