Project: Build a Basic Asynchronous Workflow

This project is a design exercise, worked through entirely on paper (or in a real AWS account if you choose to build it there, following the same two-valid-paths pattern every earlier project in this course has used). QuarryDev itself does not publish real events to AWS as part of this course — the scenario below is fictional, used purely to practice applying this module's concepts to something realistic.

When a learner completes a course, imagine the application publishes a fictional CourseCompleted event. Three independent things should happen as a result, each on its own schedule:

Application
  → publishes CourseCompleted event
  → SNS Topic (or EventBridge, if content-based routing across many event types is needed)
      → Certificate Queue → Certificate Worker
      → Analytics Queue → Analytics Worker
      → Notification path → notification service/function

This is exactly Lesson 3's SNS-plus-SQS fan-out pattern (or, alternatively, Lesson 4's EventBridge routing, if this were one of many different event types needing different rules) — three independent consumers, each buffered by its own queue, none blocking the others.

Work through each component and be able to justify its placement:

• Producer: the application itself, at the moment a course is marked complete.
• Event/message: the fictional CourseCompleted event, carrying only the information each consumer actually needs (a course ID, a learner ID) — no sensitive personal data beyond what's genuinely required.
• Routing mechanism: SNS (a fixed, known set of three subscribers) or EventBridge (if this is one of several different event types the platform needs to route differently) — Lesson 5's reasoning decides which fits.
• Queues: one per consumer (Certificate, Analytics), so a slow or failing consumer never blocks the others — Lesson 3's fan-out reasoning.
• Consumers: independent workers, each doing exactly one job.
• Retry strategy: each queue's own retry behavior, following Lesson 2's visibility-timeout reasoning — a failed attempt becomes visible again for another try, up to a configured limit.
• DLQ: each queue has its own dead-letter queue, so a message that keeps failing (a malformed course ID, for example) is isolated for investigation rather than retried forever.
• Idempotency key: the Certificate Worker, in particular, must not issue two certificates for the same course completion if the event is redelivered — checking whether a certificate already exists for this specific course-and-learner combination before issuing a new one (Module 7's idempotency concept, applied here).
• IAM boundaries: each worker's execution role (Module 7, building on Module 2's least privilege) grants only ReceiveMessage/DeleteMessage on its own specific queue — never broad SQS access across every queue in the account, and the producer's role grants only the specific Publish/SendMessage permission it needs, nothing wider.
• Monitoring: CloudWatch metrics and DLQ depth for each queue (Module 7's observability concepts), so a stuck consumer or a growing DLQ is visible before it becomes a real problem.
• Cost: SNS/EventBridge publishes, SQS requests, and each Lambda consumer's invocations all have their own independent cost story — review current pricing rather than assuming a small training load is free.

If any part of this was built in a real account, work through this checklist before considering the project finished — some of these have dependencies on each other, so order matters:

1. Delete subscriptions from the SNS topic (or remove the EventBridge rules), so nothing continues routing to queues you're about to remove.
2. Delete the SQS queues for each consumer, including their dead-letter queues.
3. Delete the SNS topic (or the EventBridge event bus, if one was created specifically for this training exercise).
4. Delete the Lambda function(s) used for the Certificate, Analytics, and Notification workers.
5. Delete the CloudWatch log groups created for these functions, if you don't need to keep the logs.
6. Delete the IAM execution role(s) created solely for this project, once nothing still references them.
7. Confirm nothing training-related remains by checking the SQS, SNS, EventBridge, Lambda, and IAM dashboards directly — the same "verify, don't assume" discipline every earlier module's project applied to its own resources.