Prioritizing Nonfunctional Requirements for Exchange Platforms

Hello. This first module is about the part of system design that determines whether the rest of the architecture is defensible: turning an ambiguous request such as “build an exchange that cannot go down” into prioritized, testable requirements.

For a senior AWS DevOps interview, do not begin by naming services. Begin by establishing what must be protected, how success is measured, what failure is tolerable, and which constraint wins when requirements conflict. This lesson gives you a reusable way to do that for an exchange platform, including the assumptions you should state when an interviewer has not supplied numbers.

By the end, you should be able to give a concise requirements brief covering availability, latency, throughput, scalability, security and compliance, RTO, RPO, and cost—then defend the important trade-offs.

---

Start with scope, users, and priorities—not an AWS diagram

An “exchange platform” is not one workload. It has distinct journeys with very different consequences of failure:

• Order entry and cancellation: accepting, validating, sequencing, and acknowledging orders.
• Matching and execution: determining fills in a deterministic order.
• Account and risk controls: balances, limits, margin, and permission checks.
• Market data: distributing quotes, trades, and order-book updates.
• Customer-facing UI and public APIs: login, portfolio views, deposits, statements.
• Back-office and compliance systems: audit, reconciliation, reporting, surveillance.

A lead-level response identifies these differences immediately. It is unsafe to give all components a single generic target such as “99.99% availability and low latency.” A portfolio page may tolerate a few seconds of delay; order cancellation during a volatile market may not. Market-data consumers may accept dropped intermediate updates if they can resynchronize; the ledger cannot silently lose a committed execution.

In an interview, take about two minutes to ask questions in six categories:

Area	High-value clarification questions
Business scope	Is this retail spot trading, institutional API trading, or latency-sensitive market making? Which markets and regions are in scope?
Critical journeys	Is the priority accepting orders, cancelling orders, matching fairly, account visibility, or market-data delivery? What must remain available during partial failure?
Load shape	What are normal and peak order rates? What is the burst factor during volatility? How many concurrent WebSocket clients?
Latency	Is the target client-perceived API latency, internal order-processing latency, or tick-to-trade latency? Which percentile matters?
Correctness and recovery	Can data be eventually consistent anywhere? What data loss is acceptable after an AZ, Region, or operator failure?
Constraints	Which regulations, retention rules, jurisdictions, cloud regions, and monthly cost envelope apply?

The point is not to interrogate the interviewer endlessly. It is to expose architectural forks early. A system serving global retail traffic through the public internet does not have the same latency requirement as a colocated or private-connectivity market-making workflow. Likewise, an exchange that must preserve a regulated audit trail has fundamentally different recovery requirements from a consumer app that can reconstruct some activity from logs.

This short segment is useful interview preparation because it models how to turn ambiguity into design boundaries.

When details are unavailable, state explicit working assumptions rather than pretending you know the answer:

“I’ll assume a regulated, regional digital-asset exchange with retail and institutional API users. The matching path is business-critical; portfolio reporting can degrade. I’ll design for a 10-fold short-lived volatility burst, and I’ll separate public user latency from internal execution latency. I would validate all numerical targets with product, risk, compliance, and finance owners before committing to an architecture.”

That sentence signals ownership: you make progress under uncertainty, but distinguish facts from assumptions.

A practical priority order

For a financial exchange, a sensible default ordering is:

1. Correctness, integrity, and fair sequencing of accepted orders and executions
2. Security and regulatory obligations
3. Availability of order cancellation, risk controls, and the matching service
4. Recovery objectives for regional or wider failures
5. Tail latency and predictable latency variation
6. Sustained throughput and burst absorption
7. Cost and operational complexity, subject to the preceding constraints

This is not universal. A low-latency market-making venue may place internal latency and jitter immediately after correctness. But cost should not casually displace integrity or regulatory requirements. The senior move is to say which priority applies and why.

---

Make each requirement measurable

A requirement is useful only if a team can measure it, test it, and decide whether it was met. Compare:

• Vague: “The trading API should be fast.”
• Measurable: “For authenticated placeOrder and cancelOrder requests received in the primary Region, $99.9\%$ shall receive a definitive acknowledgement within 50 ms, measured at the API edge over a rolling 30-day period, excluding client network time.”

The second statement still needs product validation, but it establishes the essential elements:

