Fintech and trading reference architectures: authority before AWS

Reading notesDownload original Markdown ↗

Now combine the service and recovery mechanisms around the business itself. Follow an order from permission and reservation to routing, execution, clearing, settlement, and postings; then locate the portfolio and other derived views. RSP labels a responsibility, INV an invariant, CASE a lifecycle example, and ARCA/ARCB/ARCC the three architecture variants. These are references into the chapter, not extra services. The variants address different workload boundaries, including a pipeline whose financial authorities remain external.

Evidence notation: C identifies a claim in the claim register, A a dated AWS source, F a foundational source, and CS a finding in the repository case study. The source index supplies the full source details. These labels are lookup aids, not facts to memorize.

A trading design is not a checkout flow with financial nouns. Order intent, reservation, matching, execution, clearing, settlement, cash/securities postings, portfolio, and notification are different facts with different authorities. This chapter names those authorities and invariants before placing AWS services. Larry Harris supplies market/trading framing; FIX supplies order and execution-report vocabulary; Fowler's accounting patterns supply posting and adjustment semantics; LMAX is one bounded single-writer example, not a universal exchange template (C46,C47,C107,C111; F08,F09,F17,F18,F37).

Documented: below means a cited source supports the stated scope. Inference: means an architecture decision from named premises. AWS behavior and service names are mutable and were rechecked on 2026-08-22. Workload figures are illustrative assumptions, not AWS promises or production measurements (C112; F19,F20).

Stable identifiers and authority model

The responsibility table is the first design artifact. authoritative means the row decides and records its named fact. derived means it serves a view, distribution, evidence, or notification contract and cannot authorize money, securities, order transitions, executions, or settlement merely because its read is fresh or strongly consistent (C46,C92).

Model details · task9 responsibilities

RESP|RSP01|Client command acceptance|PlaceOrder plus tenant clientOrderKey canonical fingerprint|authoritative|durable command receipt orderId acceptedVersion and ACCEPTED or REJECTED or PENDING|one fingerprint maps to one logical order and durable compatible response|tenant plus clientOrderKey conditional transaction|semantic outbox OrderAccepted or OrderRejected after local commit|receipt lookup and command-status API|timeout may leave accepted command with unknown response or pending publication|command order outbox manifest by stable IDs and version|Order API owner|fingerprint mapping durable receipt and outbox state reconcile|ARCA ARCB ARCC|INV01 INV08 INV09
RESP|RSP02|Product and permission validation|accepted command identity account instrument side and policy version|authoritative|versioned entitlement product session and restriction decision|only a permitted versioned product/account command advances|tenant plus account plus policyVersion serialized evaluation|ValidationPassed or ValidationRejected with policyVersion|permission and product reference views only|policy refresh may race command evaluation; stored decision version resolves|accepted decisions versus policy snapshot and rejected-reason controls|Product and entitlement owner|decision carries policyVersion inputs and deterministic outcome|ARCA ARCB ARCC|INV02 INV08 INV09
RESP|RSP03|Pre-trade risk and reservation|validated order exact quantity price cap currency instrument and account version|authoritative|AP12 cash securities reservations and available balances|reservation prevents double spend inside account instrument currency product-policy scope|accountId plus asset key transaction and monotonic accountVersion|FundsOrSecuritiesReserved or ReservationRejected in same transaction as intent/outbox|risk dashboards are derived; strong AP12 lookup is authority|stale caller view or timeout may leave reservation committed and route pending|reservation versus accepted order routed order posting and release manifests|Risk and ledger command owner|exact-unit balance plus active reservations equals governed capacity|ARCA ARCB ARCC|INV05 INV06 INV08 INV09 INV10
RESP|RSP04|Order lifecycle authority|accepted order version routing reports execution reports cancel and replace commands|authoritative|versioned order aggregate and allowed state transition history|only allowed expected-version transitions; terminal states reject ordinary mutation|orderId single writer or conditional expectedVersion|OrderStateChanged semantic outbox with orderVersion|order history and client status projection|late duplicate or conflicting reports can make transport arrival misleading|order versions versus routing executions and terminal/classified obligations|Order domain owner|complete version chain legal transitions and terminal evidence|ARCA ARCB ARCC|INV01 INV02 INV03 INV04 INV08 INV09
RESP|RSP05|Routing to venue or matching core|reserved accepted orderId orderVersion route policy and destination|authoritative|route intent attempt identity destination acknowledgement and status|one accepted version has one governed active route outcome or owned ambiguity|orderId routeAttemptId and destination session sequence|durable outbox to venue adapter or symbol matcher with stable identity|route-status projection and operator queue|reservation can succeed while delivery is delayed rejected or ambiguous|route intent versus destination receipt order state reservation age and release|Routing owner|every route attempt maps to receipt retry-safe absence or reconciliation break|ARCA ARCB ARCC|INV02 INV05 INV08 INV09
RESP|RSP06|Matching and execution|versioned routed order deterministic book command or venue execution report|authoritative|per-book command journal order book execution receipts and immutable fill identity|price-time or governed priority; unique fill; cumulative quantity never exceeds authority|instrument or book partition single writer with writerEpoch and inputSequence|ExecutionAccepted with executionId orderId orderVersion bookSequence and exact terms|market tape and execution projections|cancel/fill race venue timeout or failover may make requester outcome unknown|journal and snapshot versus execution receipts order quantities venue drop copy|Matching or venue-integration owner|deterministic journal replay and unique receipt set reconcile|ARCA ARCB ARCC|INV02 INV03 INV04 INV07 INV08 INV09
RESP|RSP07|Clearing obligations|accepted execution correction allocation and counterparty policy|authoritative|versioned clearing obligation amount quantity asset parties value-date policy and status|every accepted execution creates classified obligation or owned break|clearingAccount plus obligationId under expected version|ClearingObligationCreated or Corrected after local commit|clearing operations view|external clearer may accept while response times out|execution set versus clearing acknowledgements and obligation control totals|Clearing operations owner|each execution and correction maps to governed obligation lineage|ARCA ARCB ARCC|INV06 INV07 INV08 INV09
RESP|RSP08|Settlement completion and failure|clearing obligation bank custodian depository status and calendar policy|authoritative|settlement instruction status external receipt failure reason and finality evidence|settled means governing policy finality evidence exists; execution alone is insufficient|obligationId plus provider requestId and expected version|SettlementCompleted or SettlementFailed with evidence reference|client settlement and statement projections|provider timeout can mean instruction applied but response lost|obligations versus bank custodian depository statements and receipts|Settlement operations owner|terminal settled failed or owned break under declared policy window|ARCA ARCB ARCC|INV06 INV07 INV08 INV09
RESP|RSP09|Cash securities postings balances and reservations|execution trade-date obligations settlement completion or failure fees taxes corrections and releases|authoritative|append-oriented trade-date execution or obligation posting sets and linked settlement-date completion or reclassification posting sets plus versioned AP12 balances and reservations|exact units stable postingSetId balancing or conservation no silent mutation and trade-date versus settlement-date facts remain distinct|accountId plus asset or governed posting transaction scope|PostingSetRecorded and BalanceVersionAdvanced semantic outbox|portfolio PnL statements and balance display projections|partial posting external ambiguity or correction can leave unexplained balance|trade-date and settlement-date posting sets balances reservations executions obligations and external statements|Ledger owner with independent approver|balanced exact-unit postings linked settlement completion or reclassification and linked reversal or difference lineage|ARCA ARCB ARCC|INV03 INV05 INV06 INV07 INV08 INV09 INV10
RESP|RSP10|Portfolio and PnL views|versioned orders executions postings prices and corporate-action inputs|derived|AP07 portfolio position cost basis realized and unrealized PnL projection|source versions gaps and asOf visible; never authorizes risk money or securities|accountId or accountId plus instrument projector sequence|PortfolioVersionAdvanced notification only|portfolio API cache and client overlay|lag gap stale price or rebuild drift can display wrong values|authority manifests exact control totals watermarks and blue-green build|Portfolio projection owner|no gaps source totals match and cutover manifest approved|ARCA ARCB ARCC|INV09 INV10
RESP|RSP11|Notification intent and delivery|authoritative business fact policy template consent channel and expiry|derived|durable notification intent provider attempt receipt and exception|delivery cannot change business authority; required notice follows explicit product policy|notificationIntentId and recipient channel policy|NotificationIntentCreated then delivery receipts|email push SMS in-app and client catch-up|provider timeout duplicate receipt expiry or missing consent|intent versus provider receipt customer inbox and approved exception|Notification owner with policy escalation|policy-accepted receipt or classified exception while business state unchanged|ARCA ARCB ARCC|INV08 INV09 INV10
RESP|RSP12|Market-data ingest normalization and distribution|venue feed session sequence instrument mapping correction and status|derived|normalized quote trade book-update stream with source sequence and quality flags|preserve source identity sequence gaps and correction lineage; never becomes matcher or ledger|venue session plus instrument source sequence; optional derived lanes|normalized market events to Kinesis or MSK and durable audit landing|clients analytics surveillance and reference-price projections|packet gap reset out-of-order feed or hot-symbol overload|venue sequence gap requests snapshots checksums and downstream watermarks|Market data owner|source sequence continuity or classified gap and deterministic catch-up|ARCA ARCB ARCC|INV08 INV09 INV10
RESP|RSP13|Compliance surveillance and audit evidence|commands decisions executions messages postings access changes and policy versions|derived|lineage projection alerts case records and integrity-validated evidence objects|complete traceable evidence under policy; storage control alone is not compliance|tenant account instrument case and UTC report window; append evidence identity|evidence outbox to immutable or integrity-validated archive|surveillance cases audit search and regulator-approved exports|missing lineage false alert evidence access or retention mismatch|command-to-posting lineage manifests source counts hashes access logs and cases|Compliance and security owners|reproducible report plus access and integrity evidence and owned exceptions|ARCA ARCB ARCC|INV08 INV09 INV10
RESP|RSP14|Search statements analytics and client views|versioned domain facts market data and report policy|derived|OpenSearch Redis DynamoDB read models S3 Athena datasets and statements|asOf buildId sourceVersion and policy version visible; never financial authority|query-specific partition and projector checkpoint|view refresh and client catch-up events|client query APIs analytics and statement delivery|partial rebuild stale cache mapping failure or cross-domain inconsistent asOf|blue-green manifests source totals version coverage and statement rerun|Read platform and reporting owners|validated build watermark policy window and rollback target|ARCA ARCB ARCC|INV08 INV09 INV10

