Canonical terminology and guarantee language

Reference appendixDownload original Markdown ↗

Last reviewed: 2026-08-23

Tasks 2–14 use these terms consistently. Definitions describe the package's language; product documentation can use the same word differently, in which case the chapter names that product-specific meaning explicitly.

Core vocabulary

Term	Canonical meaning	Required distinction / example
Command	A message that requests an actor or aggregate to attempt an action. It is named imperatively and can be accepted or rejected: PlaceOrder, ReserveFunds, CancelOrder.	A command expresses intent, not a fact. Receiving one does not prove the action occurred.
Event	An immutable record that a domain or system fact occurred, named in the past tense: OrderAccepted, FundsReserved, TradeExecuted.	An event is not an instruction. Integration events may be derived from state; event-sourced events are the authoritative state history.
Message	The transport envelope sent through a channel. It can carry a command, event, notification, document, or reply plus identifiers, schema version, causation/correlation metadata, and timestamps.	Transport terms such as delivery, acknowledgement, visibility, partition, and DLQ apply to messages. They do not define the payload's business meaning.
Notification	A message whose business purpose is to tell a recipient that something happened or changed. It may carry only an identifier and require a read from an authoritative API/store, or carry richer context.	A notification is not intrinsically lossy or replaceable. Loss tolerance, durability, replay, acknowledgement, and required recipient behavior belong to the business contract and chosen transport.
Event-carried state transfer	Publishing enough current state in an event for a consumer to update a local copy without a synchronous read back to the producer.	This deliberately duplicates state and creates freshness/version/rebuild obligations. It is not event sourcing.
Event collaboration	An interaction style in which components announce facts and independently react, so the overall workflow emerges from subscriptions and event cascades rather than one caller directing every step.	It can use notification or event-carried state transfer. It is not event sourcing, and an expected single recipient action is usually clearer as a command.
Event sourcing	Persisting an aggregate's state transitions as its authoritative append-only event sequence and deriving current state by replay, often with snapshots.	Publishing events from a CRUD database is not event sourcing. CQRS does not require it.
CQRS	Separating the model/path that decides and records commands from the model/path that serves queries. Separation can be code-only, share one store, or add asynchronous projections and specialized stores.	CQRS does not require two databases or event sourcing. Every added read model needs authority, freshness, ordering, read-your-writes, duplicate, rebuild, recovery, and cost contracts.
Transactional outbox	Committing a semantic publication-intent record with authoritative state in one local database transaction, then relaying it asynchronously.	It closes that local state/message-intent atomicity gap only. Relay publication and consumer effects can repeat and still require identity, idempotency, replay, and reconciliation.
Saga	A long-running business process composed of local transactions and forward recovery or compensating business actions, implemented through choreography or orchestration.	It is not a distributed ACID transaction. Compensation is not rollback; irreversible pivots, timeouts, semantic locks, receipts, and reconciliation must be explicit.
Log	A retained, ordered sequence in which consumers track their own positions and can replay records within the retention boundary. Order is normally scoped to a partition/shard.	A log favors independent consumers and replay; acknowledgement usually advances consumer position rather than deleting the shared record.
Queue	A channel primarily used to assign each unit of work to one of a set of competing consumers, with acknowledgement/removal or visibility/redelivery semantics.	A queue favors work distribution. Some queue products retain or redrive messages, but that does not make them a general replay log.
Publish-subscribe router	A channel that evaluates or replicates a publication for independently configured subscriptions/targets, so zero, one, or many consumers may receive their own delivery.	Routing/fan-out does not itself define retention, replay, order, acknowledgement, or consumer-effect guarantees. Concrete product and endpoint semantics still govern.
Delivery guarantee	A transport statement about attempts to hand a message from a named producer/channel boundary to a named receiver: at-most-once, at-least-once, or a narrowly defined duplicate-suppression guarantee.	It says nothing by itself about successful handler completion, database commits, or external effects. Always name the boundary.
Processing guarantee	A statement about executions and committed effects for a named consumer operation, including retry/crash behavior and the state transaction used.	“Exactly-once processing” is prohibited unless the identity, transaction boundary, side effects, and recovery behavior are proven. Prefer “at-least-once delivery plus idempotent effect X.”
Business-effect guarantee	A statement about the externally meaningful outcome for one logical command/event identity, such as one reservation, one execution record, one ledger posting set, or one customer notification under its stated contract.	It is proved at the authoritative state/side-effect boundary with identity, atomicity or idempotency, recovery, and reconciliation—not inherited from transport delivery.
Business idempotency	The property that repeating the same logical request or event identity produces one intended business transition/effect and a compatible response.	Deduplicating transport sends is insufficient. Protect the authoritative mutation and idempotency record in one transaction when possible.
Ordering key	The key whose messages require a serialization relationship, such as orderId or accountId. It maps to a message group, partition, shard, or single-writer lane.	State the scope and what happens during retries, parallel processing, resharding, and cross-key operations. “Ordered” without a key/scope is incomplete.
Aggregate	A consistency boundary whose invariants are enforced together through a designated root and version/state transition.	An aggregate is a domain boundary, not automatically a database table, DynamoDB partition, Lambda function, or microservice. Cross-aggregate invariants need coordination or reconciliation.
Projection	A derived read model built from authoritative state or events for a particular access pattern, such as portfolio view, search index, notification preference view, or P&L dashboard.	A projection has a freshness/rebuild contract and may be stale or wrong. It must not enforce a hard monetary invariant that requires current authoritative state.
Authoritative state	The state and transition history designated to decide a business fact and enforce its invariants—for example accepted order state, reservation, execution, or posted ledger entry.	“Source of truth” is avoided unless scope is named. Different domains can have different authorities; replicas and projections are not co-authorities by default.
Ledger	An append-oriented accounting record of postings with stable identity, currency/scale, balancing rules, audit history, and correction/reversal semantics.	An event bus, event archive, mutable balance row, or generic event store is not automatically a financial ledger. Balances and portfolio views can be derived from ledger entries.
Reconciliation	A repeatable comparison of independently obtained authoritative/control totals or records, followed by classification, repair/escalation, and evidence that discrepancies were resolved.	A retry is not reconciliation. Reconciliation detects silent loss, duplication, corruption, and drift that transport metrics can miss.
Order lifecycle	The versioned authoritative state machine for one logical order, including acceptance, routing, partial execution, cancel/replace requests, terminal outcomes, and governed corrections.	A cancel request is intent, not proof that an already accepted fill disappeared. OrdStatus describes current state while ExecType describes the specific report.
Execution / fill	A venue- or matcher-authoritative fact that a quantity traded at stated terms, identified by a stable execution identity and linked to its order/version.	A transport message, portfolio change, or notification is not the fill authority. A bust/correct is a new linked fact, never a silent edit.
Reservation	Authoritative, versioned earmarking of exact cash or securities that reduces available capacity within a named account, instrument, currency, and product-policy scope.	A portfolio/cache view cannot authorize a reservation. Release, consume, and expiry are explicit transitions reconciled to orders and postings.
Clearing obligation	The governed obligation produced after execution and before final settlement, including counterparties, quantity/amount, asset, intended value date, and status.	Execution, clearing acceptance, and settlement completion are different facts with different external evidence.
Settlement	Completion or classified failure of the governed transfer that discharges a clearing obligation under the applicable venue, custodian, depository, bank, calendar, and legal policy.	“Executed” does not mean “settled.” Finality point, calendar, cutoff, and notice obligations are policy inputs, not universal constants.
Posting set	A stable-identity group of append-oriented exact-unit cash or securities postings that obeys its balancing/conservation rule and links to the source obligation/execution.	Corrections use linked reversal/difference posting sets. Updating or deleting history silently is prohibited.
Business time	The domain-effective time used by a named policy, distinct from source event time, ingestion time, processing time, and system-recorded time.	A wall-clock timestamp alone does not establish causality, serialization, or the applicable business date. Reports map policy time zones/cutoffs into UTC half-open windows.
Event contract	The versioned syntactic and semantic agreement for a message: identity, producer, type, payload meaning, units, required/optional fields, ordering/version scope, privacy classification, and compatibility policy.	An envelope standard or JSON schema alone does not establish business meaning, backward/forward compatibility, or processing guarantees.