1. Scope: Which operation and which users?
2. Measurement point: Client, edge, service, or matching engine?
3. Statistic: Percentile, rate, or maximum?
4. Target: A number and unit.
5. Measurement window: Five minutes, one day, 30 days?
6. Conditions and exclusions: Planned maintenance? Malformed requests? Client disconnects?
7. Owner and consequence: Who responds when it is missed?

SLIs, SLOs, and SLAs

An SLI is the observed metric. An SLO is the internal target placed on that metric. An SLA is an external agreement with stated consequences, such as service credits or contractual penalties.

For transaction availability, a strong definition is based on valid requests rather than “the load balancer answered a health check”:

$$\text{availability}=\frac{\text{valid requests completed correctly}}{\text{all valid requests}}$$

For an order API, “correctly” must mean more than HTTP $200$. A request that returns success but loses an accepted order is not available in the business sense. Conversely, a timeout does not necessarily mean an order was not accepted; the system needs idempotency and an order-status query to resolve the outcome safely.

Read the following selected portions of Google’s Service Level Objectives chapter. It provides the terminology and, more importantly, the discipline of measuring the user-relevant behavior rather than whatever is easiest for the platform to expose.

Latency: use percentiles and separate the clocks

Average latency is particularly misleading in exchange workloads. Suppose $99\%$ of orders are acknowledged in 10 ms and $1\%$ take 2 seconds during a burst. The mean may look acceptable while the affected traders cannot manage risk or cancel stale orders.

Use percentile objectives such as:

• $p50$: typical experience and baseline capacity behavior
• $p95$: broad customer impact
• $p99$ or $p99.9$: tail behavior, queuing, noisy-neighbor effects, and overload symptoms

But do not combine incomparable clocks. Define separate measurements:

Latency measure	Example meaning	Why it matters
Client-to-edge	Client sends request until edge returns response	User-perceived API performance, including network variability
Edge-to-acknowledgement	Request reaches AWS edge until an order outcome is returned	Platform performance under your operational control
Internal sequencing latency	Validated order enters matching path until ordered/committed	Fairness, engine behavior, and congestion
Market-data freshness	Exchange event time until a subscriber receives it	Trading decisions and stale-market risk
Recovery latency	Failure declared until safe service is restored	Operational resilience, distinct from request latency

For truly latency-sensitive trading, jitter matters alongside the percentile. Jitter is unwanted variation in latency. A stable 200 microsecond path may be more usable than a path that is typically 100 microseconds but intermittently stalls for milliseconds.

---

Work from service classes, not a universal target

The following provisional brief is an interview example, not a promise that every exchange should make. Its values demonstrate the needed shape of a requirements document. Say explicitly that you would negotiate the actual values.

Example scenario

Assume a regulated exchange operating primarily in one AWS Region, serving retail users and institutional API clients. It supports a peak of 20,000 order commands per second, normal traffic of 4,000 commands per second, and bursts up to 10 times normal traffic for five minutes during market volatility. It must preserve an auditable order and trade history. Public global users are out of scope for microsecond execution guarantees.

Priority	Requirement	Measurable target and acceptance condition
P0	Order correctness	Every accepted order, cancellation, and execution has a unique immutable identifier, ordered event record, and idempotent replay behavior. Reconciliation finds zero unexplained differences between execution log, ledger, and customer balances.
P0	Matching fairness	For each instrument partition, accepted commands are sequenced deterministically using an authoritative clock and recorded sequence. No later command may be applied ahead of an earlier accepted command without a defined, auditable rule.
P0	Order-path availability	$99.95\%$ of valid order and cancellation requests receive a correct definitive outcome in a rolling 30-day window. A safe “cancel-only” mode is permitted if new trading cannot be conducted correctly.
P0	Order-path latency	$p99.9$ edge-to-acknowledgement latency under 50 ms at normal load; under 150 ms at the stated burst load. Track rejected, accepted, and cancelled orders separately.
P1	Market-data freshness	$p99$ event-to-subscriber delivery under 250 ms for subscribed clients in-region. A subscriber can detect sequence gaps and request a snapshot/resynchronization.
P1	Scalability	Sustain 20,000 commands per second and 200,000 market-data updates per second for 60 minutes; survive a 10-fold five-minute burst without losing accepted commands. Define overload behavior, such as rate limiting or admission control, before saturation.
P1	Account API	$99.9\%$ availability and $p99$ under 300 ms for balances and portfolio reads. During severe failure, show a timestamped last-known view rather than presenting stale data as current.
P0	Recovery	Regional recovery targets are stated separately for trading capability and for analytical/reporting functions; see the RTO/RPO section below.
P1	Cost	Meet the targets within an approved baseline monthly operating budget and a separately modeled peak-event cost. Any latency-optimized dedicated capacity needs a documented benefit and capacity-risk review.