ID	Responsibility	Command/input	Authority type	State	Invariant	Writer/order scope	Publication	Reader/projection	Failure ambiguity	Reconciliation	Owner	Proof	Architecture routes	Invariant routes
RSP01	Client command acceptance	PlaceOrder plus tenant clientOrderKey canonical fingerprint	authoritative	durable command receipt orderId acceptedVersion and ACCEPTED or REJECTED or PENDING	one fingerprint maps to one logical order and durable compatible response	tenant plus clientOrderKey conditional transaction	semantic outbox OrderAccepted or OrderRejected after local commit	receipt lookup and command-status API	timeout may leave accepted command with unknown response or pending publication	command order outbox manifest by stable IDs and version	Order API owner	fingerprint mapping durable receipt and outbox state reconcile	ARCA ARCB ARCC	INV01 INV08 INV09
RSP02	Product and permission validation	accepted command identity account instrument side and policy version	authoritative	versioned entitlement product session and restriction decision	only a permitted versioned product/account command advances	tenant plus account plus policyVersion serialized evaluation	ValidationPassed or ValidationRejected with policyVersion	permission and product reference views only	policy refresh may race command evaluation; stored decision version resolves	accepted decisions versus policy snapshot and rejected-reason controls	Product and entitlement owner	decision carries policyVersion inputs and deterministic outcome	ARCA ARCB ARCC	INV02 INV08 INV09
RSP03	Pre-trade risk and reservation	validated order exact quantity price cap currency instrument and account version	authoritative	AP12 cash securities reservations and available balances	reservation prevents double spend inside account instrument currency product-policy scope	accountId plus asset key transaction and monotonic accountVersion	FundsOrSecuritiesReserved or ReservationRejected in same transaction as intent/outbox	risk dashboards are derived; strong AP12 lookup is authority	stale caller view or timeout may leave reservation committed and route pending	reservation versus accepted order routed order posting and release manifests	Risk and ledger command owner	exact-unit balance plus active reservations equals governed capacity	ARCA ARCB ARCC	INV05 INV06 INV08 INV09 INV10
RSP04	Order lifecycle authority	accepted order version routing reports execution reports cancel and replace commands	authoritative	versioned order aggregate and allowed state transition history	only allowed expected-version transitions; terminal states reject ordinary mutation	orderId single writer or conditional expectedVersion	OrderStateChanged semantic outbox with orderVersion	order history and client status projection	late duplicate or conflicting reports can make transport arrival misleading	order versions versus routing executions and terminal/classified obligations	Order domain owner	complete version chain legal transitions and terminal evidence	ARCA ARCB ARCC	INV01 INV02 INV03 INV04 INV08 INV09
RSP05	Routing to venue or matching core	reserved accepted orderId orderVersion route policy and destination	authoritative	route intent attempt identity destination acknowledgement and status	one accepted version has one governed active route outcome or owned ambiguity	orderId routeAttemptId and destination session sequence	durable outbox to venue adapter or symbol matcher with stable identity	route-status projection and operator queue	reservation can succeed while delivery is delayed rejected or ambiguous	route intent versus destination receipt order state reservation age and release	Routing owner	every route attempt maps to receipt retry-safe absence or reconciliation break	ARCA ARCB ARCC	INV02 INV05 INV08 INV09
RSP06	Matching and execution	versioned routed order deterministic book command or venue execution report	authoritative	per-book command journal order book execution receipts and immutable fill identity	price-time or governed priority; unique fill; cumulative quantity never exceeds authority	instrument or book partition single writer with writerEpoch and inputSequence	ExecutionAccepted with executionId orderId orderVersion bookSequence and exact terms	market tape and execution projections	cancel/fill race venue timeout or failover may make requester outcome unknown	journal and snapshot versus execution receipts order quantities venue drop copy	Matching or venue-integration owner	deterministic journal replay and unique receipt set reconcile	ARCA ARCB ARCC	INV02 INV03 INV04 INV07 INV08 INV09
RSP07	Clearing obligations	accepted execution correction allocation and counterparty policy	authoritative	versioned clearing obligation amount quantity asset parties value-date policy and status	every accepted execution creates classified obligation or owned break	clearingAccount plus obligationId under expected version	ClearingObligationCreated or Corrected after local commit	clearing operations view	external clearer may accept while response times out	execution set versus clearing acknowledgements and obligation control totals	Clearing operations owner	each execution and correction maps to governed obligation lineage	ARCA ARCB ARCC	INV06 INV07 INV08 INV09
RSP08	Settlement completion and failure	clearing obligation bank custodian depository status and calendar policy	authoritative	settlement instruction status external receipt failure reason and finality evidence	settled means governing policy finality evidence exists; execution alone is insufficient	obligationId plus provider requestId and expected version	SettlementCompleted or SettlementFailed with evidence reference	client settlement and statement projections	provider timeout can mean instruction applied but response lost	obligations versus bank custodian depository statements and receipts	Settlement operations owner	terminal settled failed or owned break under declared policy window	ARCA ARCB ARCC	INV06 INV07 INV08 INV09
RSP09	Cash securities postings balances and reservations	execution trade-date obligations settlement completion or failure fees taxes corrections and releases	authoritative	append-oriented trade-date execution or obligation posting sets and linked settlement-date completion or reclassification posting sets plus versioned AP12 balances and reservations	exact units stable postingSetId balancing or conservation no silent mutation and trade-date versus settlement-date facts remain distinct	accountId plus asset or governed posting transaction scope	PostingSetRecorded and BalanceVersionAdvanced semantic outbox	portfolio PnL statements and balance display projections	partial posting external ambiguity or correction can leave unexplained balance	trade-date and settlement-date posting sets balances reservations executions obligations and external statements	Ledger owner with independent approver	balanced exact-unit postings linked settlement completion or reclassification and linked reversal or difference lineage	ARCA ARCB ARCC	INV03 INV05 INV06 INV07 INV08 INV09 INV10
RSP10	Portfolio and PnL views	versioned orders executions postings prices and corporate-action inputs	derived	AP07 portfolio position cost basis realized and unrealized PnL projection	source versions gaps and asOf visible; never authorizes risk money or securities	accountId or accountId plus instrument projector sequence	PortfolioVersionAdvanced notification only	portfolio API cache and client overlay	lag gap stale price or rebuild drift can display wrong values	authority manifests exact control totals watermarks and blue-green build	Portfolio projection owner	no gaps source totals match and cutover manifest approved	ARCA ARCB ARCC	INV09 INV10
RSP11	Notification intent and delivery	authoritative business fact policy template consent channel and expiry	derived	durable notification intent provider attempt receipt and exception	delivery cannot change business authority; required notice follows explicit product policy	notificationIntentId and recipient channel policy	NotificationIntentCreated then delivery receipts	email push SMS in-app and client catch-up	provider timeout duplicate receipt expiry or missing consent	intent versus provider receipt customer inbox and approved exception	Notification owner with policy escalation	policy-accepted receipt or classified exception while business state unchanged	ARCA ARCB ARCC	INV08 INV09 INV10
RSP12	Market-data ingest normalization and distribution	venue feed session sequence instrument mapping correction and status	derived	normalized quote trade book-update stream with source sequence and quality flags	preserve source identity sequence gaps and correction lineage; never becomes matcher or ledger	venue session plus instrument source sequence; optional derived lanes	normalized market events to Kinesis or MSK and durable audit landing	clients analytics surveillance and reference-price projections	packet gap reset out-of-order feed or hot-symbol overload	venue sequence gap requests snapshots checksums and downstream watermarks	Market data owner	source sequence continuity or classified gap and deterministic catch-up	ARCA ARCB ARCC	INV08 INV09 INV10
RSP13	Compliance surveillance and audit evidence	commands decisions executions messages postings access changes and policy versions	derived	lineage projection alerts case records and integrity-validated evidence objects	complete traceable evidence under policy; storage control alone is not compliance	tenant account instrument case and UTC report window; append evidence identity	evidence outbox to immutable or integrity-validated archive	surveillance cases audit search and regulator-approved exports	missing lineage false alert evidence access or retention mismatch	command-to-posting lineage manifests source counts hashes access logs and cases	Compliance and security owners	reproducible report plus access and integrity evidence and owned exceptions	ARCA ARCB ARCC	INV08 INV09 INV10
RSP14	Search statements analytics and client views	versioned domain facts market data and report policy	derived	OpenSearch Redis DynamoDB read models S3 Athena datasets and statements	asOf buildId sourceVersion and policy version visible; never financial authority	query-specific partition and projector checkpoint	view refresh and client catch-up events	client query APIs analytics and statement delivery	partial rebuild stale cache mapping failure or cross-domain inconsistent asOf	blue-green manifests source totals version coverage and statement rerun	Read platform and reporting owners	validated build watermark policy window and rollback target	ARCA ARCB ARCC	INV08 INV09 INV10

Authority rules that survive service changes

• A projection, cache, stream, bus, archive, or search index never becomes monetary authority because it is current or strongly read. AP12 decides reservations; AP07 is rebuildable (C46,C91,C92).
• ClOrdID, ExecID, OrdStatus, and ExecType are useful FIX vocabulary, not a substitute for the design's explicit writer, transition, and correction rules (C107; F37).
• Execution, clearing, and settlement remain different states. The finality point and value-date/calendar rules are governed policy inputs (C108; F38).
• S3 Object Lock and CloudTrail integrity validation can protect named evidence artifacts, but neither proves completeness, semantic correctness, or compliance (C109; A41,A122, retrieved 2026-08-22).

Invariant catalog

The responsibility table tells you who decides each fact. The invariant catalog states what those decisions must preserve when commands repeat or arrive in an awkward order. Pick one order and connect its uniqueness, legal transitions, cumulative fills, reservation, and posting evidence across the rows before comparing service diagrams.

Model details · task9 invariants

INVARIANT|INV01|Logical order uniqueness|RSP01 RSP04|tenant plus clientOrderKey plus canonical request fingerprint maps to one orderId and durable response|conditional transaction on client key and order identity|quantity price currency instrument and policy version use canonical exact representations|mismatch rejects; repair never aliases two requests|reconcile request order receipt and outbox by stable IDs|one fingerprint one order and no unresolved duplicate|RSP01 RSP04|ARCA ARCB ARCC|CASE01 CASE11 CASE12
INVARIANT|INV02|Versioned legal order transitions|RSP02 RSP04 RSP05 RSP06|expected orderVersion and allowed state table govern transitions; terminal state blocks ordinary mutation|orderId single writer or compare-and-set expectedVersion|OrderQty CumQty LeavesQty are exact quantity units with instrument scale|cancel replace and correction create linked versions rather than overwrite|rebuild complete transition chain and park illegal or missing version|all versions contiguous and each transition allowed|RSP02 RSP04 RSP05 RSP06|ARCA ARCB ARCC|CASE03 CASE04 CASE05 CASE06 CASE07 CASE08 CASE13
INVARIANT|INV03|Unique execution and bounded cumulative quantity|RSP04 RSP06 RSP09|executionId is unique; accepted cumulative quantity never exceeds ordered authority absent governed correction|book sequence plus executionId conditional receipt|LastQty CumQty LeavesQty and OrderQty use exact instrument quantity scale|bust or correct uses new executionId and ExecRef lineage|reconcile matcher or venue receipts to order and postings|unique execution set sums to authoritative CumQty within rule|RSP04 RSP06 RSP09|ARCA ARCB ARCC|CASE02 CASE03 CASE04 CASE06 CASE07
INVARIANT|INV04|Leaves cumulative and order quantity reconcile|RSP04 RSP06|active order uses LeavesQty equals OrderQty minus CumQty; terminal policy may set zero leaves without erasing fills|orderId versioned lifecycle authority|exact quantity and scale; no binary float|replace creates governed new order version and priority policy; correction adjusts through lineage|recompute quantities from accepted execution lineage|rendered lifecycle quantities match authoritative execution set|RSP04 RSP06|ARCA ARCB ARCC|CASE03 CASE04 CASE05 CASE06 CASE07
INVARIANT|INV05|Reservation prevents double spend|RSP03 RSP05 RSP09|available equals governed balance less active reservations inside account asset product-policy scope and cannot fall below allowed limit|accountId plus currency or instrument AP12 transaction and accountVersion|cash minor units or exact decimal; securities exact quantity and scale|release consume resize expiry and correction are versioned transitions|reconcile reservations to live orders executions posting sets and aged route intents|no two accepted obligations consume the same available capacity|RSP03 RSP05 RSP09|ARCA ARCB ARCC|CASE04 CASE05 CASE09 CASE10 CASE12 CASE13
INVARIANT|INV06|Append-oriented exact-unit posting sets|RSP03 RSP07 RSP08 RSP09|stable postingSetId; complete set balances by currency or conserves securities under declared account model|ledger transaction scope plus account asset version|explicit currency instrument unit scale rounding and signed amount; binary float forbidden|linked reversal or difference posting set only; no silent update or delete|reconcile postings balances reservations executions obligations and external statements|balanced complete posting set and current control total agree|RSP03 RSP07 RSP08 RSP09|ARCA ARCB ARCC|CASE02 CASE07 CASE09 CASE10 CASE12
INVARIANT|INV07|Execution clearing and settlement separation|RSP06 RSP07 RSP08 RSP09|execution creates or updates clearing obligation; settlement needs independent completion or classified failure evidence|executionId obligationId providerRequestId expected versions|exact quantity amount currency asset and governed value date|corrections propagate new linked obligations and postings|venue clearer bank custodian depository and ledger manifests compare|no execution is called settled without governing finality evidence|RSP06 RSP07 RSP08 RSP09|ARCA ARCB ARCC|CASE03 CASE07 CASE10 CASE12
INVARIANT|INV08|Every accepted obligation resolves|RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09 RSP11 RSP12 RSP13 RSP14|accepted command route execution obligation settlement posting notice and evidence reaches terminal classified state or owned reconciliation break|stable identity state version owner and deadline per boundary|all financial comparisons use exact units and declared policy windows|repair is forward completion reversal correcting fact or owned exception|manifest partitions accepted terminal pending unknown and breaks without overlap|attempted equals completed plus rejected plus pending plus owned breaks|RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09 RSP11 RSP12 RSP13 RSP14|ARCA ARCB ARCC|CASE01 CASE02 CASE03 CASE04 CASE05 CASE06 CASE07 CASE08 CASE09 CASE10 CASE11 CASE12 CASE13
INVARIANT|INV09|Version epoch and half-open repair fencing|RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09 RSP10 RSP11 RSP12 RSP13 RSP14|sourceVersion writerEpoch buildId and UTC startInclusive endExclusive manifest prevent duplicate stale overlapping live replay and regional writers|one active writer epoch plus conditional checkpoint and non-overlapping manifest windows|report totals retain exact units currency scale and time-policy version|stale epoch rejects; repair creates new manifest and never edits signed prior proof|adjacent UTC windows share endpoint; versions and positions cover once|one active epoch no overlaps no gaps and approved manifest lineage|RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09 RSP10 RSP11 RSP12 RSP13 RSP14|ARCA ARCB ARCC|CASE06 CASE08 CASE11 CASE12 CASE13
INVARIANT|INV10|Derived state never authorizes finance|RSP03 RSP09 RSP10 RSP11 RSP12 RSP13 RSP14|portfolio cache search statement analytics market-data and compliance projection cannot approve reservation balance execution posting or settlement|authoritative command API or store owns decision; projection has sourceVersion and asOf|derived exact values preserve source units but remain non-authoritative|rebuild vNext and cut over only after control totals; correction begins at authority|compare view watermarks counts values and coverage to authority|every decision trace points to named authority not derived store|RSP03 RSP09 RSP10 RSP11 RSP12 RSP13 RSP14|ARCA ARCB ARCC|CASE09 CASE11 CASE12

