Complete AWS event-driven study guide
This is one complete course of reading, from asynchronous-system fundamentals to a defensible fintech design. All eleven chapters belong to the sequence. Learn the service mechanics, protect business effects, test a real repository against those principles, and prove the resulting system can be operated. Original chapter numbers remain in URLs for stable references; the learning order deliberately puts the repository after the concepts needed to judge it.
Before you begin
Section titled “Before you begin”You should be comfortable following an HTTP request through application code and a database, reading small code examples, and doing arithmetic with rates and units. Basic AWS familiarity helps, but you do not need to memorize service quotas or the source package's identifiers. Foundations introduces the language; the decision guide explains where services fit; Kinesis and DynamoDB supply the mechanics needed by later architecture.
Carry one example throughout: a customer submits an order, receives an acceptance result, and later sees execution and portfolio updates. At each boundary ask who owns the truth, what an acknowledgement proves, what may repeat, what happens after a timeout, and how the business outcome is independently checked. Use the withdrawal, market-data, settlement, and notification examples to test where the answer changes.
How the chapters fit together
Section titled “How the chapters fit together”Read the explanations, work through the examples and detailed contracts, then close the notes and answer the checkpoint. If you cannot defend the answer, revisit the relevant section before moving on. Tables are part of the full treatment: compare their decision dimensions and follow a concrete row through failure and recovery. Exact machine records support the same models; they are not a separate syllabus.
The sequence builds vocabulary before service choice; service mechanics before multi-service patterns; correctness before financial architecture; and architecture before repository diagnosis, economics, and operations. Interview practice integrates all of it. The quick reference is a lookup tool alongside the course, not a replacement for any chapter.
Service coverage map
Section titled “Service coverage map”These are the places to learn each service's role and limits, not a list of interchangeable products.
- Lambda, EventBridge, SNS, and SQS: the messaging and compute chapter compares execution, routing, fan-out, and owned work, including Standard/FIFO choices, invocation modes, retries, and failure destinations. Reliability follows those boundaries into recovery; cost and capacity accounts for batching, fan-out, and sustained load.
- Kinesis Data Streams: the deep dive covers producers, partition keys, consumer libraries, Lambda mappings, checkpoints, retention, hot keys, and replay. MSK/Kafka, Managed Service for Apache Flink, and Data Firehose are compared in the decision guide and streaming material so retained transport, stateful computation, and buffered delivery stay distinct.
- DynamoDB and DynamoDB Streams: the data-modeling deep dive connects access patterns, keys, indexes, transactions, identity, capacity, and rebuilds. CQRS and sagas distinguish table change capture from semantic outbox events and authoritative event history.
- Step Functions: the decision guide introduces Standard/Express and integration modes; CQRS, outbox, and sagas explains workflow coordination, compensation, pivot points, and external-effect ambiguity. Operations adds signals and recovery obligations.
- Adjacent compute and entry points: ECS, Fargate, and EC2 are evaluated against Lambda for sustained or stateful work, especially the matching core. API Gateway, WebSocket APIs, and AppSync appear at request and customer-update boundaries. Amazon MQ is a compatibility option in the service decision guide.
- Adjacent data services: Aurora, OpenSearch, DynamoDB DAX, and Redis/ElastiCache are evaluated as authority or read-store choices, not substitutes for identical guarantees. S3, Glue, and Athena support archival evidence, delivery, rebuild, and analytics discussions in patterns and trading architecture.
- Operations and recovery: observability, security, and operations connects CloudWatch, tracing, CloudTrail, IAM, KMS, and Secrets Manager to business evidence and access boundaries. Reliability explains the place of Route 53 and ARC in fenced regional recovery.
Adjacent services receive decision-level coverage where the architecture requires them. Kinesis and DynamoDB receive dedicated implementation-depth chapters; this guide does not claim an equally deep manual for every AWS product.
Reading the evidence
Section titled “Reading the evidence”A C label names a checked claim in the claim register. F identifies a foundational source, A an AWS source, and R repository evidence in the source index. CS identifies one of the twelve repository findings. Chapters explain their local identifiers—access patterns, invariants, runbooks, and exercises—where needed.
“Controlled” means a statement is tied to explicit evidence and a review rule; it does not broaden an AWS guarantee beyond the stated boundary. References to “Task” or a numbered model in retained contracts are provenance labels from producing the original package, not assignments for you. Cost-workbook and drill premises reuse those identifiers.
Dates and prices are historical snapshots, not live verification. Read a quota, price, or capability together with its region, mode, retrieval date, and citation; recheck the official source before applying it to a live design. Download links preserve exact original bytes, including the package README. This authored guide and the chapter transitions provide the website's learning sequence.
Define commands, facts, work ownership, ordering, and the separate delivery, processing, and business-effect boundaries.
Check your understanding: Trace one accepted order through a timeout and explain what is known, what can repeat, and which record proves completion.
Choose queues, routers, retained streams, workflow orchestration, and compute from explicit workload and recovery requirements.
Check your understanding: Choose a service for a command, a fan-out fact, and a replayable feed; reject a credible alternative for each and name the remaining failure boundary.
3. Kinesis: partitioning, consumers, and replay
Section titled “3. Kinesis: partitioning, consumers, and replay”Connect partition-key order to producer results, consumer checkpoints, hot keys, retention, and safe backlog recovery.
Check your understanding: Calculate the shard plan, explain why one hot key can still fail, and calculate drain time while live traffic continues.
4. DynamoDB: access patterns and authority
Section titled “4. DynamoDB: access patterns and authority”Design keys and indexes from access patterns, protect exact financial state with transactions and durable identity, and plan complete rebuilds.
Check your understanding: Explain the accepted-order transaction, distinguish inbox identity from version checks, and account for each base and index write.
5. CQRS, event sourcing, outbox, and sagas
Section titled “5. CQRS, event sourcing, outbox, and sagas”Separate read optimization, authoritative history, publication intent, and cross-service coordination without combining their guarantees.
Check your understanding: Defend the simplest sufficient CQRS step, describe a projection rebuild, and locate a saga pivot whose effect cannot be rolled back.
Assign retry ownership, retain failure evidence, protect live capacity, reconcile exact outcomes, and recover one fenced writer.
Check your understanding: Walk an ambiguous provider timeout and a poison-event recovery through containment, repair, ownership, and independent closure evidence.
Connect order acceptance, reservations, execution, clearing, settlement, ledger postings, and derived views into explicit authority boundaries.
Check your understanding: Explain a cancel/fill race and a reservation followed by routing timeout; preserve execution history and justify customer-visible state.
Use concrete code evidence to diagnose publication gaps, duplicate effects, unsafe money, incomplete exports, and missing financial controls.
Check your understanding: Narrate the current request path, identify its twelve findings, and propose staged repairs with a proof and residual risk for each.
Recompute complete unit costs and capacity using dated inputs, rounding, fan-out, hot-lane distribution, recovery load, and ownership costs.
Check your understanding: Show a sensitivity that invalidates a cheap average, distinguish modeled cost units from USD, and explain when no safe drain or price crossing exists.
10. Observability, security, and operations
Section titled “10. Observability, security, and operations”Translate business outcomes into measurable SLOs, actionable alarms, scoped access, evidence retention, compatible releases, and recovery exercises.
Check your understanding: Define an eligible SLO population, distinguish budgeted delay from a financial safety failure, and explain the evidence required to resume service.
11. Interview practice and self-assessment
Section titled “11. Interview practice and self-assessment”Combine service selection, failure analysis, quantitative reasoning, system design, and repository review into defensible spoken answers.
Check your understanding: Answer every drill family without notes, check assumptions and arithmetic against the reference answers, and revisit the chapter behind each weak boundary.
Readiness checklist
Section titled “Readiness checklist”You are ready to explain the complete design when you can:
- Distinguish a command, a fact, a queue, a retained stream, a workflow, and a projection without using a service name as the definition.
- Identify every authority and atomic boundary, then trace duplicates, reordered records, missing publication, and ambiguous external effects through detection, containment, repair, and reconciliation.
- Recompute shard, hot-lane, database-write, backlog-drain, batching, CQRS, and compute examples with units and an explicit failure condition.
- Explain why accepted, executed, settled, and customer-visible are different states; preserve exact money, reservation ownership, and balanced financial history.
- Connect the twelve repository findings to staged repairs, prove the chosen SLO and security boundaries, and describe a tested release and fenced recovery.
- Complete every interview-drill family, justify an alternative, name the condition that would change your choice, and identify evidence still needed.
When an answer is weak, follow its premise links back to the chapter, redo the reasoning, and retry the prompt before opening its reference answer. Keep the quick reference for retrieval and the source index for verification. Completion means being able to defend the boundaries and trade-offs, not merely reaching the final page.
Reading layout adapted from SSE reading notes by Mohammed Balila, MIT. Source manifest · Attribution