Notice the deliberate use of safe degraded modes. “All functionality remains available” is often less safe than declaring that new orders are paused while cancellation, risk reduction, reconciliation, and customer communication remain available. That is a product and risk decision, but DevOps should require it to be explicit and testable.

Throughput and scaling: specify the load shape

“Handles 20,000 TPS” is incomplete. Ask:

• Is that commands per second, executions per second, or market-data messages per second?
• Is it sustained or a one-second spike?
• What is the peak-to-normal ratio?
• Is load evenly distributed across instruments, or does one highly traded asset create a hot partition?
• What message size applies?
• What should happen when the platform reaches capacity?

The final question is essential. Horizontal scaling can increase overall throughput, but it cannot always divide one instrument’s strictly ordered matching stream across arbitrary workers. An exchange may partition by trading pair or instrument while retaining deterministic ordering within each partition. Requirements must reveal this before an architecture is selected.

---

Recovery targets are business commitments, not backup settings

RTO is the maximum time permitted to restore a defined level of service after an outage starts. RPO is the maximum amount of data that may be absent after recovery, measured relative to the last known recoverable state.

For an exchange, avoid the vague statement “RPO is zero.” Ask: zero loss of what?

• Accepted orders and executions
• Ledger postings and balances
• Customer-uploaded documents
• Market-data cache
• Observability data
• Noncritical analytics

The core order and ledger record may require an effective RPO of zero within a narrowly defined failure domain, while analytics could accept an RPO of several hours. A cache may have no RPO because it is intentionally reconstructible.

A defensible recovery requirement includes the failure scope and restored capability:

Failure scenario	RTO	RPO	Restored service definition
Single instance or AZ impairment	5 minutes	0 for accepted orders and ledger events	New orders, cancellations, risk checks, and matching resume safely; failed requests can be resolved through idempotency/status lookup.
Primary Region unavailable	60 minutes	Under 60 seconds for core event log, subject to confirmed replication design	Secondary Region serves a verified consistent state. Trading resumes only after leadership, sequencing, reconciliation, and client routing are confirmed.
Reporting warehouse corruption	8 hours	24 hours	Compliance and operations reports are rebuilt from authoritative immutable event records. Trading is unaffected.

The exact targets are only examples. The important point is that an RTO must include the time to validate correctness and make safe operational decisions, not merely the time to start instances or promote a database.

Also separate high availability from disaster recovery:

• Multi-AZ design reduces the impact of instance and Availability Zone failures within a Region.
• Cross-Region recovery addresses Regional failure, large-scale operational errors, or a Region-level dependency failure.
• Backups protect against corruption, accidental deletion, and some security events, but do not by themselves provide rapid failover.
• Replication can spread a bad write or deletion quickly; it is not a substitute for recoverable, tested backups.

The DR strategy is therefore selected from RTO, RPO, correctness, and cost—not from a desire to use the most sophisticated pattern.

Treat that spectrum as a decision aid, not a guarantee. A warm standby can still miss its RTO if data promotion, DNS changes, identity dependencies, runbooks, or reconciliation have never been tested.

For the latency-sensitive core, AWS’s digital-asset exchange discussion provides a useful example of a real trade-off: optimizing for the smallest local network latency can conflict with a fully resilient multi-AZ topology. Read the selected sections to ground an interview answer in the language of deterministic matching, quorum, replication modes, and accurate time.

---

Security, compliance, and cost must have acceptance criteria

Security requirements should describe enforceable outcomes, not a list of services such as IAM, KMS, and Secrets Manager. Good examples are:

Area	Requirement statement
Identity	Human privileged access uses federated identity, MFA, short-lived roles, and named individual attribution. Shared administrator credentials are prohibited.
Workload access	Each workload has a distinct role that can access only the specific queues, databases, keys, and secrets required for its function. Permissions are reviewed at a defined interval.
Secrets	Application credentials are retrieved at runtime from managed secrets storage, encrypted at rest and in transit; secret values never appear in source control, Terraform state, build logs, or application logs.
Auditability	Administrative actions, IAM policy changes, order lifecycle events, and access to sensitive records are tamper-evident, centrally retained, and searchable within an agreed investigation window.
Data protection	Customer and trading data are classified. Encryption, key ownership, retention, deletion, and cross-border replication are specified for each classification.
Compliance	Applicable jurisdictional obligations are confirmed with legal and compliance owners. Requirements define evidence retention, access review frequency, audit exports, and recovery/testing evidence.

Do not claim “PCI compliant,” “MiFID compliant,” or “SOC 2 compliant” merely because AWS services are used. Compliance is a shared responsibility and depends on scope, controls, evidence, and operating procedures. In an interview, phrase it as: “I would identify the applicable framework and translate its obligations into verifiable technical and operational controls.”

Cost as a constraint, not an afterthought

Cost requirements need enough precision to change a decision:

• “Keep it cheap” is not actionable.
• “Maintain baseline infrastructure below $X$ per month, model a $Y$-fold volatility event, and require approval for capacity reserved solely to improve the $p99.9$ order path” is actionable.

A sound cost brief usually includes:

1. Baseline cost: quiet-period steady state.
2. Peak cost: expected cost during planned peak throughput and autoscaling.
3. Unit economics: cost per order, active trader, GB of retained audit data, or market-data subscriber.
4. Mandatory resilience spend: capacity and replication needed to meet approved RTO/RPO.
5. Cost controls: tagging, budgets, anomaly alerts, retention tiers, and periodic rightsizing.
6. Explicit non-negotiables: never save money by weakening required backup retention, auditability, security controls, or recovery capability.

This lets you articulate a mature trade-off:

“Multi-site active/active can reduce recovery time, but it increases steady-state compute, cross-Region transfer, operational complexity, and the risk of consistency mistakes. If the business accepts a 60-minute regional RTO and sub-60-second RPO for the trading core, I would first evaluate a tested warm standby with replicated authoritative logs. If it requires near-zero regional interruption, it must explicitly fund and operate the stronger model.”

---

A 90-second interview answer structure

When asked to design an exchange platform, use this sequence:

1. Clarify or state assumptions. Define users, market type, geographic scope, transaction volume, burst behavior, and regulation.
2. Name the critical journeys. Separate matching, order lifecycle, cancellation, ledger, market data, customer APIs, and reporting.
3. State the priority order. Usually correctness and auditability first; then security, availability, recovery, tail latency, scale, and cost.
4. Give a compact measurable requirements table. Include percentile latency, transaction availability, sustained and burst throughput, recovery targets, and compliance outcomes.
5. Expose the key conflict. For example: lowest local latency versus multi-AZ resilience; synchronous replication versus tail latency; active-active recovery versus cost and operational risk.
6. Declare the validation plan. Load, stress, and soak tests; failover and restore drills; reconciliation tests; access reviews; and cost tests at peak load.

Avoid two common traps:

• Architecture-first answers: “I would use EKS, Aurora, Kafka, and Route 53.” Those may be appropriate later, but they are not requirements.
• Absolute claims: “Zero downtime,” “infinite scale,” and “zero RPO” are not credible until failure domain, data class, and cost are defined.

A better formulation is: “We will define what can degrade, what must remain correct, the exact recovery state, and the budget required to prove it.”

---

Key takeaways

A senior-level requirements brief is a decision tool. It makes every target measurable, identifies the service journey it applies to, states the failure scope, and explains which priority wins under conflict.

For an exchange, distinguish the low-latency execution path from public APIs, market data, reporting, and back-office functions. Treat correctness, deterministic ordering, auditability, and safe cancellation as first-class requirements. Define availability in terms of valid business outcomes, use tail-latency percentiles rather than averages, and specify load bursts rather than only average TPS.

Finally, separate Multi-AZ high availability, cross-Region disaster recovery, and backups. RTO and RPO are business commitments that must be tested end to end, including reconciliation and safe resumption of trading.

Next, you will translate these prioritized requirements into a highly available AWS network and edge design: multi-AZ VPC tiers, routing, controlled egress, private connectivity, and security boundaries.