ID	Name	Authority	Rule	Serialization	Exact units	Correction	Recovery	Proof	Responsibility routes	Architecture routes	Case routes
INV01	Logical order uniqueness	RSP01 RSP04	tenant plus clientOrderKey plus canonical request fingerprint maps to one orderId and durable response	conditional transaction on client key and order identity	quantity price currency instrument and policy version use canonical exact representations	mismatch rejects; repair never aliases two requests	reconcile request order receipt and outbox by stable IDs	one fingerprint one order and no unresolved duplicate	RSP01 RSP04	ARCA ARCB ARCC	CASE01 CASE11 CASE12
INV02	Versioned legal order transitions	RSP02 RSP04 RSP05 RSP06	expected orderVersion and allowed state table govern transitions; terminal state blocks ordinary mutation	orderId single writer or compare-and-set expectedVersion	OrderQty CumQty LeavesQty are exact quantity units with instrument scale	cancel replace and correction create linked versions rather than overwrite	rebuild complete transition chain and park illegal or missing version	all versions contiguous and each transition allowed	RSP02 RSP04 RSP05 RSP06	ARCA ARCB ARCC	CASE03 CASE04 CASE05 CASE06 CASE07 CASE08 CASE13
INV03	Unique execution and bounded cumulative quantity	RSP04 RSP06 RSP09	executionId is unique; accepted cumulative quantity never exceeds ordered authority absent governed correction	book sequence plus executionId conditional receipt	LastQty CumQty LeavesQty and OrderQty use exact instrument quantity scale	bust or correct uses new executionId and ExecRef lineage	reconcile matcher or venue receipts to order and postings	unique execution set sums to authoritative CumQty within rule	RSP04 RSP06 RSP09	ARCA ARCB ARCC	CASE02 CASE03 CASE04 CASE06 CASE07
INV04	Leaves cumulative and order quantity reconcile	RSP04 RSP06	active order uses LeavesQty equals OrderQty minus CumQty; terminal policy may set zero leaves without erasing fills	orderId versioned lifecycle authority	exact quantity and scale; no binary float	replace creates governed new order version and priority policy; correction adjusts through lineage	recompute quantities from accepted execution lineage	rendered lifecycle quantities match authoritative execution set	RSP04 RSP06	ARCA ARCB ARCC	CASE03 CASE04 CASE05 CASE06 CASE07
INV05	Reservation prevents double spend	RSP03 RSP05 RSP09	available equals governed balance less active reservations inside account asset product-policy scope and cannot fall below allowed limit	accountId plus currency or instrument AP12 transaction and accountVersion	cash minor units or exact decimal; securities exact quantity and scale	release consume resize expiry and correction are versioned transitions	reconcile reservations to live orders executions posting sets and aged route intents	no two accepted obligations consume the same available capacity	RSP03 RSP05 RSP09	ARCA ARCB ARCC	CASE04 CASE05 CASE09 CASE10 CASE12 CASE13
INV06	Append-oriented exact-unit posting sets	RSP03 RSP07 RSP08 RSP09	stable postingSetId; complete set balances by currency or conserves securities under declared account model	ledger transaction scope plus account asset version	explicit currency instrument unit scale rounding and signed amount; binary float forbidden	linked reversal or difference posting set only; no silent update or delete	reconcile postings balances reservations executions obligations and external statements	balanced complete posting set and current control total agree	RSP03 RSP07 RSP08 RSP09	ARCA ARCB ARCC	CASE02 CASE07 CASE09 CASE10 CASE12
INV07	Execution clearing and settlement separation	RSP06 RSP07 RSP08 RSP09	execution creates or updates clearing obligation; settlement needs independent completion or classified failure evidence	executionId obligationId providerRequestId expected versions	exact quantity amount currency asset and governed value date	corrections propagate new linked obligations and postings	venue clearer bank custodian depository and ledger manifests compare	no execution is called settled without governing finality evidence	RSP06 RSP07 RSP08 RSP09	ARCA ARCB ARCC	CASE03 CASE07 CASE10 CASE12
INV08	Every accepted obligation resolves	RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09 RSP11 RSP12 RSP13 RSP14	accepted command route execution obligation settlement posting notice and evidence reaches terminal classified state or owned reconciliation break	stable identity state version owner and deadline per boundary	all financial comparisons use exact units and declared policy windows	repair is forward completion reversal correcting fact or owned exception	manifest partitions accepted terminal pending unknown and breaks without overlap	attempted equals completed plus rejected plus pending plus owned breaks	RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09 RSP11 RSP12 RSP13 RSP14	ARCA ARCB ARCC	CASE01 CASE02 CASE03 CASE04 CASE05 CASE06 CASE07 CASE08 CASE09 CASE10 CASE11 CASE12 CASE13
INV09	Version epoch and half-open repair fencing	RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09 RSP10 RSP11 RSP12 RSP13 RSP14	sourceVersion writerEpoch buildId and UTC startInclusive endExclusive manifest prevent duplicate stale overlapping live replay and regional writers	one active writer epoch plus conditional checkpoint and non-overlapping manifest windows	report totals retain exact units currency scale and time-policy version	stale epoch rejects; repair creates new manifest and never edits signed prior proof	adjacent UTC windows share endpoint; versions and positions cover once	one active epoch no overlaps no gaps and approved manifest lineage	RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09 RSP10 RSP11 RSP12 RSP13 RSP14	ARCA ARCB ARCC	CASE06 CASE08 CASE11 CASE12 CASE13
INV10	Derived state never authorizes finance	RSP03 RSP09 RSP10 RSP11 RSP12 RSP13 RSP14	portfolio cache search statement analytics market-data and compliance projection cannot approve reservation balance execution posting or settlement	authoritative command API or store owns decision; projection has sourceVersion and asOf	derived exact values preserve source units but remain non-authoritative	rebuild vNext and cut over only after control totals; correction begins at authority	compare view watermarks counts values and coverage to authority	every decision trace points to named authority not derived store	RSP03 RSP09 RSP10 RSP11 RSP12 RSP13 RSP14	ARCA ARCB ARCC	CASE09 CASE11 CASE12

FIX defines CumQty as filled quantity and, for active orders, LeavesQty = OrderQty - CumQty; ExecType identifies the report while OrdStatus identifies current order state. The implementation still owns its legal transition table, priority/version policy, and authority (C107; F37). Fowler's accounting patterns show balances derived from entries and preserve history through reversal or difference adjustments; the ledger contract above applies that idea to exact cash and securities units (C47,C91; F08).

Difficult lifecycle cases

These cases put the invariant catalog under pressure. A cancel request is intent, an accepted fill is a fact, and a timeout is uncertainty; they cannot all be handled by overwriting an order status. Follow the authority decision and customer-visible result together, then check which identity, source version, and reconciliation evidence make the repair safe.

Model details · task9 cases

CASE|CASE01|Duplicate command|same tenant clientOrderKey arrives concurrently or after timeout|RSP01 fingerprint and durable receipt decide|same fingerprint returns same order and result; mismatch rejects|conditional create before map; no cache-only dedupe|repair request order and outbox; never create second logical order|existing result or explicit pending not silent resubmit|fingerprint orderId receipt and outbox reconcile|INV01 INV08|ARCA ARCB ARCC
CASE|CASE02|Duplicate fill|same executionId or equivalent venue receipt repeats|RSP06 execution receipt and RSP09 posting inbox decide|duplicate is no-op with stored receipt; conflicting payload opens break|executionId unique inside venue session and order lineage|compare venue drop copy execution rows CumQty and posting sets|order and holdings unchanged by duplicate|one execution identity produces one accepted quantity and posting lineage|INV03 INV06 INV08|ARCA ARCB ARCC
CASE|CASE03|Partial fill|execution quantity is below current LeavesQty|RSP06 fill plus RSP04 lifecycle decide|CumQty increases LeavesQty decreases order remains partially filled unless policy terminal|bookSequence and orderVersion serialize; exact quantity|replay missing execution by identity and version; reconcile postings|client sees partial quantity and remaining open asOf version|OrderQty equals CumQty plus LeavesQty for active order|INV02 INV03 INV04 INV07 INV08|ARCA ARCB ARCC
CASE|CASE04|Cancel versus fill race|cancel request and match or venue fill cross|RSP06 accepted book or venue sequence decides fill; RSP04 records result|fill accepted first remains; cancel can stop only remaining quantity|book sequence and orderVersion; cancel intent is not authority over prior fill|reconcile cancel acknowledgement accepted executions order quantities and reservation release|client receives canceled remainder plus immutable accepted fill|no accepted fill erased and released reservation equals unfilled remainder|INV02 INV03 INV04 INV05 INV08|ARCA ARCB ARCC
CASE|CASE05|Cancel replace and priority|replace requests price quantity or terms|RSP04 lifecycle plus RSP06 book policy decide|new order version links OrigClOrdID or prior version; priority retained or lost by explicit venue policy|orderId version and book sequence|late old-version reports park; reconcile old and new versions and reservations|client sees pending replace then accepted or rejected version|one active governed version and explicit priority decision|INV02 INV04 INV05 INV08|ARCA ARCB ARCC
CASE|CASE06|Late or out-of-order execution report|report version or source sequence arrives behind or ahead|RSP04 and RSP06 authoritative versions decide|duplicate or stale no-op; gap parks; valid next version applies|expected sourceVersion plus venue session sequence|fetch missing range or status snapshot then reapply; no timestamp sort repair|view remains stale or pending with asOf watermark|contiguous authoritative versions and execution quantities reconcile|INV02 INV03 INV04 INV08 INV09|ARCA ARCB ARCC
CASE|CASE07|Bust or correct|venue sends TradeCancel or TradeCorrect referencing prior execution|RSP06 correction receipt then RSP09 linked posting correction decide|new correction fact references prior execution; order quantities obligations and postings advance under policy|new executionId plus ExecRefID lineage and expected versions|reconcile original correction order clearing settlement and reversal or difference postings|client sees correction lineage not erased history|old fact retained and net exact quantities and postings reconcile|INV02 INV03 INV04 INV06 INV07 INV08|ARCA ARCB ARCC
CASE|CASE08|Market halt and resume|venue or risk control halts instrument session or market|RSP02 policy and RSP06 book state decide|new commands reject or queue by policy; accepted book state freezes; resume uses new policyVersion and epoch|instrument or session state before order sequencing|snapshot journal and venue status reconcile before controlled resume|explicit halted status and no false execution promise|no command crossed halt epoch contrary to policy|INV02 INV08 INV09|ARCA ARCB ARCC
CASE|CASE09|Stale reservation or balance view|caller or projection shows earlier available amount|RSP03 AP12 authority decides under expected accountVersion|stale command conflicts and re-evaluates; projection never authorizes|account plus asset conditional transaction|reconcile balance reservations open orders and posting sets; freeze affected scope on break|client gets conflict pending or current-authority response|no double spend despite stale view|INV05 INV06 INV08 INV10|ARCA ARCB ARCC
CASE|CASE10|Venue provider bank or custodian timeout|external request times out after possible acceptance|RSP05 RSP07 or RSP08 intent and provider receipt decide|persist intent before call; outcome remains pending-external until status or statement evidence|providerRequestId plus local intent version; no blind retry|status lookup callback drop copy statement and owned break; forward-complete or correct|pending-external not failed and not safely resubmittable|external receipt intent obligation and ledger agree|INV05 INV06 INV07 INV08|ARCA ARCB ARCC
CASE|CASE11|Replay|operator reprocesses retained facts or rebuild range|original domain authority stays authoritative; target build is derived|same identities and versions no-op or apply once; side effects suppressed unless explicitly repair target|replayManifest buildId source position and rate lane|compare manifest counts versions exact totals and watermark then cut over|serving view stays old and labeled until validated|no overlap gap repeated external effect or unowned discrepancy|INV01 INV08 INV09 INV10|ARCA ARCB ARCC
CASE|CASE12|Region failover|active Region or matching node is lost|one fenced writerEpoch per authority decides|stop writes; promote only proven snapshot journal and dependencies; stale epoch rejects|writerEpoch lease and journal inputSequence plus routed data-plane fencing|restore authority first replay outbox rebuild projections reconcile venues banks custodians and ledger|commands unavailable until fenced; projections stale asOf|one active epoch RTO RPO evidence and clean control totals|INV01 INV05 INV06 INV07 INV08 INV09 INV10|ARCA ARCB ARCC
CASE|CASE13|Reservation succeeds but route is delayed rejected or ambiguous|reservation transaction commits before destination acknowledgement|RSP03 reservation receipt and RSP05 route receipt decide|reservation remains HELD with order ROUTE_PENDING; explicit reject releases; ambiguity reconciles before release or resend|orderVersion routeAttemptId reservationId and expiry policy state|aged manifest compares outbox route receipt matcher or venue status; release or reroute only after governed evidence|accepted-pending with lookup token and reservation status|every reservation maps to active route execution governed release or owned break|INV02 INV05 INV08 INV09|ARCA ARCB ARCC

