Quick reference: decide from boundaries

Reading notesDownload original Markdown ↗

Use this page beside the complete guide when you need to recall a distinction or check a formula. SVC labels service cards, PAT pattern cards, CQR CQRS comparisons, BND guarantee boundaries, AUTH financial authorities, and FML formulas. Follow a card's chapter link whenever its shorthand hides a premise you cannot explain.

Use this for recall after studying the detailed chapters. Every card keeps the deciding ratio or scope, correctness boundary, recovery duty, and material cost/operations caveat. Mutable AWS facts route to reviewed dated claims; recheck them before publication or a real design.

Ask before naming a service

1. What business outcome and deadline matter, and which component is authority?
2. Is this one owned work item, push fan-out, fact routing, a retained log, or a multi-step workflow? How many consumers and destinations?
3. What is the delivery identity, ordering scope, duplicate window, stale/gap rule, and externally visible protected effect?
4. What are average/peak records and bytes, key skew, batch size, fan-out, retries, replay, retention, and downstream capacity?
5. What freshness/read-your-writes contract, RTO/RPO, reconciliation deadline, tenant boundary, evidence retention, and team operating burden apply?
6. What falsifier would make the preferred option unsafe or uneconomic?

Service selection cards

SVC01 — EventBridge

• Use when: route domain facts across bounded contexts using content rules and loose producer/consumer coupling.
• Deciding ratio: rule/destination fan-out and event age versus the obligation deadline; use a queue when one owner must absorb work.
• Boundary: producer API acknowledgement, bus/rule matching, target delivery, target invocation, and business effect are separate; no ordering claim is made.
• Recovery: inspect per-entry PutEvents results, validate bus/rules, provision DLQ permission, retain durable replay identity, and reconcile effects.
• Cost and operations: price published events, archive/replay, targets, retries, logs, and downstream work; monitor failed delivery and DLQ-write failure.
• Routes: service guide; C05, C06, C08, C09, C57, C60, C62; A01, A04–A07, A81, A82, A84; F01; retrieved 2026-08-22.

SVC02 — SQS Standard

• Use when: one logical worker pool owns buffered work and duplicates/out-of-order delivery are acceptable to an idempotent consumer.
• Deciding ratio: arrival versus protected drain capacity, in-flight work, batch size, visibility deadline, and age-to-SLO.
• Boundary: at-least-once delivery and best-effort order; a delete/acknowledgement does not prove the business effect.
• Recovery: durable command/effect receipt, partial-batch handling, bounded retries, DLQ/quarantine, redrive guard, and source reconciliation.
• Cost and operations: requests, payload chunks, polling, Lambda work, retry amplification, DLQ storage/redrive, and age/backlog alarms.
• Routes: service guide, reliability; C02, C40, C43, C44, C63, C103; A02, A09, A85, A118; F02–F04, F11, F13, F14; retrieved 2026-08-22.

SVC03 — SQS FIFO

• Use when: owned work needs strict order within a declared MessageGroupId and bounded producer deduplication helps.
• Deciding ratio: active message groups and batchable throughput versus one-group serialization and deadline.
• Boundary: order is per group; the documented send-deduplication interval does not deduplicate database/API/business effects.
• Recovery: keep a durable effect identity, make the consumer idempotent, stop unsafe redrive, and reconcile group gaps.
• Cost and operations: model current Region/mode/group throughput, batching, hot groups, request work, age, and blocked-group blast radius.
• Routes: service guide; C03, C04, C19, C40, C41, C63, C103; A02, A10, A11, A85, A118; F01, F11; retrieved 2026-08-22.

SVC04 — SNS Standard

• Use when: push fan-out to heterogeneous subscriptions matters and each subscriber owns its delivery/recovery boundary.
• Deciding ratio: publishers × destinations × retry work and subscriber availability; use EventBridge when content routing/governance dominates.
• Boundary: no package-wide ordering or consumer-effect guarantee; publisher-to-topic and topic-to-subscription are separate.
• Recovery: subscription DLQs where supported, idempotent subscribers, durable source/replay plan, and outcome reconciliation.
• Cost and operations: publications, deliveries by protocol, filters, retries, egress, subscriber work, and per-subscription failure signals.
• Routes: service guide; C43, C60, C64, C68; A13, A36, A83, A86, A91; F02, F03, F13; retrieved 2026-08-22.

SVC05 — SNS FIFO

• Use when: ordered/deduplicated topic fan-out to compatible SQS subscribers is required within a message group.
• Deciding ratio: message groups and FIFO subscriber topology versus serialized hot groups; filtering changes deduplication scope.
• Boundary: FIFO topic behavior does not make subscriber effects unique and delivery to Standard versus FIFO queues differs.
• Recovery: preserve publisher identity, archive/replay only within documented scope, idempotently consume, and reconcile each subscriber.
• Cost and operations: publications, subscriber delivery, archive/replay, filters, queue work, hot groups, and group age.
• Routes: service guide; C20, C64, C69; A12, A13, A83, A86, A91–A94; F11; retrieved 2026-08-22.

SVC06 — Kinesis Data Streams

