Cloud Architecture Design Questions
Part of the Cloud Computing Roadmap
In short
"Design a photo-sharing app on the cloud" has no single right answer. The interviewer is watching how you ask, estimate, start simple and talk through trade-offs, not whether your diagram matches theirs.
'Design a highly available architecture for X application' — testing whether you can apply Phase 11's patterns and Phase 6's database choices to a concrete scenario, with clear trade-off reasoning.

Think of it like this
The architect's first questions
A good architect doesn't start drawing the moment you say "build me a house". How many people live there? Will parents move in later? What's the budget? Only then does the pencil touch paper, starting with a simple outline before the fancy balcony.
Watch it happen
A calm 40-minute design answer
1/6Ask about users, features in scope, read vs write mix, latency needs and budget. Write the answers down.
The big ideas
What you need to know
Questions first
Spending the first five minutes on requirements is a strength, not a delay. Assumptions said out loud count too.
Numbers guide choices
Ten requests a second and ten thousand need very different designs. Estimate before you add Kafka.
Start boring
Managed services and a simple layout first. Add complexity only when a requirement forces it.
Think aloud
Narrate trade-offs: "I'd use DynamoDB here because access is by key, but we lose easy joins."
See it in code
Walk through the code
1Photo app for a college fest, rough numbers2Users: 50,000 total, 10,000 active on fest day3Uploads: 2 photos per active user = 20,000 photos4Photo size: ~3 MB, so 20,000 x 3 MB = 60 GB per day5Peak: most uploads in 4 evening hours6 20,000 / (4 x 3600 s) = about 1.4 uploads per second7Reads: ~10 views per photo = 200,000 reads per day8 9So: object storage for photos, a CDN for reads, a small10database for metadata. Storage and bandwidth matter most.1/3Start from users and work out daily data. Round freely, interviewers expect it.
Back-of-envelope maths you can do on a whiteboard in two minutes. It shows the app tier is tiny and storage is the real story.
Save yourself the pain
Common mistakes
Oops
Jumping straight into drawing microservices, Kubernetes and three databases.
Do this instead
Clarify, estimate, then draw a simple version. Complexity should be earned by requirements.
Oops
Defending your first design no matter what the interviewer hints.
Do this instead
Treat hints as new requirements. Saying "good point, I'd change this to..." scores well.
Your mission
Run one mock design
Quick check
The interviewer says "design a results portal for 5 lakh students". What should you do first?
Go deeper
- 1Practice a repeatable structure: requirements, compute, storage, networking, redundancy, cost.
- 2Prepare 1-2 fully worked-through examples (e.g. a 3-tier web app with auto-scaling).
- 3Practice justifying trade-offs (cost vs redundancy) explicitly as part of your answer.
More architecture & design at this stop
Stuck on this topic? Ask an Insider
Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.