ID	Case	Input/trigger	Authority decision	State transition	Idempotency/order	Recovery	Customer state	Proof	Invariant routes	Architecture routes
CASE01	Duplicate command	same tenant clientOrderKey arrives concurrently or after timeout	RSP01 fingerprint and durable receipt decide	same fingerprint returns same order and result; mismatch rejects	conditional create before map; no cache-only dedupe	repair request order and outbox; never create second logical order	existing result or explicit pending not silent resubmit	fingerprint orderId receipt and outbox reconcile	INV01 INV08	ARCA ARCB ARCC
CASE02	Duplicate fill	same executionId or equivalent venue receipt repeats	RSP06 execution receipt and RSP09 posting inbox decide	duplicate is no-op with stored receipt; conflicting payload opens break	executionId unique inside venue session and order lineage	compare venue drop copy execution rows CumQty and posting sets	order and holdings unchanged by duplicate	one execution identity produces one accepted quantity and posting lineage	INV03 INV06 INV08	ARCA ARCB ARCC
CASE03	Partial fill	execution quantity is below current LeavesQty	RSP06 fill plus RSP04 lifecycle decide	CumQty increases LeavesQty decreases order remains partially filled unless policy terminal	bookSequence and orderVersion serialize; exact quantity	replay missing execution by identity and version; reconcile postings	client sees partial quantity and remaining open asOf version	OrderQty equals CumQty plus LeavesQty for active order	INV02 INV03 INV04 INV07 INV08	ARCA ARCB ARCC
CASE04	Cancel versus fill race	cancel request and match or venue fill cross	RSP06 accepted book or venue sequence decides fill; RSP04 records result	fill accepted first remains; cancel can stop only remaining quantity	book sequence and orderVersion; cancel intent is not authority over prior fill	reconcile cancel acknowledgement accepted executions order quantities and reservation release	client receives canceled remainder plus immutable accepted fill	no accepted fill erased and released reservation equals unfilled remainder	INV02 INV03 INV04 INV05 INV08	ARCA ARCB ARCC
CASE05	Cancel replace and priority	replace requests price quantity or terms	RSP04 lifecycle plus RSP06 book policy decide	new order version links OrigClOrdID or prior version; priority retained or lost by explicit venue policy	orderId version and book sequence	late old-version reports park; reconcile old and new versions and reservations	client sees pending replace then accepted or rejected version	one active governed version and explicit priority decision	INV02 INV04 INV05 INV08	ARCA ARCB ARCC
CASE06	Late or out-of-order execution report	report version or source sequence arrives behind or ahead	RSP04 and RSP06 authoritative versions decide	duplicate or stale no-op; gap parks; valid next version applies	expected sourceVersion plus venue session sequence	fetch missing range or status snapshot then reapply; no timestamp sort repair	view remains stale or pending with asOf watermark	contiguous authoritative versions and execution quantities reconcile	INV02 INV03 INV04 INV08 INV09	ARCA ARCB ARCC
CASE07	Bust or correct	venue sends TradeCancel or TradeCorrect referencing prior execution	RSP06 correction receipt then RSP09 linked posting correction decide	new correction fact references prior execution; order quantities obligations and postings advance under policy	new executionId plus ExecRefID lineage and expected versions	reconcile original correction order clearing settlement and reversal or difference postings	client sees correction lineage not erased history	old fact retained and net exact quantities and postings reconcile	INV02 INV03 INV04 INV06 INV07 INV08	ARCA ARCB ARCC
CASE08	Market halt and resume	venue or risk control halts instrument session or market	RSP02 policy and RSP06 book state decide	new commands reject or queue by policy; accepted book state freezes; resume uses new policyVersion and epoch	instrument or session state before order sequencing	snapshot journal and venue status reconcile before controlled resume	explicit halted status and no false execution promise	no command crossed halt epoch contrary to policy	INV02 INV08 INV09	ARCA ARCB ARCC
CASE09	Stale reservation or balance view	caller or projection shows earlier available amount	RSP03 AP12 authority decides under expected accountVersion	stale command conflicts and re-evaluates; projection never authorizes	account plus asset conditional transaction	reconcile balance reservations open orders and posting sets; freeze affected scope on break	client gets conflict pending or current-authority response	no double spend despite stale view	INV05 INV06 INV08 INV10	ARCA ARCB ARCC
CASE10	Venue provider bank or custodian timeout	external request times out after possible acceptance	RSP05 RSP07 or RSP08 intent and provider receipt decide	persist intent before call; outcome remains pending-external until status or statement evidence	providerRequestId plus local intent version; no blind retry	status lookup callback drop copy statement and owned break; forward-complete or correct	pending-external not failed and not safely resubmittable	external receipt intent obligation and ledger agree	INV05 INV06 INV07 INV08	ARCA ARCB ARCC
CASE11	Replay	operator reprocesses retained facts or rebuild range	original domain authority stays authoritative; target build is derived	same identities and versions no-op or apply once; side effects suppressed unless explicitly repair target	replayManifest buildId source position and rate lane	compare manifest counts versions exact totals and watermark then cut over	serving view stays old and labeled until validated	no overlap gap repeated external effect or unowned discrepancy	INV01 INV08 INV09 INV10	ARCA ARCB ARCC
CASE12	Region failover	active Region or matching node is lost	one fenced writerEpoch per authority decides	stop writes; promote only proven snapshot journal and dependencies; stale epoch rejects	writerEpoch lease and journal inputSequence plus routed data-plane fencing	restore authority first replay outbox rebuild projections reconcile venues banks custodians and ledger	commands unavailable until fenced; projections stale asOf	one active epoch RTO RPO evidence and clean control totals	INV01 INV05 INV06 INV07 INV08 INV09 INV10	ARCA ARCB ARCC
CASE13	Reservation succeeds but route is delayed rejected or ambiguous	reservation transaction commits before destination acknowledgement	RSP03 reservation receipt and RSP05 route receipt decide	reservation remains HELD with order ROUTE_PENDING; explicit reject releases; ambiguity reconciles before release or resend	orderVersion routeAttemptId reservationId and expiry policy state	aged manifest compares outbox route receipt matcher or venue status; release or reroute only after governed evidence	accepted-pending with lookup token and reservation status	every reservation maps to active route execution governed release or owned break	INV02 INV05 INV08 INV09	ARCA ARCB ARCC

A cancel request never cancels an execution already accepted by the matching or venue authority. A bust/correct is new governed evidence linked by execution identity; it propagates through order quantity, obligation, posting, portfolio, statement, and reconciliation lineages (C107; F37). Replay re-delivers facts; only proof against authority repairs state (FSR04,FSR09,RBK05).

Three architecture operating contracts

The three variants keep the preceding responsibilities explicit while changing where work is owned and where scale matters. The brokerage optimizes reads around authorities, the market/execution pipeline distributes externally authoritative facts, and the mixed exchange owns a resident matching core. Read solid authority paths and asynchronous projections separately, then compare the hot-lane and recovery assumptions.

Every variant consumes all ten invariants and thirteen cases. It changes where work runs and which projections are worth owning, not the meaning of cash, execution, settlement, or evidence.

Model details · task9 architectures

ARCH|ARCA|Read-heavy brokerage|serve portfolio history search analytics and live client views without moving financial decisions off command authority|Aurora PostgreSQL is nearer when relational transactions joins ad-hoc operations and one SQL authority dominate; reject extra projections until measured reads earn them|authoritative=RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09; derived=RSP10 RSP11 RSP12 RSP13 RSP14; external=none|1000 commands/s peak 50000 reads/s peak 4 projection writes/command|command acknowledgement p99 under 150 ms; read p95 under 2 s normal and stale-asOf after 30 s|accountId for AP12 and ledger; orderId lifecycle; source versions for projections; no global order|CQRS-lite; minVersion receipt overlay then bounded authority lookup; versioned stale-asOf views|RSP01 and AP16 atomic intent; stable eventId inbox plus next sourceVersion for each projector|reconcile ambiguous route receipt before resend or release; repair AP16 and gaps; retained source plus S3 manifest rebuild vNext; reconcile counts exact values versions then blue-green cutover|hottest account write partition or slowest projection sink|DynamoDB transactions and indexes Streams or Kinesis projection writes OpenSearch Redis S3 Athena client connections and replay|projection schemas capacity reservations security on-call rebuild drills reconciliation and compliance evidence|command p99 projection age by account gap age inbox duplicate rate search coverage rebuild ETA and reconciliation breaks|least-privilege context tables KMS keys PII token boundary access logs versioned evidence and policy retention|remove cache first then projection; migrate authority to Aurora only through dual-read evidence and fenced cutover|low read benefit strongly current cross-domain query or team cannot rebuild four stores|I keep risk reservation order execution and ledger authoritative; projections buy read isolation at a measured 50 reads per command and fail stale not unsafe|brokerage client submits BUY then sees receipt overlay until portfolio vNext reaches acceptedVersion|letting Redis OpenSearch or AP07 portfolio authorize available cash|C35 C46 C49 C92 C99 C100 C102 C109 C112 F17 F19 F20 A32 A34 A35 A54 A55 A106; Inference T9ARCHA; AWS retrieved 2026-08-22
ARCH|ARCB|Write-heavy market and execution pipeline|ingest normalize distribute and audit high-rate feed and execution facts with minimal synchronous fan-out|MSK is nearer when Kafka protocol connectors long retention partition control or team expertise are requirements; Firehose is only buffered destination delivery and Flink is earned by event-time state|authoritative=none; derived=RSP12 RSP13 RSP14; external=RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09 RSP10 RSP11|5000 events/s average 8000 peak 700 B 3 full consumers 12 percent top symbol|normalization p99 under 50 ms; sparse status p95 under 5 s; live lag alarm at 30 s|venueSession plus sourceSequence; instrument lanes; spread hot symbol only with source subsequence and deterministic merge watermark|append fast then async sparse projections; clients read authoritative status for fills|durable unmodified raw append before source acknowledgement and lossy normalization; stable source eventId executionId sequence and batch manifest|separate live and replay lanes; replay raw journal from checkpoint into isolated consumer; reconcile external order execution ledger clearing settlement authorities plus feed sequence and local sinks|top-symbol lane and downstream committed throughput not aggregate ingress|Kinesis or MSK bytes shards partitions consumers Firehose landing Flink state only when needed sparse writes storage transfer and replay|feed certification schema registry lane migration lag operations archive restore reconciliation and incident ownership|source gaps duplicates peak Bps top-symbol share per-lane utilization iterator or consumer lag checkpoint age sink commit and audit coverage|private feed sessions least privilege per consumer KMS PII exclusion immutable or integrity-validated raw evidence and access logs|move Kinesis to MSK for binding Kafka contract; split hot symbol only after versioned lane map and merge proof; move matching out of stream processor|matching authority ledger authority arbitrary global order or stateful Flink with no event-time need|I keep the stream transport and audit-only: source sequence restores order, stable IDs control duplicates, and no replay is declared repair before reconciliation|normalize venue execution reports then fan out ledger receipt surveillance and client status|calling Kinesis MSK Firehose Flink or S3 the matcher or ledger|C29 C31 C42 C44 C67 C72 C74 C75 C77 C80 C100 C109 C112 F01 F17 F28 F31 A88 A89 A90 A95 A97 A99; Inference T9ARCHB; AWS retrieved 2026-08-22
ARCH|ARCC|Mixed exchange platform|run deterministic latency-sensitive book matching while using serverless around APIs workflows projections notifications compliance and control planes|one global LMAX-style thread is only a bounded example; reject universal serialization and partition books when measured capacity fault isolation and products require it|authoritative=RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09; derived=RSP10 RSP11 RSP12 RSP13 RSP14; external=none|24000 commands/s across 8 book partitions at 180 us service time; 20 percent hottest book owns a dedicated partition with 0 co-located traffic; 6200/s for 2 seconds burst sensitivity|API acknowledgement p99 under 100 ms; admitted match command p99 under 1 ms is an unvalidated scenario target pending tail burst and queue load tests; external settlement is policy-SLO not match latency|account authority reserves then durable outbox sends orderVersion once to symbol single writer with writerEpoch and inputSequence|strong authoritative receipt lookup; projections are versioned stale-asOf; no cross-book snapshot claim|account transaction reservation order intent and outbox; matcher applies orderVersion once and journals before execution receipt|active appends durable replicated journal and snapshot; passive read-only replay then fenced epoch promotion; hottest-partition replay cap 400/s after 300/s safety; reconcile risk route execution ledger clearing settlement and providers|hottest book service time GC or IO leak; cross-account and cross-book coordination|fixed ECS or EC2 matcher capacity journals snapshots network storage plus variable API outbox projection workflow notification audit and replay|performance engineering host/runtime patching capacity headroom exchange certification deterministic testing failover game days and specialized on-call|per-book arrival service time utilization queue depth sequence gap tail latency journal fsync replication lag epoch conflicts and reconciliation breaks|separate matcher network account and compliance boundaries; KMS encrypted journals least privilege signed images access logs PII tokenization evidence retention|admit split migrate and replay from hottest-partition queue tail and safety envelope; change ownership only through versioned map drain snapshot epoch cutover and deterministic replay; Lambda remains around not inside matcher|low-volume loose-latency brokerage or team cannot operate deterministic long-lived core|I reserve on the account authority then route a versioned order through a durable outbox to one symbol writer; the journal and epoch make replay and failover provable while serverless owns the edges|cash reserved for account AAPL BUY then book partition emits immutable fill receipt that drives postings and clearing|Lambda as default matching loop or a stream consumer treated as price-time authority|C34 C46 C53 C91 C99 C105 C106 C107 C108 C109 C111 C112 F08 F09 F17 F37 F38 A58 A60 A101 A102 A119 A120 A121; Inference T9ARCHC; AWS retrieved 2026-08-22