• Use when: several consumers need a retained, replayable, partitioned log with per-key/shard order and independent progress.
• Deciding ratio: max(bytes-shards, record-shards) × skew/utilization, then hottest-key rate, fan-out, retention, and drain headroom.
• Boundary: order/checkpoint is shard-scoped; acknowledgement, checkpoint, sink effect, business version, and reconciliation remain distinct.
• Recovery: preserve source identity/version, quarantine poison data, archive before retention loss, rebuild consumers, and protect live capacity while draining.
• Cost and operations: capacity mode/shards, PUT units, enhanced fan-out, retention, archive, consumers, sink work, iterator age, skew, and throttles.
• Routes: Kinesis deep dive; C10–C17, C42, C70–C80, C114; A03, A14–A18, A95–A99; F01, F02; retrieved 2026-08-22.

SVC07 — DynamoDB Streams

• Use when: consumers need a table-change feed tied to item mutations, especially projection or repair triggers inside retention.
• Deciding ratio: source table write rate × consumers × retry/replay work versus short retention and semantic-event needs.
• Boundary: records describe table changes; transaction grouping, consumer effects, semantic intent, and durable long replay are not supplied automatically.
• Recovery: idempotent projector inbox/effect, source versions/gaps, archive or independent outbox for long replay, rebuild, and reconciliation.
• Cost and operations: source writes/index amplification, Lambda polling/work, poison/gap age, retention margin, archive, and projection rebuild.
• Routes: DynamoDB deep dive; C23, C84, C96, C99, C100; A01, A21, A102, A106, A111; F01, F11; retrieved 2026-08-22.

SVC08 — Step Functions Standard

• Use when: a durable, inspectable, long-running orchestration owns explicit steps, waits, callbacks, retries, and compensation decisions.
• Deciding ratio: transitions per workflow × workflow rate, duration, callback/deadline needs, and audit/operator value.
• Boundary: workflow history and step transitions do not make downstream business effects idempotent or compensations reversible.
• Recovery: stable execution/business identity, bounded step retry, ambiguity lookup, compensation policy, human stop, and obligation reconciliation.
• Cost and operations: transitions, execution history/retention, Lambda/API work, retries, payload handoff, failed/timed-out executions, and redrive policy.
• Routes: service guide; C25, C65, C101; A25, A26, A87, A116; F05, F10; retrieved 2026-08-22.

SVC09 — Step Functions Express

• Use when: high-rate, short-duration orchestration fits its documented execution/history semantics and external effects remain protected.
• Deciding ratio: executions × duration/log work versus Standard transition cost and durability/audit requirements.
• Boundary: execution mode is not a shortcut for unique financial effects, durable business history, or unlimited duration.
• Recovery: application-owned receipts/idempotency, bounded retry, external durable evidence, ambiguity lookup, and reconciliation.
• Cost and operations: executions, duration/memory, logs, downstream calls/retries, throttles, failures, and evidence-retention burden.
• Routes: service guide; C25, C65; A25, A26; retrieved 2026-08-22.

SVC10 — Amazon Data Firehose

• Use when: managed buffered delivery to supported analytics/storage destinations is the goal, not general application streaming.
• Deciding ratio: ingest bytes, buffer size/interval, transformation work, destination throughput, backup, and acceptable delivery freshness.
• Boundary: delivered objects/records do not prove financial completeness, low-latency action, order, or consumer checkpoint semantics.
• Recovery: source backup, destination error prefix, manifest/count checks, transform quarantine, replay route, and reconciliation.
• Cost and operations: ingested bytes, conversion/format, transformation, destination/storage/egress, backup, freshness, and delivery-error metrics.
• Routes: service guide; C28, C30, C31, C49, C66; A29, A76, A88; F19, F20; retrieved 2026-08-22. Operations; C119, A131; retrieved 2026-08-23.

SVC11 — Amazon MSK / Kafka

• Use when: Kafka protocol/ecosystem, partitioned consumer groups, retention, transactions within documented Kafka scope, or portability justify operating it.
• Deciding ratio: partition/key demand, consumer groups, retention/storage/replication, broker/network headroom, and team operating capability.
• Boundary: Kafka transaction/read-process-write semantics are boundary-limited; external databases, APIs, and financial effects need their own protection.
• Recovery: durable event/business identity, checkpoint/transaction discipline, poison isolation, archive, partition-aware replay, rebuild, and reconciliation.
• Cost and operations: brokers/serverless units, storage, replication/transfer, connectors, monitoring, upgrades, lag by group/partition, and on-call load.
• Routes: service guide; C29, C49, C68; A30, A77, A90; F19, F20, F28; retrieved 2026-08-22.

SVC12 — Managed Service for Apache Flink

• Use when: stateful event-time computation, windows, watermarks, joins, and checkpointed application state are real requirements.
• Deciding ratio: keyed state and event-time work per compute unit, source partitions, checkpoint duration, backpressure, and sink capacity.
• Boundary: checkpoint consistency covers the configured Flink state/source/sink contract, not arbitrary external effects or financial authority.
• Recovery: tested checkpoints/savepoints, compatible deploy/restore, late-data policy, idempotent or transactional sink boundary, and result reconciliation.
• Cost and operations: compute units, autoscaling, checkpoint storage, source/sink/transfer, state growth, backpressure, checkpoint age/failure, and upgrades.
• Routes: service guide; C30, C49, C67, C68; A31, A80, A89; F19, F20, F31; retrieved 2026-08-22.

