Module 7: Reference Architectures And Domain Practice
8. Project: your own architecture diagram, new scenario
Description
Documentary. The five previous lessons gave you five reference architecture patterns, each with its diagram and its domain justification already resolved. Lessons 6 and 7 gave you twenty questions where you chose among already-written options. This lesson is different, on purpose: there are no options A, B, C, and D — there's a scenario you've never seen anywhere in this ecosystem, explicitly not Andes Cargo, and the task is to design your own reference architecture diagram, with your own domain justification, before looking at the reference solution that closes the lesson.
This is the real transfer test the rest of the module prepared for: recognizing an already-learned pattern is one skill; composing several patterns to solve a new business, with constraints that don't come labeled by domain, is the skill the exam — and a solutions architect's real work — genuinely demands.
Connection to the module
You're going to use, quite deliberately, the pieces from lessons 1 through 5 of this module as a toolbox: the 3-tier pattern (lesson 1), asynchronous processing (lesson 2), static site (lesson 3), disaster recovery (lesson 4), and migration (lesson 5, if the scenario calls for it). No pattern in this lesson is new — what's new is that you decide which apply, where, and why, with the scenario not telling you the pattern's name.
The scenario: MercadoExpress
MercadoExpress is a grocery delivery platform, operating in three countries (Peru, Colombia, and Ecuador), founded fourteen months ago and already with a real presence in six cities. The company is evaluating migrating its infrastructure, currently split between its own servers and a different cloud provider, to AWS. These are the requirements the founding team delivered, without organizing them by domain — your first job is to read and classify them yourself:
On traffic and the business. Order traffic concentrates in two predictable daily windows — lunch (12:00-14:00) and dinner (19:00-21:00) — with up to 8 times normal traffic during those hours, and practically none between 2:00 and 6:00 a.m. A product catalog with photos is queried constantly; occasionally, a special-offer product concentrates thousands of repeated queries within minutes.
On the order flow. When a customer confirms an order, the system checks inventory, processes payment (through an external, tokenized payment processor — MercadoExpress never stores the full card number), and assigns a delivery driver. Occasionally, a product runs out of stock between confirmation and real verification — those cases need to remain available for manual review by the support team, without blocking the rest of the orders or getting silently lost.
On identity and access. Customers register with email/password or their Google account, with no employee manually creating their account. Delivery drivers are contracted staff, with their own application, needing to authenticate differently from customers. The operations team — twelve people — works from one AWS account per country (three accounts total, plus a shared platform account), and needs variable access to the four accounts based on role, managed centrally.
On sensitive data. Delivery drivers' banking data (to pay them weekly) is stored encrypted, with a key managed by the company itself, not by AWS — an explicit legal-department requirement.
On business continuity. The consumer protection regulator in one of the three countries requires that, facing complete loss of the Region hosting the main infrastructure, order history and inventory be recoverable and available within a maximum of 30 minutes during operating hours — with no requirement for simultaneous active traffic in two regions at all times, a cost the company, still in growth stage, can't sustain.
On batch work. Every early morning, a process reconciles inventory reported by the three countries against physical warehouse counts — a process that tolerates interruptions (it restarts from the last saved checkpoint) and only needs to finish before stores open at 6:00 a.m., with no other exact-timing requirement.
On static content. The customer help page and the marketing landing page are completely static, updated by the marketing team several times a week through an automated deployment pipeline.
Your task
Before reading the next section's reference solution, work through the following on your own, with paper, a text editor, or the diagramming tool you prefer:
- Classify each scenario requirement by domain (Secure, Resilient, High-Performing, Cost-Optimized) — some requirements, as in any mixed scenario from lessons 6 and 7, will touch more than one domain at once.
- Identify which pattern (or combination of patterns) from lessons 1 through 5 of this module solves each business block — the order flow, the product catalog, customer/driver/operations identity, the banking data, business continuity, the nightly job, and the static content.
- Draw a complete reference architecture diagram, with notation similar to previous lessons' (subnets, named security groups, data-flow arrows).
- Write the domain justification for at least three architecture decisions you made — not all of them, the three you consider most important to defend before a technical committee.
Self-assessment rubric
Before seeing the reference solution, check your own work against this list — it's, precisely, the same kind of checklist a real solutions architect uses before presenting a design:
RUBRIC — CHECK YOUR DESIGN BEFORE CONTINUING
☐ The order flow uses an asynchronous pattern (lesson 2), not direct
synchronous invocation — with a DLQ or manual-review queue for
"out of stock" cases
☐ Customer identity uses a Cognito user pool (self-service registration,
Google federation) — NOT IAM users
☐ Operations identity uses IAM Identity Center (centralized access
to 4 accounts) — NOT duplicated per-account credentials
☐ Banking data uses a customer-managed KMS key,
explicitly selected when creating the encrypted resource — NOT an
AWS-managed key
☐ The product catalog, with unpredictable query spikes on
specific items, uses a caching layer (lesson 1 or the
Module 4 vocabulary) — NOT just "a bigger database"
☐ The DR strategy is Pilot Light or Warm Standby (lesson 4) — NOT
Multi-Site Active-Active, which the scenario explicitly rules out
by cost
☐ The nightly reconciliation job uses Spot Instances or an
interruption-tolerant mechanism (lesson 5 or Module 5) — NOT fixed
On-Demand capacity running all night
☐ The static content uses the S3 + CloudFront + Route 53 pattern
(lesson 3), NOT served from the same application tier
☐ Every variable compute piece (application tier during peak hours)
uses Auto Scaling — NOT fixed capacity sized for the 8x
peak
☐ Every security group references the previous tier's by ID
(lesson 1) — NOT open IP ranges between internal tiersA reference solution
There's no single correct architecture for this scenario — as in any real design exercise — but this solution meets every point on the rubric above, and is representative of what an examiner would expect to see.
MERCADOEXPRESS — COMPLETE REFERENCE ARCHITECTURE
── IDENTITY ────────────────────────────────────────────────────
Customers ......... Cognito user pool (email/password + Google, optional MFA)
Drivers ........... SEPARATE Cognito user pool (different app, same mechanism)
Operations ........ IAM Identity Center (4 accounts: PE/CO/EC + platform,
permission sets per role, centralized access)
── ORDER FLOW (pattern: async processing, lesson 2) ─────────────
Customer app ──▶ API Gateway ──▶ SQS (orders queue)
│
▼
Lambda (checks inventory + charges + assigns driver)
│
┌───────────────┴───────────────┐
▼ ▼
success: confirms order failure ("out of stock"):
SQS manual-review-queue
(support team reviews)
── APPLICATION TIER (pattern: 3-tier, lesson 1) ──────────────────
ALB (public) ──SG chain──▶ Auto Scaling Group (private, 2+ AZ)
│ dynamic scaling: 8x during peak hours
▼
Aurora PostgreSQL Multi-AZ
(orders, inventory) + ElastiCache
in front of the catalog (offer product = hot key)
── DRIVERS' BANKING DATA (Secure) ────────────────────────────────
Table encrypted with a customer-managed KMS key
(explicitly created when provisioning the resource, never
the default AWS-managed key)
── BUSINESS CONTINUITY (pattern: DR, lesson 4) ────────────────────
Warm Standby in a secondary Region: reduced but active environment,
continuous Aurora replication to the secondary Region — meets
the 30-minute RTO during operating hours without the cost of
Multi-Site Active-Active, which the company's budget rules out
── NIGHTLY JOB (pattern: migration/batch, Module 5 vocabulary) ──
Inventory reconciliation job on Spot Instances (interruption-
tolerant, no exact deadline except "before 6 a.m.")
── STATIC CONTENT (pattern: static site, lesson 3) ───────────────
Route 53 (ALIAS) ──▶ CloudFront (OAC) ──▶ private S3
(help + landing, file versioning for marketing's frequent
pipeline, NOT repeated manual invalidation)The domain justification for the three most important decisions
Why asynchronous processing for the order flow, and not direct invocation (Resilient + Secure): an order involving a real money charge can't be silently lost if a step fails — the queue with its manual-review DLQ (this module's lesson 2) guarantees no "out of stock" case disappears without a human seeing it, and it decouples the moment the order is placed from the moment it's processed, absorbing the 8x peak without the customer waiting for a synchronous response from every step.
Why Warm Standby and not Multi-Site Active-Active for business continuity (Resilient + Cost-Optimized): the regulator requires 30 minutes of recovery during operating hours — not permanent, simultaneous active traffic in two regions. Warm Standby meets that RTO with a reduced but already-running environment, without the cost of duplicated full production the scenario explicitly rules out by budget — the same exam decision this module's lesson 4 already established with the complete decision tree.
Why IAM Identity Center for the operations team, and not one IAM user per person per account (Secure): twelve people need variable access to four different accounts — manually multiplying identities (up to forty-eight possible combinations) is exactly the error this guide's Module 2 already identified; IAM Identity Center centralizes that management with permission sets per role, auditable from a single place.
Common mistakes
Designing the complete architecture before classifying requirements by domain (skipping the process's first step). What happens: someone starts drawing boxes and arrows immediately, without first identifying which requirement belongs to which domain. How to spot it: if your diagram has pieces you can't explain with "this solves requirement X of domain Y." How to fix it: this lesson's task step 1 — classify before drawing — isn't bureaucracy, it's the same scenario-reading discipline Module 1, lesson 6, already established as this entire guide's central technique.
Applying the most sophisticated pattern available instead of the one the scenario justifies (over-engineering, this whole module's most repeated error). What happens: someone, recognizing multi-site active-active exists, applies it here "because it's the most resilient possible," ignoring that the scenario explicitly rules out that cost. How to spot it: if your DR solution never mentions the budget constraint the scenario explicitly gives. How to fix it: every decision in this exercise — like in any real exam question — must anchor to a textual constraint in the scenario, never to "the technically superior option in the abstract."
Forgetting the product catalog also needs Module 4's "hot key" pattern (treating performance as a problem already solved by Multi-AZ). What happens: someone assumes that, with Aurora Multi-AZ already in the diagram, the product catalog is solved, without adding any caching layer for the offer product concentrating thousands of queries. How to spot it: if your diagram has no piece dedicated to absorbing repeated reads of the same popular item. How to fix it: Multi-AZ solves availability (Resilient); a caching layer solves the uneven read pattern (High-Performing) — they're different problems, with different pieces, the same principle governing this module's lesson 7 ten questions.
Summary and next step
In this lesson you composed, on your own, this module's five patterns into a single reference architecture diagram for a business you'd never seen before in this ecosystem — the real transfer test that distinguishes recognizing a pattern from knowing how to apply it. You compared your own design against an objective rubric and a complete reference solution, with the domain justification for the three most important decisions.
Before moving on, honestly review how many rubric points your first design met before seeing the solution — it's, precisely, the same diagnostic signal Module 1, lesson 8, already taught you to read about your own performance.
This closes Module 7 in full: five reference architecture patterns and twenty mixed cross-domain practice questions. Module 8 — this guide's final capstone — awaits with a complete 50-question practice exam, proportioned to each domain's real weight, followed by the detailed answer key, your own performance analysis, and exam-day strategy.
Resources
- AWS Certification — SAA-C03 exam guide — the four complete task statements this exercise integrates into a single scenario.
- Module 7, lessons 1 through 5, of this guide — the five reference architecture patterns used as this project's toolbox.
- Module 1, lesson 6, of this guide — the scenario-reading technique this task's step 1 applies to a complete case, not just a multiple-choice question.