ID	Variant	Problem / why	Nearest alternative	Authority	Workload	Latency target	Partition/order	Consistency/freshness	Idempotency/publication	Recovery/replay/reconciliation	Bottleneck	Variable cost	Fixed burden	Metrics	Security/audit	Migration path	Poor fit	Two-minute defense	Fintech example	Anti-pattern	Sources
ARCA	Read-heavy brokerage	serve portfolio history search analytics and live client views without moving financial decisions off command authority	Aurora PostgreSQL is nearer when relational transactions joins ad-hoc operations and one SQL authority dominate; reject extra projections until measured reads earn them	authoritative=RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09; derived=RSP10 RSP11 RSP12 RSP13 RSP14; external=none	1000 commands/s peak 50000 reads/s peak 4 projection writes/command	command acknowledgement p99 under 150 ms; read p95 under 2 s normal and stale-asOf after 30 s	accountId for AP12 and ledger; orderId lifecycle; source versions for projections; no global order	CQRS-lite; minVersion receipt overlay then bounded authority lookup; versioned stale-asOf views	RSP01 and AP16 atomic intent; stable eventId inbox plus next sourceVersion for each projector	reconcile ambiguous route receipt before resend or release; repair AP16 and gaps; retained source plus S3 manifest rebuild vNext; reconcile counts exact values versions then blue-green cutover	hottest account write partition or slowest projection sink	DynamoDB transactions and indexes Streams or Kinesis projection writes OpenSearch Redis S3 Athena client connections and replay	projection schemas capacity reservations security on-call rebuild drills reconciliation and compliance evidence	command p99 projection age by account gap age inbox duplicate rate search coverage rebuild ETA and reconciliation breaks	least-privilege context tables KMS keys PII token boundary access logs versioned evidence and policy retention	remove cache first then projection; migrate authority to Aurora only through dual-read evidence and fenced cutover	low read benefit strongly current cross-domain query or team cannot rebuild four stores	I keep risk reservation order execution and ledger authoritative; projections buy read isolation at a measured 50 reads per command and fail stale not unsafe	brokerage client submits BUY then sees receipt overlay until portfolio vNext reaches acceptedVersion	letting Redis OpenSearch or AP07 portfolio authorize available cash	C35 C46 C49 C92 C99 C100 C102 C109 C112 F17 F19 F20 A32 A34 A35 A54 A55 A106; Inference T9ARCHA; AWS retrieved 2026-08-22
ARCB	Write-heavy market and execution pipeline	ingest normalize distribute and audit high-rate feed and execution facts with minimal synchronous fan-out	MSK is nearer when Kafka protocol connectors long retention partition control or team expertise are requirements; Firehose is only buffered destination delivery and Flink is earned by event-time state	authoritative=none; derived=RSP12 RSP13 RSP14; external=RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09 RSP10 RSP11	5000 events/s average 8000 peak 700 B 3 full consumers 12 percent top symbol	normalization p99 under 50 ms; sparse status p95 under 5 s; live lag alarm at 30 s	venueSession plus sourceSequence; instrument lanes; spread hot symbol only with source subsequence and deterministic merge watermark	append fast then async sparse projections; clients read authoritative status for fills	durable unmodified raw append before source acknowledgement and lossy normalization; stable source eventId executionId sequence and batch manifest	separate live and replay lanes; replay raw journal from checkpoint into isolated consumer; reconcile external order execution ledger clearing settlement authorities plus feed sequence and local sinks	top-symbol lane and downstream committed throughput not aggregate ingress	Kinesis or MSK bytes shards partitions consumers Firehose landing Flink state only when needed sparse writes storage transfer and replay	feed certification schema registry lane migration lag operations archive restore reconciliation and incident ownership	source gaps duplicates peak Bps top-symbol share per-lane utilization iterator or consumer lag checkpoint age sink commit and audit coverage	private feed sessions least privilege per consumer KMS PII exclusion immutable or integrity-validated raw evidence and access logs	move Kinesis to MSK for binding Kafka contract; split hot symbol only after versioned lane map and merge proof; move matching out of stream processor	matching authority ledger authority arbitrary global order or stateful Flink with no event-time need	I keep the stream transport and audit-only: source sequence restores order, stable IDs control duplicates, and no replay is declared repair before reconciliation	normalize venue execution reports then fan out ledger receipt surveillance and client status	calling Kinesis MSK Firehose Flink or S3 the matcher or ledger	C29 C31 C42 C44 C67 C72 C74 C75 C77 C80 C100 C109 C112 F01 F17 F28 F31 A88 A89 A90 A95 A97 A99; Inference T9ARCHB; AWS retrieved 2026-08-22
ARCC	Mixed exchange platform	run deterministic latency-sensitive book matching while using serverless around APIs workflows projections notifications compliance and control planes	one global LMAX-style thread is only a bounded example; reject universal serialization and partition books when measured capacity fault isolation and products require it	authoritative=RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09; derived=RSP10 RSP11 RSP12 RSP13 RSP14; external=none	24000 commands/s across 8 book partitions at 180 us service time; 20 percent hottest book owns a dedicated partition with 0 co-located traffic; 6200/s for 2 seconds burst sensitivity	API acknowledgement p99 under 100 ms; admitted match command p99 under 1 ms is an unvalidated scenario target pending tail burst and queue load tests; external settlement is policy-SLO not match latency	account authority reserves then durable outbox sends orderVersion once to symbol single writer with writerEpoch and inputSequence	strong authoritative receipt lookup; projections are versioned stale-asOf; no cross-book snapshot claim	account transaction reservation order intent and outbox; matcher applies orderVersion once and journals before execution receipt	active appends durable replicated journal and snapshot; passive read-only replay then fenced epoch promotion; hottest-partition replay cap 400/s after 300/s safety; reconcile risk route execution ledger clearing settlement and providers	hottest book service time GC or IO leak; cross-account and cross-book coordination	fixed ECS or EC2 matcher capacity journals snapshots network storage plus variable API outbox projection workflow notification audit and replay	performance engineering host/runtime patching capacity headroom exchange certification deterministic testing failover game days and specialized on-call	per-book arrival service time utilization queue depth sequence gap tail latency journal fsync replication lag epoch conflicts and reconciliation breaks	separate matcher network account and compliance boundaries; KMS encrypted journals least privilege signed images access logs PII tokenization evidence retention	admit split migrate and replay from hottest-partition queue tail and safety envelope; change ownership only through versioned map drain snapshot epoch cutover and deterministic replay; Lambda remains around not inside matcher	low-volume loose-latency brokerage or team cannot operate deterministic long-lived core	I reserve on the account authority then route a versioned order through a durable outbox to one symbol writer; the journal and epoch make replay and failover provable while serverless owns the edges	cash reserved for account AAPL BUY then book partition emits immutable fill receipt that drives postings and clearing	Lambda as default matching loop or a stream consumer treated as price-time authority	C34 C46 C53 C91 C99 C105 C106 C107 C108 C109 C111 C112 F08 F09 F17 F37 F38 A58 A60 A101 A102 A119 A120 A121; Inference T9ARCHC; AWS retrieved 2026-08-22

The following reciprocal route manifest is the machine-checkable join between each architecture and the responsibility, invariant, and lifecycle contracts. It prevents an architecture narrative from silently dropping a safety rule.

Model details · task9 routes

ROUTE|ARCA|RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09 RSP10 RSP11 RSP12 RSP13 RSP14|INV01 INV02 INV03 INV04 INV05 INV06 INV07 INV08 INV09 INV10|CASE01 CASE02 CASE03 CASE04 CASE05 CASE06 CASE07 CASE08 CASE09 CASE10 CASE11 CASE12 CASE13
ROUTE|ARCB|RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09 RSP10 RSP11 RSP12 RSP13 RSP14|INV01 INV02 INV03 INV04 INV05 INV06 INV07 INV08 INV09 INV10|CASE01 CASE02 CASE03 CASE04 CASE05 CASE06 CASE07 CASE08 CASE09 CASE10 CASE11 CASE12 CASE13
ROUTE|ARCC|RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09 RSP10 RSP11 RSP12 RSP13 RSP14|INV01 INV02 INV03 INV04 INV05 INV06 INV07 INV08 INV09 INV10|CASE01 CASE02 CASE03 CASE04 CASE05 CASE06 CASE07 CASE08 CASE09 CASE10 CASE11 CASE12 CASE13

Architecture	Responsibilities	Invariants	Cases
ARCA	RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09 RSP10 RSP11 RSP12 RSP13 RSP14	INV01 INV02 INV03 INV04 INV05 INV06 INV07 INV08 INV09 INV10	CASE01 CASE02 CASE03 CASE04 CASE05 CASE06 CASE07 CASE08 CASE09 CASE10 CASE11 CASE12 CASE13
ARCB	RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09 RSP10 RSP11 RSP12 RSP13 RSP14	INV01 INV02 INV03 INV04 INV05 INV06 INV07 INV08 INV09 INV10	CASE01 CASE02 CASE03 CASE04 CASE05 CASE06 CASE07 CASE08 CASE09 CASE10 CASE11 CASE12 CASE13
ARCC	RSP01 RSP02 RSP03 RSP04 RSP05 RSP06 RSP07 RSP08 RSP09 RSP10 RSP11 RSP12 RSP13 RSP14	INV01 INV02 INV03 INV04 INV05 INV06 INV07 INV08 INV09 INV10	CASE01 CASE02 CASE03 CASE04 CASE05 CASE06 CASE07 CASE08 CASE09 CASE10 CASE11 CASE12 CASE13

Variant A — read-heavy brokerage

Diagram text source

flowchart LR
  Client[Client] --> API[API Gateway plus command Lambda]
  API -->|clientOrderKey| Order[(AUTHORITY: order receipt and lifecycle)]
  Order -->|accountVersion exact units| Risk[(AUTHORITY: AP12 risk reservation)]
  Risk -->|atomic reservation plus AP16 outbox| Route[(AUTHORITY: durable route attempt)]
  Route -->|orderId orderVersion routeAttemptId| Venue[AUTHORITY BOUNDARY: external venue or owned internal matcher]
  Venue -->|accepted executionId exact terms| Exec[(AUTHORITY: unique execution receipt)]
  Venue -->|reject or proven cancel remainder| Order
  Exec -->|order version and CumQty| Order
  Exec -->|trade-date postingSetId| Ledger[(AUTHORITY: ledger posting sets)]
  Exec -->|classified obligation| Clear[(AUTHORITY: clearing obligation)]
  Clear -->|providerRequestId| Provider[EXTERNAL: clearer bank custodian depository]
  Provider -->|finality evidence or classified failure| Settle[(AUTHORITY: settlement status)]
  Settle -->|linked completion reclassification or correction posting| Ledger
  Settle -->|governed consume release or break| Risk
  Order -->|semantic AP16 outbox| Stream[DynamoDB Streams relay]
  Ledger -->|semantic AP16 outbox| Stream
  Stream -. async eventId and sourceVersion .-> K[Kinesis retained fan-out]
  K -. accountId .-> Port[(DERIVED: DynamoDB portfolio vN)]
  K -. orderId .-> Search[(DERIVED: OpenSearch index vN)]
  K -. accountId .-> Cache[(DERIVED: Redis disposable cache)]
  K -. manifest partition .-> Lake[(DERIVED: S3 plus Athena analytics)]
  Client --> Query[Query API minVersion]
  Query --> Port
  Query --> Search
  Query --> Cache
  Query -. receipt overlay or bounded authority lookup .-> Order
  Rebuild[S3 authority export plus catch-up] -. async blue-green .-> Port
  Rebuild -. async blue-green .-> Search
  Route -. timeout or ambiguous receipt .-> Recon[Reconciliation owner]
  Recon -. route receipt or governed release .-> Route
  Recon -. execution identity and quantity .-> Exec
  Recon -. posting sets and balances .-> Ledger
  Recon -. obligation status .-> Clear
  Recon -. finality evidence .-> Settle
  Recon -. reservation consume or release .-> Risk
  Recon -. watermarks and coverage .-> Port
  Recon -. watermarks and coverage .-> Search
  Venue -. drop copy and status .-> Recon
  Provider -. receipts and statements .-> Recon

Inference T9AWS01: start at CQRS-lite. A command transaction stores the durable receipt, order/AP12 mutation, and AP16 semantic outbox. Streams relays only that semantic envelope; it does not infer one transaction from nearby CDC records (C99; A101,A102, retrieved 2026-08-22). Risk, reservation, order state, execution receipt, and posting set stay on the command side. Portfolio, P&L, search, cache, statements, analytics, and live-client messages are versioned derived stores.

The reservation does not imply delivery. Its local transaction creates the durable route attempt; only the venue/internal matcher receipt creates the unique execution fact. Route timeout remains ambiguous and HELD until status or drop-copy reconciliation proves acceptance, rejection, or a governed release. Execution then drives order quantity, trade-date ledger posting, and clearing; settlement evidence drives linked completion/reclassification posting and reservation consume/release or an owned break.

Inference T9AWS02: Read-your-writes returns {orderId, acceptedVersion}. minVersion waits within the stated read SLO, overlays the receipt, or performs a bounded authority lookup; it never claims a transactional cross-domain portfolio snapshot. At lag budget breach, serve a clear asOf, freeze stale widgets, shed search and analytics refresh, and protect command/ledger capacity. Clients reconnect with their last acknowledged view version and fetch a catch-up range or current snapshot; WebSocket/AppSync transport does not prove ordered lossless receipt (C54; A54,A55, retrieved 2026-08-22).

Inference T9AWS03: Rebuild each store independently: export authoritative domains to a versioned S3 manifest, load portfolio-vNext or search-vNext, replay the gap with side-effects suppressed, compare exact totals/counts/version coverage, then switch the alias conditionally. Keep the old build as rollback. Redis is warmed from validated projections and can be dropped at any time. OpenSearch is for relevance/filter/aggregation, not balance authorization (C92,C100; A32,A34,A106, retrieved 2026-08-22).

Inference T9AWS04: Aurora PostgreSQL is the nearer fit when one relational authority must enforce multi-row invariants, operations depend on SQL joins/ad-hoc investigation, and read replicas plus deliberate projections meet measured load. Select the engine, endpoint, transaction isolation, replica-lag, and scaling contract explicitly; “serverless” does not turn replicas into current authorities (C56, C92; A35,A62,A112, retrieved 2026-08-22).

Variant B — write-heavy market and execution pipeline

Diagram text source

flowchart LR
  Upstream[EXTERNAL AUTHORITY: order risk reservation and routing] --> Matcher[EXTERNAL AUTHORITY: venue or matcher execution]
  Feed[EXTERNAL: venue feed or execution session] -->|unmodified bytes sessionId sourceSequence| Raw[(LOCAL: durable unmodified ingress journal)]
  Matcher -->|execution report unmodified| Raw
  Raw -->|ack source only after durable append| Ack[Acknowledgement boundary]
  Raw -->|replayable raw record| Norm[LOCAL: lossy feed/session normalization]
  Raw -. immutable evidence copy .-> Audit[(LOCAL AUDIT: durable raw S3 copy)]
  Norm -->|instrument key or governed lane key| Log[Kinesis or deliberate MSK log]
  Log -. async per-lane order .-> Sparse[(DERIVED: sparse status projection)]
  Log -. async batches .-> Firehose[Firehose buffered delivery]
  Firehose -. async .-> Lake[(DERIVED: S3 analytics)]
  Log -. event-time only when earned .-> Flink[Flink keyed state]
  Flink -. async .-> Surv[(DERIVED: surveillance)]
  Log -. executionId and orderVersion .-> Receipt[(LOCAL DERIVED: idempotent receipt inbox)]
  Receipt -. stable receipt reference .-> Upstream
  Receipt -. accepted external identity .-> Ledger[EXTERNAL AUTHORITY: ledger posting]
  Receipt -. accepted external identity .-> Clear[EXTERNAL AUTHORITY: clearing obligation]
  Clear -. instruction .-> Settle[EXTERNAL AUTHORITY: settlement status]
  Ledger -. source versions .-> Portfolio[EXTERNAL DERIVED: portfolio and notification]
  Replay[Isolated replay lane plus manifest] -. capped async .-> Sparse
  Recon[LOCAL reconciliation owner] -. source gaps and acknowledgement coverage .-> Feed
  Recon -. order route and execution receipt .-> Upstream
  Recon -. execution authority .-> Matcher
  Recon -. posting evidence .-> Ledger
  Recon -. obligation evidence .-> Clear
  Recon -. finality evidence .-> Settle
  Recon -. receipt coverage .-> Receipt
  Recon -. audit coverage .-> Audit