SVC13 — API Gateway

• Use when: managed HTTP/WebSocket ingress, authentication integration, throttling, and API lifecycle fit the request boundary.
• Deciding ratio: requests/connections/messages × payload/duration versus latency, quota, downstream concurrency, and abuse envelope.
• Boundary: a successful API response proves only the defined API contract; it does not prove downstream routing, settlement, or projection freshness.
• Recovery: durable command receipt/status lookup, stable idempotency identity, downstream backpressure, timeout ambiguity handling, and outcome reconciliation.
• Cost and operations: request/message/connection units, transfer, authorizer/Lambda work, logs, WAF, latency/errors/throttles, and tenant cardinality.
• Routes: service guide; C51, A52, A53; retrieved 2026-08-22. Operations; C119, C122, A128, A144; retrieved 2026-08-23.

SVC14 — WebSocket / AppSync delivery

• Use when: clients need pushed status or subscription updates and disconnect/reconnect semantics are explicitly designed.
• Deciding ratio: concurrent connections × messages × payload and reconnect rate versus freshness, fan-out, and client catch-up needs.
• Boundary: delivery to a live connection/subscription does not prove client receipt, durable history, order authority, or financial completion.
• Recovery: durable source/status query, sequence/version and gap detection, reconnect catch-up, stale-connection cleanup, and client-visible freshness.
• Cost and operations: connection minutes, messages, resolver/Lambda work, transfer, fan-out, disconnects, delivery failures, and stale-client support.
• Routes: service guide; C54; A54, A55; retrieved 2026-08-22.

SVC15 — Aurora PostgreSQL

• Use when: relational constraints, evolving joins, SQL reporting, or a ledger/accounting model fits an explicitly selected transaction/isolation contract.
• Deciding ratio: transactional/write/read I/O, working set, connections, replica/failover needs, and relation complexity versus keyed access patterns.
• Boundary: ACID is database-transaction scoped; publication, replicas, caches/search, cross-service effects, and accounting meaning remain separate.
• Recovery: transaction/outbox, immutable posting evidence, backups/PITR, tested failover/restore, connection fencing, projection rebuild, and reconciliation.
• Cost and operations: instances/serverless capacity, storage/I/O, replicas, backup, transfer, connections, maintenance, failover, locks, and query plans.
• Routes: DynamoDB deep dive; C92, C99; A20, A35, A112, A115; F04, F11; retrieved 2026-08-22.

SVC16 — Lambda

• Use when: bounded stateless event/request work benefits from managed scaling and its latency, duration, concurrency, payload, and integration semantics fit.
• Deciding ratio: arrival/batch × duration × headroom, request/GB-s work, downstream concurrency, and idle-to-active duty cycle.
• Boundary: invocation success, event-source checkpoint, and business effect differ; retry paths and duplicate exposure depend on invocation source.
• Recovery: reserved/mapping concurrency, idempotent receipt/effect, partial batches, poison handling, durable replay, downstream protection, and reconciliation.
• Cost and operations: requests, GB-s, provisioned concurrency if used, logs/traces, transfer, retries, event-source work, throttles, age, errors, and cold paths.
• Routes: service guide, cost; C06, C07, C53, C63, C104, C115; A01–A05, A51, A58–A60, A85, A117, A123, A124; F03, F13; retrieved 2026-08-22.

SVC17 — ECS / Fargate

• Use when: sustained or long-running workers need process/runtime control, stable connections, custom batching, or predictable task capacity without managing hosts.
• Deciding ratio: capacity per task and HA floor versus peak × headroom, active duty, task start/scale time, and Lambda capacity-feasible cost.
• Boundary: task health and queue checkpoint do not prove unique effects, order correctness, or financial completion.
• Recovery: multiple fenced workers, graceful drain/checkpoint, autoscaling with protected replay, immutable deploy/rollback, poison quarantine, and reconciliation.
• Cost and operations: provisioned vCPU/memory/ephemeral storage for running tasks, load balancing/network/logs, idle HA floor, scaling, deployment, and image security.
• Routes: cost; C53, C115; A51, A58, A59, A123, A124; retrieved 2026-08-22.

SVC18 — EC2

• Use when: host-level control, specialized hardware/networking, licensed/runtime constraints, or stable high utilization justify fleet ownership.
• Deciding ratio: required capacity/HA × utilization and commitment horizon versus managed compute total burden and operator capability.
• Boundary: host/process availability does not provide application ordering, idempotency, checkpoint correctness, or financial authority.
• Recovery: multi-AZ fleet, fencing, immutable images, capacity replacement, checkpoint/state strategy, tested restore, and reconciliation.
• Cost and operations: instances/commitments, storage, network, load balancing, patching, scaling, AMIs, host failure, capacity reservations, and on-call work.
• Routes: service guide, cost; C49, C53; A60, A68; F19, F20; retrieved 2026-08-22.

Pattern selection cards

PAT01 — Transactional outbox

