Course Design — AWS SQS

The design document behind the course. It exists so that 32 modules written over many sessions stay consistent, nothing in the spec gets dropped, and every diagram/lab/code sample has an owner.

Spec: ../aws-sqs-prompt.md · Template: _reference/chapter-template.md · Facts: _reference/aws-facts.md

1. Design decisions

Why 32 modules and not the spec's 28 directories

The spec gives two lists that don't fully agree: a 25-entry LEVEL 0–24 curriculum and a 28-entry directory tree. Neither covers everything the spec's body sections demand. Four topics that the spec treats at length had no home in the directory tree:

The spec explicitly permits this: "You may adjust the number of modules if necessary, but maintain a logical progression." Every directory name from the spec's tree is preserved; the four above are inserted and the sequence renumbered. §2 below is the full traceability table proving nothing was dropped.

Ordering change: lifecycle before queue types

The spec's directory tree puts 04-standard-queue / 05-fifo-queue before 06-message-lifecycle. This course reverses that. Standard-vs-FIFO is a comparison, and a comparison is meaningless before the reader knows what a message's life looks like. So:

03 architecture → 04 the API surface → 05 the lifecycle → 06 standard → 07 FIFO

By module 06 the reader already knows what "at-least-once" and "in-flight" mean, so the standard/FIFO contrast lands as a genuine trade-off rather than a feature list.

Ordering change: semantics before retries

09-delivery-semantics-and-idempotency sits before 10-retries and 11-dead-letter-queues. Retry design is unsafe to teach before the reader accepts that duplicate execution is guaranteed, not exceptional. Idempotency is a precondition for retries, not a footnote after them.

Three-tier depth

Every hard topic is written at three explicit levels (🟢 what / 🟡 how / 🔴 what breaks). A reader preparing for an interview next week reads levels 1–2. A reader on call reads level 3. The level-3 material is the reason this is a course and not a tutorial.

2. Traceability — spec → module

Proof that every numbered LEVEL and every named spec section has a home.

3. Module map

4. Dependency graph

flowchart TD
    subgraph F["Foundations 🟢"]
        M00[00 Prerequisites] --> M01[01 Messaging Fundamentals]
        M01 --> M02[02 SQS Introduction]
        M02 --> M03[03 SQS Architecture]
        M03 --> M04[04 Sending & Receiving]
        M04 --> M05[05 Message Lifecycle]
    end

    subgraph C["Core mechanics 🟡🔴"]
        M05 --> M06[06 Standard Queues]
        M05 --> M08[08 Visibility Timeout]
        M06 --> M07[07 FIFO Queues]
        M08 --> M09[09 Delivery Semantics & Idempotency]
        M06 --> M09
        M09 --> M10[10 Retries]
        M10 --> M11[11 Dead Letter Queues]
    end

    subgraph E["Efficiency 🟡🔴"]
        M04 --> M12[12 Long Polling]
        M04 --> M13[13 Batch Processing]
        M12 --> M14[14 Scaling Consumers]
        M13 --> M14
        M14 --> M15[15 Performance & Throughput]
        M13 --> M18[18 Cost]
        M12 --> M18
    end

    subgraph O["Operating 🔴"]
        M11 --> M17[17 Monitoring & Observability]
        M15 --> M17
        M04 --> M16[16 Security]
    end

    subgraph I["Integrations 🔴"]
        M13 --> M19[19 Lambda]
        M08 --> M19
        M02 --> M20[20 SNS Fanout]
        M20 --> M21[21 S3 / EventBridge / API GW]
        M14 --> M22[22 ECS / EKS]
        M14 --> M23[23 Spring Boot]
    end

    subgraph P["Synthesis ⚫"]
        M09 --> M24[24 Distributed Systems Concepts]
        M24 --> M25[25 Production Architecture]
        M17 --> M25
        M16 --> M25
        M25 --> M26[26 Troubleshooting]
        M25 --> M27[27 SQS vs Kafka vs RabbitMQ]
        M25 --> M28[28 Case Studies]
        M28 --> M29[29 Hands-on Labs]
        M29 --> M30[30 Capstone]
        M26 --> M31[31 Interview Prep]
        M30 --> M31
    end

Critical path (minimum to be dangerous in production): 00 → 01 → 02 → 04 → 05 → 08 → 09 → 11 → 17.

5. Diagram inventory

The spec requires 40 diagrams. Each has exactly one owning module; others link to it.

Extras beyond the required 40: S3 → SQS (21), API Gateway → SQS (21), ECS worker fleet (22), Kafka partitions/offsets (27), RabbitMQ exchanges/bindings (27), capstone architecture (30), one per case study (28).

6. Code inventory

All Java 21 + AWS SDK for Java 2.x. Each sample is owned by one module.

7. Lab inventory

29-hands-on-labs/ — each lab states prerequisites, setup, steps, expected observation, teardown, and estimated AWS cost (nearly all fall inside the free tier).

8. Revision pack

revision/ — written after the course body, derived from it, never copy-pasted from it.

9. Build order and status

10. Final audit checklist

From the spec's VALIDATION BEFORE COMPLETION section. Run at phase 9.

What SQS is · why queues exist · producer · consumer · polling · message · queue · standard queue · FIFO queue · at-least-once delivery · ordering · visibility timeout · receipt handle · DeleteMessage · retry · DLQ · redrive policy · long polling · batch APIs · consumer scaling · throughput · backpressure · idempotency · Lambda · SNS · S3 · ECS · EKS · Spring Boot · IAM · encryption · CloudWatch · troubleshooting · cost · production architecture · SQS vs Kafka · SQS vs RabbitMQ · hands-on labs · capstone · interview preparation

Plus mechanical checks:

• Every internal link resolves
• Every Mermaid block renders
• No quota or price hard-coded outside _reference/aws-facts.md
• No AWS credentials in any code sample
• Every diagram is followed by explanatory prose
• Every module has all 12 template sections
• Every term defined exactly once, on first use, and linked thereafter