This variant locally owns RSP12–RSP14 derived pipeline work only. RSP01–RSP11 remain explicit external authorities or external derived responsibilities; the local idempotent receipt inbox never promotes a feed record into execution, ledger, clearing, settlement, portfolio, or notification authority.

Inference T9AWS05: Append the unmodified ingress bytes and source/session identity to the durable raw journal first. Acknowledge the source only after that append is durable; lossy normalization and the S3 evidence copy consume the journal. Normalize FIX/session framing into stable sourceId, sessionId, sourceSequence, eventId, schema version, event/business time, ingestion time, instrument, and correction lineage. Batch network calls and aggregate only after every consumer can deaggregate and preserve identity/order; a partial batch keeps per-entry results and retries failures only (C72,C73; A96,A98, retrieved 2026-08-22).

Inference T9AWS06: Kinesis is nearer when AWS-native managed shards, bounded retention, and a small consumer set fit. MSK is nearer when the Kafka protocol, connectors, consumer-group ecosystem, topic retention/partition control, or existing operating competence is binding. Kafka transactions stop at compatible Kafka operations; neither MSK nor Kinesis extends them into a ledger/API (C29; F28; A30, retrieved 2026-08-22). Firehose is buffered destination delivery, not the source log. Flink earns its fixed state/checkpoint burden only for event-time windows, joins, watermarks, late-data rules, or continuous state; it is not the matcher or ledger (C31,C67; F31; A88,A89, retrieved 2026-08-22).

Hot-symbol rule: if one instrument remains below the single-lane envelope, keep its source order intact. If it must be spread, a single authoritative normalizer assigns (instrumentSourceSequence, laneMapVersion, subSequence) before hashing into lanes. Downstream merge waits for a source-sequence watermark across every lane, rejects duplicate identities, parks gaps, and cuts to a new lane map only after the old map drains at a recorded sequence. Without that source sequence and merge proof, spreading deliberately destroys the order the business requires. No Kinesis shard, Kafka partition, or table implies global order (C34,C75,C79).

Live traffic owns the primary allocation; replay has an explicit cap and safety reserve. If total committed downstream capacity is not greater than live plus safety, the safe replay rate is zero: pause replay, shed optional consumers, or add proven capacity. A caught-up checkpoint proves position only. Complete repair additionally reconciles venue sequence coverage, executions, postings, audit objects, and each sink watermark (FSR03–FSR05,FSR09,RBK03–RBK05).

Variant C — mixed exchange platform

Diagram text source

flowchart LR
  Client[Client] --> API[API Gateway plus Lambda command edge]
  API -->|accountId command| Risk[(AUTHORITY: AP12 account risk and reservation)]
  Risk -->|atomic order intent plus AP16 outbox| Route[Durable router]
  Route -. async orderId orderVersion instrument .-> Match[ACTIVE AUTHORITY: ECS or EC2 single-writer book core]
  Match -->|active writer appends admitted input and snapshots| Journal[(AUTHORITY: durable replicated journal plus snapshots)]
  Match -->|executionId bookSequence exact terms| Exec[(AUTHORITY: execution receipt)]
  Exec -->|trade-date execution and obligation posting sets| Ledger[(AUTHORITY: cash and securities posting sets)]
  Exec -. async .-> Clear[AUTHORITY: clearing obligation]
  Clear -. external instruction .-> External[EXTERNAL: clearer bank custodian depository]
  External -. receipt statement .-> Settle[(AUTHORITY: settlement status)]
  Settle -->|linked settlement-date completion failure reclassification or correction posting| Ledger
  Settle -->|consume release or classified break under policy| Risk
  Ledger -. outbox async .-> Proj[(DERIVED: portfolio search clients compliance)]
  Journal -->|read-only snapshot plus journal replay| Passive[PASSIVE: cannot append]
  Fence[Promotion gate: fence old writer and routing; acquire next epoch] --> Passive
  Passive -. only after promotion becomes active may append .-> Journal
  Recon[Reconciliation owner] -. reservation and release evidence .-> Risk
  Recon -. route receipt .-> Route
  Recon -. execution identity and quantity .-> Exec
  Recon -. posting sets and balances .-> Ledger
  Recon -. clearing obligations .-> Clear
  Recon -. finality completion or failure .-> Settle
  Recon -. venue and provider evidence .-> External

The account-versus-symbol handoff is explicit:

1. RSP03 conditionally reserves exact cash/securities under accountVersion.
2. The same local transaction records order intent and an AP16 outbox envelope with reservationId, orderId, orderVersion, instrument, and expiry policy.
3. RSP05 publishes and records routeAttemptId; the symbol matcher applies an order version once under writerEpoch and inputSequence.
4. The matcher journals admitted input before emitting an immutable executionId receipt. Order and reservation consume/release only from that receipt or a governed rejection/ambiguity resolution.
5. RSP09 records trade-date execution/obligation posting sets without claiming final settlement; RSP07 creates the clearing obligation and RSP08 tracks settlement completion/failure separately. Finality evidence then creates a linked settlement-date completion, reclassification, reversal/difference posting, reservation release/consume, or classified break under the named product policy. These are distinct governed facts, not a universal jurisdiction-specific accounting rule.

When reservation succeeds but matching is delayed, the order is ROUTE_PENDING and reservation stays HELD. A proven rejection releases it. An ambiguous timeout triggers status/drop-copy lookup and a reconciliation break before release or resend. A staleness deadline is a product policy that can cancel the remaining order only after the router/matcher authority proves the outcome; it never assumes absence from timeout (CASE13,FSR02,FSR07).

Inference T9AWS07: run the match core as a long-lived capacity-controlled process on ECS/EC2 or a specialized runtime. One writer per book makes price-time or other governed priority deterministic. Keep IO outside the loop, journal inputs, snapshot state, replay deterministically in tests, and publish receipts through durable output. LMAX supports this as one example, not the exact topology or a portable throughput promise (C53,C111; F09; A58,A60, retrieved 2026-08-22). Lambda remains useful for APIs, workflow/process managers, outbox relay, projections, notices, compliance reports, and control planes; it is not the default low-latency matching loop.

Inference T9AWS08: Ownership uses a lease plus monotonic writerEpoch. A promoted passive must load a validated snapshot, replay the complete journal after its checkpoint, acquire the next epoch, and prove the old writer fenced before accepting. Every command and output carries the epoch; stale output is rejected. Failback is a new fenced migration, not an unfenced role swap (C105,C106; A119,A120,A121, retrieved 2026-08-22). The passive reads the replicated journal and snapshot; it cannot append until routing and the old writer are fenced and it owns the new epoch. Resume unrestricted trading only after separate risk/reservation, route, execution, ledger, clearing, settlement, bank, and custodian manifests reconcile.

Account versus symbol partitioning

Model details · task9 partitions

PARTITION|PART01|accountId|RSP03 RSP09|cash securities reservation balance and ledger sequence inside one account asset scope|institutional or omnibus account can dominate one key|multi-account transfer and symbol matching need intent receipt and reconciliation rather than hidden distributed transaction|fence account writer; replay exact account versions; rebuild projections separately|price-time order across clients for one symbol|versioned account-shard map; stop writes drain old version copy validate totals acquire new epoch|ARCA ARCB ARCC
PARTITION|PART02|symbol or bookId|RSP06 RSP12|price-time or governed matching priority and market-feed sequence for one instrument|open news or halt can make one symbol irreducibly hot|account risk reservation spans symbols; route accepted orderVersion from account authority to book once|fence book writer; restore snapshot then parent journal order; reconcile every execution receipt|whole-account cash securities or tenant fairness|versioned ownership and lane map; halt or drain at sequence snapshot cut over new epoch then resume|ARCA ARCB ARCC
PARTITION|PART03|tenantId|RSP01 RSP13 RSP14|tenant isolation export compliance or policy sequence when actually required|large tenant monopolizes lane and quiet tenants starve|orders accounts and books within tenant remain separate invariants; cross-tenant transfer is exceptional coordination|tenant lane rebalances independently but replay can amplify all tenant work|hot-book matching or high-cardinality accounts when tenant order is unnecessary|split tenant by governed subdomain key with dual-read manifest and explicit fairness quotas|ARCA ARCB ARCC
PARTITION|PART04|composite or lane key|RSP05 RSP06 RSP10 RSP12|accountId plus instrument protects position projection; symbol plus lane spreads derived load only with source merge sequence|wrong salt can remain skewed and creates N-way fan-out|broader cash invariant and whole-symbol order move outside key; merge and gap coordination become mandatory|replay every lane under laneMapVersion then merge by source sequence and watermark|authority without a source sequence or operation needing atomic cross-lane order|publish new mapVersion stop old-map admission drain to cutoverSequence validate no gaps then enable new lanes|ARCA ARCB ARCC

ID	Key	Responsibility routes	Protected invariant/order	Skew risk	Cross-partition cost	Failure/replay	Poor fit	Migration/cutover	Architecture routes
PART01	accountId	RSP03 RSP09	cash securities reservation balance and ledger sequence inside one account asset scope	institutional or omnibus account can dominate one key	multi-account transfer and symbol matching need intent receipt and reconciliation rather than hidden distributed transaction	fence account writer; replay exact account versions; rebuild projections separately	price-time order across clients for one symbol	versioned account-shard map; stop writes drain old version copy validate totals acquire new epoch	ARCA ARCB ARCC
PART02	symbol or bookId	RSP06 RSP12	price-time or governed matching priority and market-feed sequence for one instrument	open news or halt can make one symbol irreducibly hot	account risk reservation spans symbols; route accepted orderVersion from account authority to book once	fence book writer; restore snapshot then parent journal order; reconcile every execution receipt	whole-account cash securities or tenant fairness	versioned ownership and lane map; halt or drain at sequence snapshot cut over new epoch then resume	ARCA ARCB ARCC
PART03	tenantId	RSP01 RSP13 RSP14	tenant isolation export compliance or policy sequence when actually required	large tenant monopolizes lane and quiet tenants starve	orders accounts and books within tenant remain separate invariants; cross-tenant transfer is exceptional coordination	tenant lane rebalances independently but replay can amplify all tenant work	hot-book matching or high-cardinality accounts when tenant order is unnecessary	split tenant by governed subdomain key with dual-read manifest and explicit fairness quotas	ARCA ARCB ARCC
PART04	composite or lane key	RSP05 RSP06 RSP10 RSP12	accountId plus instrument protects position projection; symbol plus lane spreads derived load only with source merge sequence	wrong salt can remain skewed and creates N-way fan-out	broader cash invariant and whole-symbol order move outside key; merge and gap coordination become mandatory	replay every lane under laneMapVersion then merge by source sequence and watermark	authority without a source sequence or operation needing atomic cross-lane order	publish new mapVersion stop old-map admission drain to cutoverSequence validate no gaps then enable new lanes	ARCA ARCB ARCC

No table or stream supplies global order by implication. Global serialization is possible only by accepting a common coordinator/bottleneck. These designs choose the smallest scope that protects the invariant and coordinate the account-risk-to-symbol-match handoff explicitly (C34,C41).

Quantified selection envelope

The diagrams show responsibilities; the calculations test whether the busiest lane can support them. Aggregate capacity is not spare capacity for a serialized hot book. Treat the average, hot-share, service-time, and recovery branches as separate checks, and preserve any unvalidated latency target as a measurement still to be made.

These inputs are assumptions, not AWS promises or measured production facts. The shared cost model is the calculation authority and Task 9 validation compares this complete reader-visible copy against it. Task 10's canonical dated eu-west-1 model supplies ARCA's priced break-even reconciliation; the table below remains scoped to Task 9's falsifiable ratios and capacity envelopes (C49,C112; F19,F20).