• Use when: authoritative state and publication intent must commit together in one compatible store transaction.
• Deciding ratio: source writes × outbox amplification and relay/retry/reconciliation work versus tolerated missing-publication risk.
• Boundary: closes state-versus-intent atomicity, not transport duplicates, consumer effects, ordering across aggregates, or downstream completion.
• Recovery: lease/claim relay, stable event ID, retryable states, poison quarantine, lag/gap alarms, repair scan, and reconciliation.
• Cost and operations: base/index writes, relay reads/writes, stream/transport, retries, archive, cleanup, outbox age, and stuck-state ownership.
• Routes: CQRS chapter; C38, C40, C99; F04, F11, A115.

PAT02 — Atomic inbox/effect receipt

• Use when: a retried delivery must mutate a protected database effect at most once under a stable event identity.
• Deciding ratio: duplicate/replay rate × effect cost and receipt retention versus transactional write/read amplification.
• Boundary: proves one protected store effect per identity only inside the chosen transaction; not external API uniqueness or global delivery.
• Recovery: atomically inspect/insert receipt with effect, reject fingerprint conflict, retain through retry horizon, and reconcile ambiguous external effects.
• Cost and operations: receipt storage/indexes, transactional multiplier, hot identity lanes, expiry/repair, conflict alarms, and audit evidence.
• Routes: reliability; C40, C90; F02, F04, F11; A20, A101; retrieved 2026-08-22.

PAT03 — Idempotent command receipt

• Use when: clients may repeat an accepted command and need the same durable status/result rather than a second obligation.
• Deciding ratio: retry window/volume and result retention versus command transaction work and stale-key risk.
• Boundary: protects command acceptance for matching identity/fingerprint; it does not prove routing or downstream completion.
• Recovery: PENDING/COMPLETED state machine, fingerprint conflict, bounded takeover, durable status lookup, outbox linkage, and reconciliation.
• Cost and operations: transactional writes/reads, retention, hot customer keys, abandoned PENDING repair, conflict/security evidence, and result payload storage.
• Routes: DynamoDB deep dive; AP08, C08, C40, C90, C93, C99; F11, A101, A110.

PAT04 — Saga

• Use when: one business obligation spans authorities that cannot share a transaction and each step has explicit compensation or forward-recovery policy.
• Deciding ratio: steps × retries/compensations and deadline versus coordination/audit value and irreversibility risk.
• Boundary: coordinates local transactions; compensation is a new business action, not rollback, and some financial effects are irreversible.
• Recovery: stable saga/step identity, owned timeouts, ambiguity lookup, safe compensation/forward recovery, human escalation, and obligation reconciliation.
• Cost and operations: transitions/messages, histories, timers, retries, compensations, operator cases, stuck obligations, deadline age, and evidence.
• Routes: CQRS chapter; C39, C101; F05, F10; A116; retrieved 2026-08-22.

PAT05 — Orchestration or choreography

• Use when: choose explicit central step ownership for complex/deadline flows, or distributed fact reaction for genuinely autonomous bounded contexts.
• Deciding ratio: participants/dependencies and visibility/deadline needs versus coordinator coupling or emergent event-chain complexity.
• Boundary: neither style supplies cross-service atomicity, unique effects, reversible compensation, or business completion by itself.
• Recovery: one retry owner per boundary, durable identities, timeouts, terminal states, compensation/repair, dependency observability, and reconciliation.
• Cost and operations: transition/event fan-out, histories/logs, duplicated retry, operator cognitive load, stuck-flow age, and change coordination.
• Routes: CQRS chapter; C39, C58, C101; F05, F07, F10, F29, F30; A116; retrieved 2026-08-22.

PAT06 — DLQ or quarantine

• Use when: a bounded delivery/processing boundary must stop poison or exhausted work without silently discarding identity and evidence.
• Deciding ratio: failure rate × retry attempts × poison coupling versus retention, investigation, redrive capacity, and deadline.
• Boundary: stores a failed representation at one boundary; it does not guarantee writable permission, source completeness, safe redrive, or effect rollback.
• Recovery: capture raw bytes/identity/error/attempt/source position, alarm, classify, patch, replay under headroom, and reconcile outcome.
• Cost and operations: retry work, storage, alarms, operator cases, redrive, replay capacity, oldest age, repeat poison ID, and retention margin.
• Routes: reliability; C43, C44, C57, C103; F02, F03, F13, F14; A81, A118; retrieved 2026-08-22.

PAT07 — Reconciliation

• Use when: authorities/providers/projections can diverge or an external effect can be ambiguous and correctness needs an independent backstop.
• Deciding ratio: obligations/control totals and break arrival versus reconciliation capacity, safety reservation, and resolution deadline.
• Boundary: detects/owns discrepancies from independent evidence; it does not erase the original failure or make a projection authoritative.
• Recovery: compare authoritative sets/totals, classify missing/duplicate/mismatch, lease repair, preserve audit trail, escalate aging breaks, and close explicitly.
• Cost and operations: scans/exports/queries, provider calls, repair work, evidence retention, break count/age/value, capacity, and human burden.
• Routes: fintech architecture, reliability; RSP10, INV06, INV08, INV10, C46, C47, C48, C108.

PAT08 — Blue-green projection rebuild