Supporting control terms

Term	Canonical meaning
Marginal AWS cost	Incremental regional service charges caused by one more workload unit under declared tiers and rounding; it excludes fixed platform ownership and expected loss.
Allocated platform cost	Marginal AWS cost plus a declared allocation of shared engineering, on-call, compliance, and platform burden to a business denominator.
Risk-adjusted fully loaded cost	Allocated platform cost plus an explicitly modeled expected correctness/availability-loss scenario; expected loss never permits a weaker invariant, audit control, or SLO.
Retry boundary	The component that observes a failure, owns attempt count/age/backoff, and decides success, terminal failure, or handoff. EventBridge target delivery, Lambda async invocation, an event-source mapping, SDK retry, and business workflow retry are separate boundaries.
Dead-letter destination (DLQ)	A holding destination for messages a named delivery/processing boundary stopped retrying. A DLQ requires alarms, retained context, diagnosis, safe redrive, idempotency, and reconciliation.
Replay	Re-reading retained historical records from a chosen position into a named consumer/version. Replay specifies scope, order, rate limit, side-effect suppression/idempotency, checkpoint, and completion reconciliation.
Backpressure	A policy for keeping admitted work within bounded downstream capacity by limiting concurrency/backlog, slowing or rejecting producers, deferring work, shedding lower-value work, or isolating capacity.
Lag budget	The maximum acceptable age/freshness delay for a workload plus the time and spare capacity allocated to drain backlog after a peak or outage. It is stated per consumer, key, tenant, or priority class where aggregate lag can hide starvation.
Fairness	The scheduling/isolation policy that bounds how much one tenant, key, priority class, or poison item can delay others. Aggregate throughput is not evidence of fairness.
Authoritative inference	Not a valid term. Architecture conclusions are labeled simply Inference: and cite their documented premises; they are never promoted to vendor guarantees.
Service level indicator (SLI)	A dimensioned measurement of a named user/business outcome over an explicit eligible population and observation boundary. A technical component metric can diagnose an SLI but is not automatically the SLI.
Service level objective (SLO)	A target range for an SLI over a declared window, population, exclusions, and owner. A planning SLO is not a vendor promise or production commitment until validated and approved.
Error budget	The allowed bad-event amount implied by an availability/latency-ratio SLO over one window. It governs release and reliability action; it never authorizes a correctness, financial-invariant, security, or audit-completeness breach.
Burn rate	Error consumption divided by allowed error for the same normalized interval. Fast and slow windows trade detection speed against noise; a concrete alert threshold remains policy.
Audit evidence	Retained records selected to prove a named business, access, or change assertion within an explicit producer and completeness boundary. It is distinct from sampled diagnostic telemetry and requires schema, identity, integrity, access, retention, hold, and validation ownership.