Kind	Key	Value or equation	Unit
INPUT	a_commands_peak_rps	1000	commands/s
INPUT	a_reads_peak_rps	50000	reads/s
INPUT	a_low_reads_peak_rps	12000	reads/s
INPUT	a_authoritative_writes_per_command	4	writes/command
INPUT	a_projection_writes_per_command	4	writes/command
INPUT	a_projection_write_migration_trigger	6	writes/command
INPUT	b_average_events_rps	5000	events/s
INPUT	b_peak_events_rps	8000	events/s
INPUT	b_payload_bytes	700	B/event
INPUT	b_fanout_consumers	3	consumers
INPUT	b_top_symbol_share	0.12	ratio
INPUT	b_hot_share_sensitivity	0.15	ratio
INPUT	b_single_lane_capacity_rps	1000	events/s
INPUT	b_recovery_capacity_rps	12000	committed events/s
INPUT	b_live_allocation_rps	8000	events/s
INPUT	b_safety_reservation_rps	1000	events/s
INPUT	b_replay_cap_rps	3000	events/s
INPUT	b_backlog_records	4500000	events
INPUT	b_zero_spare_capacity_rps	9000	committed events/s
INPUT	c_total_arrival_rps	24000	commands/s
INPUT	c_match_partitions	8	partitions
INPUT	c_service_time_us	180	us/command
INPUT	c_top_symbol_share	0.20	ratio
INPUT	c_hot_share_sensitivity	0.24	ratio
INPUT	c_service_time_sensitivity_us	220	us/command
INPUT	c_hot_dedicated_partition	1	boolean 1=yes
INPUT	c_hot_partition_other_live_rps	0	commands/s
INPUT	c_hot_safety_reservation_rps	300	commands/s
INPUT	c_hot_replay_cap_rps	400	commands/s
INPUT	c_hot_backlog_commands	240000	commands
INPUT	c_hot_zero_capacity_rps	5100	commands/s
INPUT	c_burst_arrival_rps	6200	commands/s
INPUT	c_burst_duration_seconds	2	s
FORMULA	a_read_write_ratio	a_reads_peak_rps / a_commands_peak_rps	reads/command
FORMULA	a_total_write_amplification	a_authoritative_writes_per_command + a_projection_writes_per_command	writes/command
FORMULA	b_raw_bytes_per_second	events_rps * b_payload_bytes	B/s
FORMULA	b_fanout_bytes_per_second	raw_bytes_per_second * b_fanout_consumers	B/s
FORMULA	b_hot_symbol_rate	events_rps * symbol_share	events/s
FORMULA	b_replay_rate	max(0,min(replay_cap,recovery-live-safety))	events/s
FORMULA	b_drain_time	backlog / replay_rate; infinite when replay_rate <= 0	s
FORMULA	c_partition_arrival	c_total_arrival_rps / c_match_partitions	commands/s/partition
FORMULA	c_utilization	arrival_rps * service_time_us / 1000000	ratio
FORMULA	c_hottest_symbol_utilization	c_total_arrival_rps * share * service_time_us / 1000000	ratio
FORMULA	c_hot_partition_live	hottest_symbol_rps + other_live_rps	commands/s
FORMULA	c_hot_arithmetic_spare	service_capacity - hot_partition_live	commands/s
FORMULA	c_hot_replay_rate	max(0,min(replay_cap,service_capacity-hot_live-safety))	commands/s
FORMULA	c_hot_drain_time	hot_backlog / hot_replay_rate; infinite when replay_rate <= 0	s
FORMULA	c_burst_queue_growth	max(0,burst_arrival-service_capacity) * burst_duration	commands
RESULT	a_read_write_ratio	50.00	reads/command
RESULT	a_low_read_write_ratio	12.00	reads/command
RESULT	a_projection_write_amplification	4	writes/command
RESULT	a_total_write_amplification	8	writes/command
RESULT	a_migration_trigger	REASSESS_AT_6_PROJECTION_WRITES	state
RESULT	b_average_raw_Bps	3500000	B/s
RESULT	b_peak_raw_Bps	5600000	B/s
RESULT	b_average_fanout_Bps	10500000	B/s
RESULT	b_peak_fanout_Bps	16800000	B/s
RESULT	b_top_symbol_average_rps	600	events/s
RESULT	b_top_symbol_peak_rps	960	events/s
RESULT	b_hot_sensitivity_peak_rps	1200	events/s
RESULT	b_hot_sensitivity_state	OVER_SINGLE_LANE	state
RESULT	b_live_capacity_percent	66.67	%
RESULT	b_replay_capacity_percent	25.00	%
RESULT	b_safety_capacity_percent	8.33	%
RESULT	b_replay_rate_rps	3000	events/s
RESULT	b_backlog_drain_seconds	1500.00	s
RESULT	b_backlog_drain_minutes	25.00	min
RESULT	b_zero_spare_state	NO_SAFE_DRAIN	state
RESULT	c_partition_arrival_rps	3000.00	commands/s/partition
RESULT	c_partition_service_capacity_rps	5555.56	commands/s/partition
RESULT	c_partition_utilization	0.5400	ratio
RESULT	c_partition_headroom_percent	46.00	%
RESULT	c_hottest_symbol_rps	4800	commands/s
RESULT	c_hottest_symbol_utilization	0.8640	ratio
RESULT	c_hot_share_sensitivity_rps	5760	commands/s
RESULT	c_hot_share_sensitivity_utilization	1.0368	ratio
RESULT	c_service_time_sensitivity_utilization	1.0560	ratio
RESULT	c_hottest_sensitivity_state	OVER_CAPACITY	state
RESULT	c_hot_partition_assignment	DEDICATED_HOT_BOOK	state
RESULT	c_hot_partition_other_live_rps	0	commands/s
RESULT	c_hot_partition_live_rps	4800	commands/s
RESULT	c_hot_arithmetic_spare_rps	755.56	commands/s
RESULT	c_hot_partition_headroom_percent	13.60	%
RESULT	c_hot_safety_reservation_rps	300	commands/s
RESULT	c_hot_effective_replay_rps	400	commands/s
RESULT	c_hot_backlog_drain_seconds	600.00	s
RESULT	c_hot_backlog_drain_minutes	10.00	min
RESULT	c_hot_zero_spare_state	NO_SAFE_DRAIN	state
RESULT	c_burst_excess_rps	644.44	commands/s
RESULT	c_burst_queue_growth_commands	1288.89	commands
RESULT	c_tail_service_capacity_rps	4545.45	commands/s
RESULT	c_p99_latency_state	UNVALIDATED_LOAD_TEST_REQUIRED	state

Interpretation by variant:

• Variant A: the base planning point has 50 reads per command, four deliberate projection writes, and eight total logical writes. Task 10's dated model puts ARCA's 50 reads/command below its 75.462912 reads/write cost break-even and at -$887.203238/month; choose ARCA only when the measured 95 ms p99 read-latency gain, 2-second freshness, and command/read isolation justify that cost. The lower-read sensitivity is 12 reads/command. Reassess when measured read work avoided no longer covers variable projection/storage/rebuild work and fixed ownership, or when projection fan-out reaches six writes/command.
• Variant B: raw traffic is 3,500,000 B/s average and 5,600,000 B/s peak; three full consumers turn that into 10,500,000 and 16,800,000 downstream B/s before protocol/storage amplification. A 12% top symbol reaches 960 events/s at peak against the 1,000-event/s planning lane; 15% reaches 1,200 and forces admission, a different source-order/merge design, or a new substrate. Of 12,000 committed events/s, the model reserves 66.67% live, 25% replay, and 8.33% safety; 4,500,000 events drain in 1,500 seconds (25 minutes). At 9,000 total capacity, live plus safety leaves no safe drain.
• Variant C: the average across eight partitions is 3,000 commands/s, 0.54 utilization, and 46% arithmetic headroom at 180 us, but it is not an admission or latency proof. The 20% hottest book has a dedicated partition, so its 4,800/s includes 0/s co-located book traffic; utilization is 0.864, arithmetic spare is 755.56/s, and headroom is 13.60%. After a 300/s hot-book safety reserve, effective replay is capped at 400/s; 240,000 commands drain in 600.00 seconds (10.00 minutes). A 5,100/s zero-capacity case leaves no safe hot-book replay. A 6,200/s burst for 2 seconds exceeds nominal service capacity by 644.44/s and grows the queue by 1,288.89 commands before retries or downstream delay. A 24% hot share reaches 5,760/s and 1.0368 utilization; a 220 us service-time tail gives 4,545.45/s capacity and 1.0560 utilization. The sub-1-ms p99 is therefore an unvalidated scenario target until measured burst, tail, queue, journal, and replay load tests prove it. Admission, migration, and replay use this hottest-partition envelope, never aggregate spare on unrelated books.

What to measure before choosing:

• A: command/read distribution, read work avoided, projection writes and bytes, cache hit attribution, per-account skew, freshness/error budgets, full rebuild duration, and fixed store/on-call/security ownership. Reassess below the economic break-even from Task 7 or at six projection writes per command.
• B: serialized average/peak/p99 bytes, session and instrument rate/share, per-lane throttling, downstream committed throughput, consumer fan-out, checkpoint/restart time, archive completeness, and safe replay rate. Migrate the lane or substrate when hottest-source demand crosses one lane or no safe drain remains.
• C: per-book arrival distribution, measured service time and p99.9, GC/IO pauses, journal/replication latency, snapshot replay time, failover epoch conflicts, and specialist on-call burden. Admit, split, migrate, and replay from the hottest partition's live load, queue tail, arithmetic spare, and safety reservation; aggregate capacity on unrelated books is not available.

Reliability and repository mappings

The local fintech application and SSE notes are cross-reference evidence only. They help locate existing order-handler, trade-executor, portfolio-projector, SQS, and Kinesis examples (R01–R06; X01–X07); they do not override the domain authorities, FIX/PFMI vocabulary, or current AWS owner documentation in this chapter. In particular, an application field named orderStatus or a demo consumer is not proof of venue execution, settlement, one-time effect, or ledger authority.

This table maps, rather than repeats, the reviewed repository and reliability contracts. Every design retains prevent/detect/contain/repair and names the residual ambiguity.

Model details · task9 controls

CONTROL|ARCA|CS01 CS02 CS03 CS04 CS05 CS06 CS07 CS08 CS09 CS10 CS11 CS12|FSR01 FSR02 FSR03 FSR04 FSR05 FSR06 FSR07 FSR08 FSR09 FSR10 FSR11 FSR12|atomic receipt reservation order and AP16 outbox plus exact ledger|projection age gaps duplicate inbox rebuild and financial control totals|serve receipt or stale-asOf view shed derived work freeze affected account on invariant break|repair outbox rebuild vNext reconcile authority projections and external evidence|cross-domain client view can show different asOf versions until reconciled
CONTROL|ARCB|CS01 CS02 CS03 CS04 CS05 CS06 CS07 CS08 CS09 CS10 CS11 CS12|FSR01 FSR02 FSR03 FSR04 FSR05 FSR06 FSR07 FSR08 FSR09 FSR10 FSR11 FSR12|stable source sequence identity batch manifest journal and limited fan-out|feed gaps duplicates hot-key share lag sink commit and audit coverage|protect live lane pause replay isolate poison symbol shed analytics|restore sequence range replay isolated consumers reconcile executions postings and sinks|venue resend or ambiguous acknowledgement can remain pending break
CONTROL|ARCC|CS01 CS02 CS03 CS04 CS05 CS06 CS07 CS08 CS09 CS10 CS11 CS12|FSR01 FSR02 FSR03 FSR04 FSR05 FSR06 FSR07 FSR08 FSR09 FSR10 FSR11 FSR12|account reservation durable handoff book journal writer epoch unique receipt and exact posting|per-book sequence queue tail journal replication epoch and end-to-end reconciliation|halt affected book fence writer keep ambiguous orders pending protect ledger|restore snapshot replay journal promote fenced epoch rebuild projections reconcile externals|old writer or provider may have acted until fencing and evidence prove otherwise

Architecture	CS routes	FSR routes	Prevent	Detect	Contain	Repair	Residual ambiguity
ARCA	CS01 CS02 CS03 CS04 CS05 CS06 CS07 CS08 CS09 CS10 CS11 CS12	FSR01 FSR02 FSR03 FSR04 FSR05 FSR06 FSR07 FSR08 FSR09 FSR10 FSR11 FSR12	atomic receipt reservation order and AP16 outbox plus exact ledger	projection age gaps duplicate inbox rebuild and financial control totals	serve receipt or stale-asOf view shed derived work freeze affected account on invariant break	repair outbox rebuild vNext reconcile authority projections and external evidence	cross-domain client view can show different asOf versions until reconciled
ARCB	CS01 CS02 CS03 CS04 CS05 CS06 CS07 CS08 CS09 CS10 CS11 CS12	FSR01 FSR02 FSR03 FSR04 FSR05 FSR06 FSR07 FSR08 FSR09 FSR10 FSR11 FSR12	stable source sequence identity batch manifest journal and limited fan-out	feed gaps duplicates hot-key share lag sink commit and audit coverage	protect live lane pause replay isolate poison symbol shed analytics	restore sequence range replay isolated consumers reconcile executions postings and sinks	venue resend or ambiguous acknowledgement can remain pending break
ARCC	CS01 CS02 CS03 CS04 CS05 CS06 CS07 CS08 CS09 CS10 CS11 CS12	FSR01 FSR02 FSR03 FSR04 FSR05 FSR06 FSR07 FSR08 FSR09 FSR10 FSR11 FSR12	account reservation durable handoff book journal writer epoch unique receipt and exact posting	per-book sequence queue tail journal replication epoch and end-to-end reconciliation	halt affected book fence writer keep ambiguous orders pending protect ledger	restore snapshot replay journal promote fenced epoch rebuild projections reconcile externals	old writer or provider may have acted until fencing and evidence prove otherwise

The reference repository's Level 2 repair—transactional outbox, durable idempotency, execution receipt, idempotent projectors—precedes all three. Level 3 adds explicit risk/reservation, match/venue, clearing/settlement, ledger, and reconciliation authorities. Changing Lambda to ECS without those boundaries fixes neither CS01–CS11 nor any financial invariant.

Audit compliance security and time semantics

Inference T9AWS09: Evidence lineage uses stable identifiers from client command through policy decision, reservation, route attempt, matcher/venue sequence, execution, clearing obligation, settlement receipt, posting set, projection build, notice, and reconciliation case. Every hop retains schema/policy version, causation and correlation IDs, owner, and access classification. Hash/checksum manifests and CloudTrail integrity validation can detect named artifact changes; S3 Object Lock can protect selected object versions under retention or legal hold. These are mechanism scopes, not a claim that all required evidence was captured or that any jurisdiction's compliance duty was satisfied (C50,C109; A38-A41,A122, retrieved 2026-08-22).

Security boundaries:

• separate command, matcher, ledger, read, and compliance accounts/roles where blast radius and segregation of duties require it; use temporary credentials, least privilege, rule/table/key-specific policies, and independent approval for posting corrections and retention overrides;
• encrypt transport and storage with an explicit KMS key-policy/rotation/ recovery owner; encryption protects confidentiality, not business correctness or record completeness;
• isolate/tokenize PII before market-data, analytics, and surveillance fan-out; preserve reversible mapping only in the authorized identity boundary;
• log privileged reads, policy changes, epoch/route changes, evidence exports, legal-hold actions, and correction approvals; alert on denied and unexpected access as well as missing expected evidence;
• treat retention duration, deletion, legal hold, settlement calendar, surveillance scope, customer notice, and regulator export format as explicit product/jurisdiction policy inputs reviewed by counsel/compliance—not universal constants.

Time fields are not interchangeable:

Time	Meaning	Use	Unsafe substitution
Business/effective time	when the governing product policy says a fact takes effect	value date statement allocation correction and policy reporting	server receive time
Event time	when the represented domain fact occurred; FIX TransactTime is this for the business transaction	venue/matcher fact and event-time analytics	transport arrival order
Ingestion time	when this system accepted the envelope	lag and missing-feed diagnosis	execution authority
Processing time	when a consumer handled the envelope	capacity latency and retry analysis	causal order
Recorded time	when the authority durably committed the record	audit lineage and recovery checkpoint	universal business date

Inference T9STABLE01: wall-clock time alone cannot establish causality or total order. Use source sequence/version, writer epoch, stable identity, and causation edges; use clocks to measure latency and select governed windows (C110; F01,F37). A report manifest records policy timezone/calendar/cutoff version, then converts to UTC [startInclusive,endExclusive). Adjacent windows share exactly one endpoint. The manifest carries source versions/checkpoints, build ID, exact-unit control totals, code/schema/policy versions, evidence hashes, owner, and resolution state. A rerun with the same authority point and policy version must reproduce the same classified result or open a break.

Senior interview follow-ups

Model details · task9 interviews

INTERVIEW|Q01|Why can a strong portfolio read not authorize a BUY?|Strong consistency describes that projection store read; provenance remains derived. Use AP12 reservation authority and version, then show stale-asOf portfolio.|RSP03 RSP10|INV05 INV10|ARCA ARCB ARCC
INTERVIEW|Q02|What makes duplicate PlaceOrder safe?|Tenant client key plus canonical fingerprint conditionally maps to one order and durable receipt in the same authority transaction; mismatch rejects and timeout returns pending lookup.|RSP01 RSP04|INV01 INV08|ARCA ARCB ARCC
INTERVIEW|Q03|How do partial fills reconcile?|Unique execution identities sum to CumQty; active LeavesQty equals OrderQty minus CumQty; each exact fill drives linked posting and obligation evidence.|RSP04 RSP06 RSP09|INV03 INV04 INV07|ARCA ARCB ARCC
INTERVIEW|Q04|Who wins a cancel versus fill race?|The matcher or venue accepted sequence wins. Cancel can stop remaining quantity only; it cannot erase an accepted fill. Order and reservation versions record the result.|RSP04 RSP06|INV02 INV03 INV04 INV05|ARCA ARCB ARCC
INTERVIEW|Q05|How does cancel replace affect priority?|The governing venue or book policy decides and the new order version records whether priority is retained or lost. OrigClOrdID or equivalent links the prior version.|RSP04 RSP06|INV02 INV04|ARCA ARCB ARCC
INTERVIEW|Q06|How do you process a late execution report?|Compare stable identity and expected source or order version: duplicate/stale no-op, next applies, gap parks and fetches missing range. Never sort by timestamp and hope.|RSP04 RSP06|INV02 INV03 INV09|ARCA ARCB ARCC
INTERVIEW|Q07|How is a bust or correction represented?|Create a new execution correction referencing the original, then linked reversal or difference postings and corrected obligations. Preserve old history and reconcile net exact units.|RSP06 RSP07 RSP09|INV03 INV06 INV07|ARCA ARCB ARCC
INTERVIEW|Q08|What happens after reservation succeeds but routing times out?|Keep order ROUTE_PENDING and reservation HELD. Resolve routeAttemptId through destination receipt or status reconciliation before resend or release; expose pending to client.|RSP03 RSP05|INV05 INV08 INV09|ARCA ARCB ARCC
INTERVIEW|Q09|Why Kinesis for the write-heavy design but not matching?|It provides partitioned retained transport and independent consumers. It does not own book priority, exact execution identity, ledger semantics, or global order.|RSP06 RSP12|INV03 INV09 INV10|ARCB ARCC
INTERVIEW|Q10|When would you choose MSK instead?|When Kafka protocol clients connectors partition/retention controls ecosystem or team expertise are binding enough to pay its fixed operations; transactions still stop before arbitrary external stores.|RSP12 RSP13|INV08 INV09|ARCB
INTERVIEW|Q11|When does Flink earn its place?|Stateful event-time joins windows watermarks and late-data rules whose value pays checkpoint state upgrade and on-call burden; never simple routing delivery matching or ledgering.|RSP12 RSP13|INV08 INV09 INV10|ARCB
INTERVIEW|Q12|How do you split a hot symbol?|Only with an authoritative source sequence laneMapVersion subsequence deterministic merge watermark and drained cutover. Otherwise preserve one lane or change substrate/admission.|RSP06 RSP12|INV03 INV09|ARCB ARCC
INTERVIEW|Q13|Why ECS or EC2 for the mixed matcher?|Measured long-lived deterministic single-writer latency runtime and journal control justify it. Lambda stays at edges; dedicated compute adds capacity failover patching and specialist on-call burden.|RSP06|INV02 INV03 INV09|ARCC
INTERVIEW|Q14|How does match failover avoid two writers?|Monotonic writerEpoch plus lease and routing fence; passive restores snapshot and journal, acquires next epoch, stale outputs reject, then reconciliation gates traffic and failback.|RSP06|INV03 INV08 INV09|ARCC
INTERVIEW|Q15|Is an executed trade settled?|No. Execution creates a distinct clearing obligation; settlement needs governing finality evidence or classified failure from bank custodian depository or FMI policy.|RSP06 RSP07 RSP08|INV07 INV08|ARCA ARCC
INTERVIEW|Q16|What proves a projection rebuild?|Versioned isolated target, complete authority manifest, catch-up watermark, no gaps, counts and exact totals match, conditional blue-green cutover, retained rollback target.|RSP10 RSP14|INV08 INV09 INV10|ARCA ARCB ARCC
INTERVIEW|Q17|Does Object Lock make the system compliant?|No. It protects named object versions within configured mode and policy. Completeness semantics access lineage retention suitability legal duties and reconciled evidence remain owned controls.|RSP13|INV08 INV09 INV10|ARCA ARCB ARCC
INTERVIEW|Q18|What would make you migrate each design?|A loses measured read benefit or exceeds projection ownership; B exceeds hot-lane or safe-drain envelope; C hottest-book utilization or failover burden exceeds tested headroom. Use versioned fenced cutovers.|RSP05 RSP06 RSP10 RSP12 RSP14|INV08 INV09 INV10|ARCA ARCB ARCC

ID	Prompt	Strong-answer rubric	Responsibility routes	Invariant routes	Architecture routes
Q01	Why can a strong portfolio read not authorize a BUY?	Strong consistency describes that projection store read; provenance remains derived. Use AP12 reservation authority and version, then show stale-asOf portfolio.	RSP03 RSP10	INV05 INV10	ARCA ARCB ARCC
Q02	What makes duplicate PlaceOrder safe?	Tenant client key plus canonical fingerprint conditionally maps to one order and durable receipt in the same authority transaction; mismatch rejects and timeout returns pending lookup.	RSP01 RSP04	INV01 INV08	ARCA ARCB ARCC
Q03	How do partial fills reconcile?	Unique execution identities sum to CumQty; active LeavesQty equals OrderQty minus CumQty; each exact fill drives linked posting and obligation evidence.	RSP04 RSP06 RSP09	INV03 INV04 INV07	ARCA ARCB ARCC
Q04	Who wins a cancel versus fill race?	The matcher or venue accepted sequence wins. Cancel can stop remaining quantity only; it cannot erase an accepted fill. Order and reservation versions record the result.	RSP04 RSP06	INV02 INV03 INV04 INV05	ARCA ARCB ARCC
Q05	How does cancel replace affect priority?	The governing venue or book policy decides and the new order version records whether priority is retained or lost. OrigClOrdID or equivalent links the prior version.	RSP04 RSP06	INV02 INV04	ARCA ARCB ARCC
Q06	How do you process a late execution report?	Compare stable identity and expected source or order version: duplicate/stale no-op, next applies, gap parks and fetches missing range. Never sort by timestamp and hope.	RSP04 RSP06	INV02 INV03 INV09	ARCA ARCB ARCC
Q07	How is a bust or correction represented?	Create a new execution correction referencing the original, then linked reversal or difference postings and corrected obligations. Preserve old history and reconcile net exact units.	RSP06 RSP07 RSP09	INV03 INV06 INV07	ARCA ARCB ARCC
Q08	What happens after reservation succeeds but routing times out?	Keep order ROUTE_PENDING and reservation HELD. Resolve routeAttemptId through destination receipt or status reconciliation before resend or release; expose pending to client.	RSP03 RSP05	INV05 INV08 INV09	ARCA ARCB ARCC
Q09	Why Kinesis for the write-heavy design but not matching?	It provides partitioned retained transport and independent consumers. It does not own book priority, exact execution identity, ledger semantics, or global order.	RSP06 RSP12	INV03 INV09 INV10	ARCB ARCC
Q10	When would you choose MSK instead?	When Kafka protocol clients connectors partition/retention controls ecosystem or team expertise are binding enough to pay its fixed operations; transactions still stop before arbitrary external stores.	RSP12 RSP13	INV08 INV09	ARCB
Q11	When does Flink earn its place?	Stateful event-time joins windows watermarks and late-data rules whose value pays checkpoint state upgrade and on-call burden; never simple routing delivery matching or ledgering.	RSP12 RSP13	INV08 INV09 INV10	ARCB
Q12	How do you split a hot symbol?	Only with an authoritative source sequence laneMapVersion subsequence deterministic merge watermark and drained cutover. Otherwise preserve one lane or change substrate/admission.	RSP06 RSP12	INV03 INV09	ARCB ARCC
Q13	Why ECS or EC2 for the mixed matcher?	Measured long-lived deterministic single-writer latency runtime and journal control justify it. Lambda stays at edges; dedicated compute adds capacity failover patching and specialist on-call burden.	RSP06	INV02 INV03 INV09	ARCC
Q14	How does match failover avoid two writers?	Monotonic writerEpoch plus lease and routing fence; passive restores snapshot and journal, acquires next epoch, stale outputs reject, then reconciliation gates traffic and failback.	RSP06	INV03 INV08 INV09	ARCC
Q15	Is an executed trade settled?	No. Execution creates a distinct clearing obligation; settlement needs governing finality evidence or classified failure from bank custodian depository or FMI policy.	RSP06 RSP07 RSP08	INV07 INV08	ARCA ARCC
Q16	What proves a projection rebuild?	Versioned isolated target, complete authority manifest, catch-up watermark, no gaps, counts and exact totals match, conditional blue-green cutover, retained rollback target.	RSP10 RSP14	INV08 INV09 INV10	ARCA ARCB ARCC
Q17	Does Object Lock make the system compliant?	No. It protects named object versions within configured mode and policy. Completeness semantics access lineage retention suitability legal duties and reconciled evidence remain owned controls.	RSP13	INV08 INV09 INV10	ARCA ARCB ARCC
Q18	What would make you migrate each design?	A loses measured read benefit or exceeds projection ownership; B exceeds hot-lane or safe-drain envelope; C hottest-book utilization or failover burden exceeds tested headroom. Use versioned fenced cutovers.	RSP05 RSP06 RSP10 RSP12 RSP14	INV08 INV09 INV10	ARCA ARCB ARCC

Sources used in this chapter

Domain, standards, and conceptual anchors:

• Larry Harris, Trading and Exchanges, for market roles and trading-domain framing (F17).
• FIX Trading Community, FIXimate FIX.Latest top-level specification (F18, retrieved 2026-08-24) and direct FIX Latest locators for CumQty, ClOrdID, ExecID, ExecRefID, OrderQty, OrdStatus, ExecType, LeavesQty, and TransactTime (F37).
• Martin Fowler, Patterns for Accounting (F08) and The LMAX Architecture (F09).
• CPMI-IOSCO, Principles for Financial Market Infrastructures and the official inspectable Principle 8 locator, for settlement-finality scope (F38).
• Kleppmann and Riccomini, Designing Data-Intensive Applications, second edition (F01); FinOps Foundation Unit Economics (F19); Werner Vogels, The Frugal Architect (F20).

Current AWS routes rechecked 2026-08-22:

• DynamoDB transactions, Streams, and export (A101,A102,A106).
• Kinesis sizing, producer semantics, and KCL/resharding (A95-A97).
• Managed Flink checkpoint scope, MSK consumer lag, and Firehose buffering (A88-A90).
• ECS concepts, EC2 concepts, WebSocket APIs, and AppSync real-time (A54,A55,A58,A60).
• IAM best practices, KMS best practices, CloudTrail integrity validation, and S3 Object Lock (A38,A39,A41,A122).
• AWS disaster-recovery objectives, Route 53 DNS failover, and ARC regional routing controls (A119-A121).

Takeaway and next step

A trading architecture is defensible when every accepted obligation has a named authority, identity, state transition, and eventual proof or owned discrepancy. Explain the cancel/fill and reservation/routing-timeout cases without erasing a committed fact. Next, test these ideas against real code in the Repository case study, where the earlier CS references are examined in full.