• Use when: a derived view must be rebuilt without letting partial, stale, or incompatible state replace the serving version.
• Deciding ratio: source history/backlog ÷ protected replay rate versus retention, RTO, live SLO, storage, and validation time.
• Boundary: validates a derived view against an authority/source watermark; it does not repair corrupt authority or authorize financial action.
• Recovery: build vNext from bounded source, track versions/gaps/watermark, compare counts/totals, catch up, atomic cutover, retain rollback, then retire.
• Cost and operations: duplicate storage/write/compute, archive reads, validation queries, replay headroom, freshness/gap age, cutover epoch, and rollback window.
• Routes: CQRS chapter; C35, C59, C96, C98, C100, C104; F01, F02, F06, F07, F11, F13; A102, A106, A111, A114; retrieved 2026-08-22.

PAT09 — Single writer and fencing

• Use when: one ordering/invariant scope cannot tolerate concurrent stale leaders or split-brain writes.
• Deciding ratio: hottest scope rate/latency versus one writer capacity and failover/recovery deadline.
• Boundary: fences writers for the named scope/epoch; it does not create cross-scope global order or make downstream consumers unique.
• Recovery: durable epoch/lease, conditional writes, stale-client rejection, one-writer proof, state/checkpoint restore, ordered catch-up, and reconciliation.
• Cost and operations: reserved capacity, standby/HA floor, coordination store, tail latency, epoch/lease alarms, failover drills, backlog, and operator control.
• Routes: fintech architecture; INV09, C34, C46, C111; F09, F17.

CQRS spectrum

CQR01 — CQRS-lite

• Command authority: one transactional model owns legal transitions, reservations, exact money, and outbox intent.
• Read model: same store/table or a few secondary access paths; avoid a separate pipeline unless an AP requires it.
• Consistency/freshness: authority read for decisions; dated/explicit bounded freshness only for derived paths.
• Ordering scope: authoritative aggregate version; transport order never substitutes for it.
• Rebuild: indexes or small projections have a named source, version, validation, and rollback.
• Duplicate handling: command receipt plus atomic inbox/effect where deliveries can repeat.
• Failure recovery: repair outbox/receipts first, then rebuild derived paths and reconcile totals.
• Cost/operations: minimum moving parts; still count index amplification, receipts, backup, and on-call work.
• When it does not pay: relational/AP needs conflict, source cannot meet read SLO, or physical lanes fail.
• Routes: CQRS chapter; CQR01, C35, C40, C97, C99; F06, A113.

CQR02 — Read-heavy brokerage

• Command authority: order/risk/reservation/ledger stores own acceptance and financial decisions.
• Read model: portfolio, order history, search/cache, and customer-status projections optimized per AP.
• Consistency/freshness: explicit source version/watermark, customer receipt overlay, and authority fallback for decisions.
• Ordering scope: per account/order/source aggregate; reject stale, deduplicate, detect gaps.
• Rebuild: blue-green vNext from retained/archive authority facts, validate exact totals, then cut over.
• Duplicate handling: durable event identity plus atomic projector inbox/effect.
• Failure recovery: keep commands safe while projections lag; quarantine poison, catch up under headroom, reconcile.
• Cost/operations: price transport, every projection write/store/query, rebuild, duplicate, reconciliation, observability, and team.
• When it does not pay: read benefit is below complete-cost break-even or freshness/rebuild/authority constraints fail.
• Routes: CQRS chapter; CQR02, AP07, AP12, REL05, C35, C49, C100, C102.

CQR03 — Write-heavy execution stream

• Command authority: fenced sequencer/matcher and durable order/execution authorities own state transitions and fills.
• Read model: independent market, surveillance, risk, reporting, and archive consumers.
• Consistency/freshness: source sequence/event time and consumer watermarks; no derived view authorizes matching or settlement.
• Ordering scope: explicitly partition by invariant; a hot symbol may require a single writer outside transport sharding.
• Rebuild: raw/archive source plus checkpoints, compatible code/schema, validation, and protected catch-up capacity.
• Duplicate handling: unique execution/fill identity and consumer inbox/effect; stale/gap rejection.
• Failure recovery: fence old writer, restore authority/checkpoint, preserve source, replay consumers, reconcile fills/ledger.
• Cost/operations: provision for hottest lane, fan-out, retention/archive, stateful compute, standby, replay, and on-call.
• When it does not pay: one authority store meets workload, team cannot operate ordering/recovery, or hot key exceeds the proposed sequencer.
• Routes: fintech architecture; CQR03, RSP04, RSP06, INV03, INV09, C34, C46, C100, C111.

CQR04 — Mixed exchange platform

• Command authority: separate bounded order/risk, execution, clearing, settlement, and ledger authorities with explicit handoffs.
• Read model: AP-specific portfolio, status, surveillance, reporting, and operations views.
• Consistency/freshness: per-view SLO/watermark and receipt overlay; cross-authority obligations resolve through state and reconciliation.
• Ordering scope: version/epoch per authority scope; no global broker order is invented.
• Rebuild: each projection has independent source, compatibility, blue-green validation, catch-up, and rollback.
• Duplicate handling: command, event, execution, provider, and posting identities are distinct and durably protected.
• Failure recovery: stop unsafe action, preserve obligations, look up ambiguity, forward-recover/compensate where valid, and reconcile.
• Cost/operations: allocate shared platform and team burden plus every flow's transport, workflow, store, rebuild, evidence, and DR.
• When it does not pay: boundaries lack ownership, complete cost exceeds benefit, or operational/recovery maturity cannot support them.
• Routes: fintech architecture; CQR04, RSP01–RSP10, INV01–INV10, C39, C46, C47, C100, C108.