Guarantee sentence template

Use this shape whenever delivery, ordering, consistency, or “exactly once” is discussed:

Documented: [service/component] provides [property] for [operation] within [scope/key/transaction], subject to [retry, window, mode, or exception] ([source ID], retrieved [date]). Boundary: this does not cover [consumer commit/external effect/cross-partition operation]. Design response: [idempotency/version check/outbox/reconciliation].

Examples:

• Documented: SQS FIFO suppresses repeated sends sharing a deduplication ID during the documented interval and orders messages within a message group (A10, retrieved 2026-08-22). Boundary: neither property commits the consumer's ledger write once. Design response: transact the event ID and ledger posting, and reconcile postings.
• Documented: EventBridge applies its target retry policy when it cannot deliver an event to a target (A05, retrieved 2026-08-22). Boundary: after Lambda accepts the invocation, function/runtime and business failures belong to different controls. Design response: name the invocation type and its retry/destination plus business idempotency.
• Inference: because a trade transition spans account and order keys, a per-order stream sequence alone cannot enforce the cash invariant. Keep the reservation on the authoritative command side or introduce explicit coordination and reconciliation.

Prohibited shorthand and replacement

Do not write	Write instead
“SQS FIFO/Lambda is exactly once.”	“SQS FIFO deduplicates sends within its documented interval and orders within a message group; Lambda delivery/processing can repeat, so effect X is idempotent.”
“EventBridge retries Lambda for 24 hours.”	“EventBridge retries target delivery according to the target policy. State separately how the chosen Lambda invocation path and business handler failures are retried.”
“Kinesis guarantees order.”	“Kinesis orders records within a shard; records using the stated partition key share an ordering scope, subject to the documented write and resharding behavior.”
“DynamoDB is strongly consistent.”	“This base-table read requests strong consistency; the GSI/Stream path is eventually consistent.”
“The DLQ prevents loss.”	“The DLQ retains terminal failures at boundary X; alarms, redrive, idempotency, and reconciliation close the recovery loop.”
“CQRS uses two databases.”	“CQRS separates command and query models; this design uses [same store / asynchronous projection / specialized read store] for stated access patterns.”
“This is event sourcing because it publishes events.”	“The authoritative store is [state/event sequence]. Integration events are published through [outbox/Stream] after that local commit.”
“The portfolio table is the source of truth.”	“The execution/ledger domain is authoritative for X; the portfolio table is a projection with freshness and rebuild SLO Y.”
“Serverless is cheaper and scales automatically.”	“For workload W in eu-west-1 on date D, the measured/modelled unit cost is X; concurrency, downstream capacity, backlog age, and operational cost bound scaling.”
“Global ordering is impossible.”	“Global serialization is possible only by coordinating through a common ordering scope; this design chooses per-key order to preserve parallelism and reconciles cross-key invariants.”

Term consistency checklist

Each major chapter must pass these checks:

• commands are imperative and events are past-tense facts;
• messages/envelopes are not confused with domain events;
• queue and log behavior is described from the concrete service semantics;
• delivery and processing guarantees name their boundaries;
• ordering statements name their key/partition/group and failure behavior;
• authoritative state, ledger, and projections are labeled in every fintech flow;
• replay and reconciliation are separate procedures;
• CQRS, event sourcing, outbox, event-carried state transfer, and notifications are not used as synonyms.