# Fintech and trading reference architectures: authority before AWS 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). ```text 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 ```text 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 ```text 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 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. ```text 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. ```text 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 ```mermaid 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 ```mermaid 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 ```mermaid 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 ```text 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 These inputs are assumptions, not AWS promises or measured production facts. The [shared cost model](../research/cost-model.md#trading-architecture-selection-envelopes) 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. ```text 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 ```text 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*](https://global.oup.com/academic/product/trading-and-exchanges-9780195144703), for market roles and trading-domain framing (F17). - FIX Trading Community, [FIXimate FIX.Latest top-level specification](https://fiximate.fixtrading.org/en/FIX.Latest/fix.html) (F18, retrieved 2026-08-24) and direct FIX Latest locators for [`CumQty`](https://fiximate.fixtrading.org/en/FIX.Latest/tag14.html), [`ClOrdID`](https://fiximate.fixtrading.org/en/FIX.Latest/tag11.html), [`ExecID`](https://fiximate.fixtrading.org/en/FIX.Latest/tag17.html), [`ExecRefID`](https://fiximate.fixtrading.org/en/FIX.Latest/tag19.html), [`OrderQty`](https://fiximate.fixtrading.org/en/FIX.Latest/tag38.html), [`OrdStatus`](https://fiximate.fixtrading.org/en/FIX.Latest/tag39.html), [`ExecType`](https://fiximate.fixtrading.org/en/FIX.Latest/tag150.html), [`LeavesQty`](https://fiximate.fixtrading.org/en/FIX.Latest/tag151.html), and [`TransactTime`](https://fiximate.fixtrading.org/en/FIX.Latest/tag60.html) (F37). - Martin Fowler, [Patterns for Accounting](https://martinfowler.com/eaaDev/AccountingNarrative.html) (F08) and [The LMAX Architecture](https://martinfowler.com/articles/lmax.html) (F09). - CPMI-IOSCO, [*Principles for Financial Market Infrastructures*](https://www.bis.org/cpmi/publ/d101a.pdf) and the [official inspectable Principle 8 locator](https://www.bis.org/pfmi/help/principleid.htm), for settlement-finality scope (F38). - Kleppmann and Riccomini, [*Designing Data-Intensive Applications*, second edition](https://www.oreilly.com/library/view/designing-data-intensive-applications/9781098119058/) (F01); FinOps Foundation [Unit Economics](https://www.finops.org/framework/capabilities/unit-economics/) (F19); Werner Vogels, [The Frugal Architect](https://thefrugalarchitect.com/) (F20). Current AWS routes rechecked 2026-08-22: - [DynamoDB transactions](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transaction-apis.html), [Streams](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html), and [export](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/S3DataExport.HowItWorks.html) (A101,A102,A106). - [Kinesis sizing](https://docs.aws.amazon.com/streams/latest/dev/how-do-i-size-a-stream.html), [producer semantics](https://docs.aws.amazon.com/streams/latest/dev/developing-producers-with-sdk.html), and [KCL/resharding](https://docs.aws.amazon.com/streams/latest/dev/kcl.html) (A95-A97). - [Managed Flink checkpoint scope](https://docs.aws.amazon.com/managed-flink/latest/java/how-fault.html), [MSK consumer lag](https://docs.aws.amazon.com/msk/latest/developerguide/consumer-lag.html), and [Firehose buffering](https://docs.aws.amazon.com/firehose/latest/dev/create-configure-backup.html) (A88-A90). - [ECS concepts](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html), [EC2 concepts](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html), [WebSocket APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-overview.html), and [AppSync real-time](https://docs.aws.amazon.com/appsync/latest/devguide/aws-appsync-real-time-data.html) (A54,A55,A58,A60). - [IAM best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html), [KMS best practices](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-kms-best-practices/introduction.html), [CloudTrail integrity validation](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-validation-intro.html), and [S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html) (A38,A39,A41,A122). - [AWS disaster-recovery objectives](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html), [Route 53 DNS failover](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html), and [ARC regional routing controls](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.regional.html) (A119-A121).