Guarantee boundaries

BND01 — Producer acknowledgement

• Proves: the named producer API returned its documented per-request/per-entry result.
• Does not prove: valid configuration, routing, target delivery, durable consumer state, business effect, or settlement.
• Design response: inspect partial results, preserve request/event identity and intent, validate configuration independently, and reconcile outcome.
• Routes: foundations; C08, A06, A82.

BND02 — Transport delivery

• Proves: only the documented handoff/delivery condition for the named transport and destination.
• Does not prove: one delivery, one consumer effect, external API success, ordering outside scope, or business completion.
• Design response: stable identity, idempotent effect, explicit order/version, terminal failure destination, replay source, and reconciliation.
• Routes: foundations; C01–C07, C41, F01, F11.

BND03 — Consumer commit/checkpoint

• Proves: consumer progress advanced at the source/library boundary under its contract.
• Does not prove: an unrelated database/API effect committed atomically or cannot repeat after a crash.
• Design response: checkpoint after protected effect where possible, atomically store inbox/effect, and design replay/gap reconciliation.
• Routes: Kinesis deep dive; C41, C74; A97; F01; retrieved 2026-08-22.

BND04 — Business effect

• Proves: only the protected store/provider operation under a stable identity and explicit transaction/idempotency contract.
• Does not prove: upstream unique delivery, downstream publication, reversible external effects, or whole-flow completion.
• Design response: receipt plus effect transaction, outbox, provider lookup after ambiguity, durable obligation state, and reconciliation.
• Routes: reliability; C01, C38, C40, C41, C90, C99; A20, A101, A115; F01, F04, F11; retrieved 2026-08-22.

BND05 — Ordering

• Proves: order only within the declared shard, partition, group, writer, or aggregate-version scope.
• Does not prove: global time/order, novelty, no gaps, one effect, or valid financial transition.
• Design response: name scope and source version/epoch; reject stale/duplicate, detect gaps, fence writers, and reconcile.
• Routes: Kinesis deep dive; C03, C09, C10, C34, C41, C46.

BND06 — Store consistency/transactions

• Proves: only documented reads/writes/conditions/transaction items inside the selected store and Region topology.
• Does not prove: cross-service publication, semantic accounting, cache/index freshness, or external provider uniqueness.
• Design response: transact compatible authority+receipt+outbox, use exact values, expose versions/freshness, and reconcile external sets.
• Routes: DynamoDB deep dive; C82, C83, C89, C90, C92, C93, C95, C99; A100, A101.

BND07 — Workflow

• Proves: the workflow engine's named execution/transition/history state.
• Does not prove: downstream effect idempotency, reversible compensation, or final business obligation resolution.
• Design response: stable saga/step identity, one retry owner, deadlines, ambiguity lookup, compensation/forward recovery, and reconciliation.
• Routes: CQRS chapter; C25, C39, C65, C101; A25, A26, A87, A116; F05, F10; retrieved 2026-08-22.

BND08 — Replay and reconciliation

• Proves: replay re-presents preserved inputs; reconciliation independently compares named evidence and owns discrepancies.
• Does not prove: replay is safe, source history complete, authority uncorrupted, or every discrepancy automatically repairable.
• Design response: capacity/deadline gate, immutable identity/schema, sandbox/blue-green target, validation totals, human escalation, and audit closure.
• Routes: reliability; C43, C44, C48, C59, C100, C104, C105; F13–F15.

Retry and idempotency flow

1. Classify: validation/permanent → reject/quarantine; transient/throttle → bounded retry; ambiguous timeout → lookup before retry.
2. Deadline: compute remaining business/SLO/provider deadline. If expired, STOP → quarantine and reconcile.
3. Owner: choose one retry layer for this boundary; remove multiplicative nested retry.
4. Identity: carry stable command, event, execution/provider, and posting identities plus fingerprint/version.
5. Protected effect: atomically store the receipt/inbox with the state mutation when they share a transaction; otherwise use explicit provider idempotency/lookup and obligation state.
6. Ambiguity: query authority/provider by identity; never infer failure merely from a timeout.
7. Stop: cap attempts/age/concurrency, preserve raw evidence, isolate poison, protect live headroom, and reconcile to closure.

Routes: reliability, C04, C40, C43–C45, C90, C99, C100, C104; F03, F11–F13.

Fintech authority and invariants

AUTH01 — Command acceptance and order lifecycle

Authority owns durable request identity, validation, legal transition, version, and status receipt. One logical command cannot create two obligations. Routes: fintech architecture, RSP01, RSP04, INV01, INV04.

AUTH02 — Risk and reservations

Authority atomically reserves or releases exact assets or limits; no projection or cache can approve a spend. Routes: fintech architecture, RSP03, INV05.

