Architecture Exercise: Design a Highly Available Web Application

As with every hands-on activity in this course, this is worked through entirely as a design exercise — on paper, or in a real AWS account if you choose to explore it there. QuarryDev does not deploy real production infrastructure as part of this course, and there is no single mandatory architecture for this scenario — the point is justifying choices against requirements, not matching a memorized "correct" diagram.

A learning platform, resembling QuarryDev's own, has these requirements:

• Learners browse courses and read lesson pages, which must stay responsive.
• Users authenticate before accessing certain content.
• Uploaded or provided learning assets (images, downloadable files) need durable storage.
• Some background work (for example, generating a completion certificate) should not block the interactive request that triggers it.
• The application should tolerate the failure of an individual compute instance or task.
• Persistent data must survive compute being replaced.
• Logs and metrics are required to know the system is healthy.
• Permissions should follow least privilege throughout.
• Infrastructure should be reproducible, not hand-built.
• Cost matters — this is not a workload that justifies unlimited spend.

• Compute: this workload's traffic is likely to be everyday, moderate, and somewhat predictable, with occasional bursts around new course launches — either ECS/Fargate (Module 9, more control over the running environment) or a serverless API (Module 7, less infrastructure management, well-suited to variable load) could genuinely fit; EC2 alone would fit if there were a specific need for OS-level control this scenario doesn't actually have. Whichever is chosen, the trade-off is real: containers add deployment/observability responsibility, serverless adds cold-start and distributed-system considerations, and neither is "always correct" (Modules 7 and 9's own comparisons apply directly here).
• Database: lesson pages and course structure are naturally relational — courses, modules, and lessons have real, queryable relationships (Module 5) — pointing toward RDS/Aurora. If a specific piece of this platform needed fast, simple lookups by a known key at very high volume with no relationship querying, that specific piece might reasonably use DynamoDB instead — but "DynamoDB is more scalable" alone isn't sufficient justification for the whole platform, since scalability isn't this workload's primary constraint here.
• Storage: uploaded/provided learning assets are discrete files, and S3 (Module 4) fits directly — not the compute tier's own local disk, which Lesson 3 already ruled out for anything that must survive a replaced instance.
• Network boundaries: the load balancer sits in a public-facing entry point; the application and database tiers sit in private networking (Module 6), following this lesson's own three-tier diagram.
• Availability: application instances/tasks spread across at least two AZs behind a load balancer (Lessons 1–2), with a database configured for the availability this workload's requirements justify (Module 5's Multi-AZ RDS pattern, if the requirement calls for it).
• Scaling: an Auto Scaling Group or equivalent (Lesson 3) lets the compute tier grow for a launch-day traffic spike and shrink afterward — safe specifically because the compute tier is stateless (Lesson 3, Module 9).
• Async processing: certificate generation doesn't need to block the interactive request that triggers it — an SQS-based decoupled design (Lesson 2, Module 8) lets that work happen separately, with the trade-off of eventual processing and the need for an idempotent worker (Module 8).
• Security: IAM roles scoped to least privilege for every workload identity (Module 2, Module 9's task roles), Security Groups restricting traffic to only what each tier needs (Module 6), encryption in transit and at rest (Module 10), and secrets in a managed secrets mechanism, never in code (Module 10).
• Observability: CloudWatch metrics and logs for the application and its background workers, with alarms on genuinely meaningful conditions rather than arbitrary thresholds (Module 10) — and CloudTrail available if an unexpected AWS configuration change ever needs investigating (Module 10).
• Backup/recovery: the database's backup strategy is a distinct decision from its availability configuration (Module 5's Backup ≠ High Availability, reinforced by this module's Lesson 1) — and if this platform had a genuine disaster-recovery requirement beyond routine AZ failure, that RTO/RPO conversation would need to happen explicitly, not be assumed covered by Multi-AZ alone.
• Infrastructure as Code: the whole design defined as CloudFormation templates (Module 11), reviewed before any change, rather than hand-built and prone to drift.
• Cost: every choice above trades some cost against resilience or performance — the right balance depends on this platform's actual scale and budget, not a maximal or minimal default (previous lesson).

Two learners could reasonably choose ECS/Fargate versus a serverless API for the compute tier here, and both could be defensible — what actually matters, and what this exercise is testing, is whether the choice is justified against this scenario's specific requirements and stated trade-offs, not whether it matches one memorized diagram. The same applies to every other decision above: the goal is the reasoning, not a fixed destination.