AUTH03 — Matching and execution

A fenced sequencer/matcher owns the declared book scope; every fill/execution has a unique durable identity and valid quantity transition. Routes: fintech architecture, RSP06, INV03, INV09.

AUTH04 — Clearing

Clearing derives and agrees obligations from authoritative executions; it is distinct from trade capture and settlement completion. Routes: fintech architecture, RSP07, INV07.

AUTH05 — Settlement

Settlement authority tracks provider/custodian instructions, receipts, ambiguity, finality policy, and unresolved obligations. Routes: fintech architecture, RSP08, INV07, INV08, C108.

AUTH06 — Ledger and postings

The ledger owns exact currency/scale/rounding and append-only balanced posting sets; balanced means exact-unit debits equal credits for the governed scope. Routes: fintech architecture, RSP09, INV02, INV06, C47.

AUTH07 — Portfolio and P&L projection

Portfolio/P&L is derived, versioned, freshness-bounded, gap-aware, disposable, and rebuildable. A projection never authorizes a financial action. Routes: fintech architecture, RSP10, INV10.

AUTH08 — Provider receipts and ambiguity

Provider idempotency key, request/response/callback identities, lookup, deadline, and evidence distinguish unknown outcome from failure. Routes: fintech architecture, RSP08, INV08, C90, C108.

AUTH09 — Reconciliation and audit

An independent control compares authoritative orders, fills, postings, provider receipts, clearing/settlement sets, and projections; discrepancies have owner, age, value, repair evidence, and closure. Routes: fintech architecture, RSP10, INV06–INV08, INV10, C48.

Portable formulas and reviewed examples

Choose the formula from the question and name its units before substituting a remembered value. The examples come from different planning scenarios; compare their live load, safety reserve, fan-out, and item sizes before combining results.

Keep units through every line. Limits/prices/examples below are the reviewed package inputs, not timeless architecture constants.

ID	Purpose	Formula	Units	Reviewed example / branch	Routes
FML01	Kinesis aggregate shards	ceil(max(R_records × B_record / 1,000,000 B/s/shard, R_records / 1,000 records/s/shard) × k_skew / u_target)	records/s; B/record; shards	8,000 records/s × 700 B, 1.25 skew, 0.80 utilization → 13 shards	Kinesis, cost/capacity; C70, C75, C114; A95, A99; 2026-08-22
FML02	Kinesis hot-key test	R_key = R_records × share_key; feasible only if R_key ≤ 1,000 records/s/key lane for this reviewed provisioned baseline	records/s	8,000 × 0.15 = 1,200 records/s: INFEASIBLE single lane	Kinesis, cost/capacity; C75, C114; A95; 2026-08-22
FML03	Recovery spare and drain	spare = C_commit - R_live - R_safety; drain = backlog / spare only when spare > 0; otherwise NO_SAFE_DRAIN	records/s; records; s	9,000 − 5,000 − 1,000 = 3,000 records/s; 4,500,000 / 3,000 = 1,500 s = 25 min	cost/capacity, reliability; C104, C114; F13, A117; 2026-08-22
FML04	Batch, fan-out, retry/replay work	source = R × seconds; processed = source × (1 + retry + replay); invocations = processed / batch × consumers; consumer_work = processed × consumers	records/month; invocations/month; record-consumer operations/month	5,000 × 2,592,000 = 12,960,000,000; with 0.02 retry, 0.05 replay, batch 100, 3 consumers → 416,016,000 invocations and 41,601,600,000 operations	cost/capacity; C49, C102, C113; F19, A123; 2026-08-22
FML05	DynamoDB transactional base plus ordinary GSIs	base_WRU = 2 × Σ ceil(item_KiB) for transaction items; GSI_WRU = Σ ceil(index_KiB); keep every base/index lane separate	WRU/order; WRU/s	Items 1.2, 0.7, 1.6, 0.2 KiB → 12; GSIs 0.45, 0.35, 0.45 KiB → 3; 15 WRU/order, 1,800 WRU/s at 120 orders/s	DynamoDB, cost/capacity; C95, C114, C116; A100, A101, A104, A127; 2026-08-22
FML06	DynamoDB lane and replica topology	lane_WRU/s = order_WRU × orders/s × lane_share; base replicated writes are rWRUs and ordinary GSI writes occur in each replica Region	WRU/s/lane; Regions	4 × 120 × 0.50 = 240 WRU/s hot order lane; at share 1.0 → 480 WRU/s	DynamoDB, cost/capacity; C114, C116; A100, A127; 2026-08-22
FML07	CQRS complete-cost break-even	(fixed_USD/month + variable_USD/month) / (writes/month × avoided_USD/read); if avoided benefit is zero, return NO_ECONOMIC_WIN before division	USD/month; writes/month; USD/read; reads/write	(2,350 + 279.351238) / (61,560,000 × 0.000000566) = 75.462912 reads/write	cost/capacity; C35, C49, C102; F06, F19, A113; 2026-08-22
FML08	CQRS sensitivities	Recompute the same complete-cost numerator and benefit denominator; never swap fixed/variable or half/double associations	reads/write	half volume 142.908388; double volume 41.740175; zero benefit NO_ECONOMIC_WIN	cost/capacity; C49, C102; F19, F20; 2026-08-22
FML09	Lambda concurrency and work	concurrency = ceil(arrival_records/s / batch_records × duration_s/invocation × headroom); GB-s = invocations × memory_GB × duration_s/invocation	concurrent invocations; GB-s/month	Also expose requests separately; concurrency or request count alone is not cost	cost/capacity; C49, C53, C115; A123; 2026-08-22
FML10	Sustained-compute capacity	capacity/task = batch_records / service_time_s; tasks = max(HA_min, ceil(peak_records/s × headroom / capacity/task))	records/s/task; tasks	Reviewed baseline: 125 records/s/task; 400 × 1.5 needs 5 tasks; capacity-feasible minimum fleet 177.732 USD/month, with no price crossing in the reviewed envelope	cost/capacity; C53, C115; A124; 2026-08-22
FML11	Unit economics	(marginal + allocated_shared + risk_adjustment) / business_outcome_count; publish each numerator separately	USD/outcome	Denominator may be accepted order, settled trade, account, or replayed record—name it	cost/capacity; C49, C102, C112, C113; F19, F20
FML12	Error budget and burn pair	allowed_bad = N × (1-T); remaining = allowed_bad-B; consumed=B/allowed_bad; burn(W)=(bad_W/eligible_W)/(1-T)	events; ratio; window	For T=1 or zero-tolerance financial safety, do not divide: page/freeze on the break	operations; C117; F14, F15, F16, F39
FML13	Freshness	freshness_s = observation_time_s - source_watermark_or_asOf_s	seconds	Measure authority-to-projection age; queue age alone does not prove business freshness	operations; C59, C117; F01, F14
FML14	RTO, RPO, recovery headroom	raw_spare = C_recovery - R_live - R_safety; effective_replay = max(0,min(cap,raw_spare)); drain_s = backlog/effective_replay when positive	records/s; records; seconds	RTO is maximum acceptable restore delay; RPO is maximum acceptable data-loss/recovery-point age; objectives remain unmeasured until tested	reliability; C104, C105; F13, F14, A119; 2026-08-22

Operational signals and runbook triggers

The formulas identify a limit; the operating signals show when it is being approached. Connect each signal to the obligation at risk and the runbook owner. A cleared technical alarm is only one part of recovery evidence.

• Business outcomes: admitted obligations, accepted/rejected/expired commands, unique fills, settled value, unresolved obligations, and zero-tolerance safety breaks—not only transport success.
• Age/lag: oldest work, per-shard/group lag, source watermark freshness, retention margin, callback age, rebuild catch-up, and deadline remaining.
• Poison identity: raw identity/source position, repeat count, error class, affected scope, quarantine age, and owner.
• Retries/throttles: attempts by owner layer, amplification, partial failures, downstream saturation, concurrency/capacity, and retry-budget exhaustion.
• Authority/projection gaps: stale/gap/duplicate versions, receipt versus status, exact control totals, projection freshness, and reconciliation breaks.
• Imbalance/break aging: amount/currency/scope, provider/ledger difference, oldest unresolved age, value at risk, repair state, and evidence.
• Writer epoch: active writer/lease, stale rejection, split-brain evidence, checkpoint/source version, and failover/failback decision.
• RPO age and recovery: latest proven recovery point, immutable artifact, restore/catch-up time, effective headroom, measured RTO/RPO, and game-day result.
• Security evidence: tenant/principal/action/resource/decision, policy/key/ secret change, data classification/redaction, audit population, and retention.
• Cost drivers: records/bytes/requests, batch/fan-out/retry/replay, storage/ retention/transfer, projection/index amplification, active/idle compute, observability, reconciliation, shared team, and risk burden.

Trigger a runbook from business deadline/budget burn plus the causal boundary: contain unsafe actions, protect live capacity, preserve evidence, identify one owner, repair authority before projections, verify totals, and record closure.

Interview readiness checklist

1. Narrate in this order: requirements → authority/invariants → identities and guarantee boundaries → service/pattern choice and rejection → capacity/cost → failure/recovery/reconciliation → observability/security → falsifier.
2. Ask who owns retries, the stopping deadline, poison evidence, ambiguity lookup, live/replay headroom, RTO/RPO proof, and human escalation.
3. Ask what is marginal, allocated, and risk-adjusted; name every unit, round at the billed boundary, test hottest physical lane, and show zero/infeasible branches before division.
4. Ask for tenant/principal/resource boundaries, exact-money representation, immutable/auditable evidence, secrets/keys, release compatibility, and DR exercises.
5. Do not claim a projection, cache, GSI, search index, or stream authorizes money or an order transition.
6. Avoid “the system is exactly once,” global order from a partitioned service, checkpoint equals effect, DLQ equals recovery, failover equals tested RTO/RPO, aggregate capacity equals hot-lane feasibility, or price-only service choice.
7. Close with the next measurement or experiment that could falsify the design.

Takeaway and next step

Return to the complete study guide for the full sequence, or use interview drills to practise the boundary you just reviewed. Keep the detailed chapter and its dated evidence behind every concise answer.