Architecture Case Studies

TL;DR

• Same AWS fundamentals apply across every industry; what changes is which constraint is non-negotiable — correctness/audit for banking, PHI handling for healthcare, spike elasticity for retail, global asset delivery for media, multi-tenancy for SaaS.
• A core-system migration (e.g., a banking ledger) requires a phased/dual-running approach, not a big-bang cutover — the cost of a mistake is regulatory and financial, not just operational downtime.
• Compliance requirements (HIPAA, financial audit trails) must shape the data pipeline and access model itself, not be bolted on as a separate access-control layer afterward.
• Retail’s defining trait is a predictable, extreme, bounded-duration traffic spike — the correct answer is elasticity around baseline, never permanent peak provisioning.
• Multi-cloud is usually an inherited constraint (acquisition, vendor lock-in, regulation), not a deliberate redundancy strategy — the practical goal is identity federation, not full architectural parity across clouds.

Core Concepts

Enterprise migrations — risk tolerance scales with workload criticality

Migration mechanism (MGN, DMS, Strangler Fig) is largely industry-agnostic; the acceptable failure mode is not. A marketing website and a core banking ledger can both technically migrate via the same tooling, but the ledger demands a slower, phased, dual-running approach with heavy reconciliation testing, because a failure there carries regulatory and financial consequences a typical enterprise app migration doesn’t.

Scenario: Banking core ledger migration. Requirements: zero tolerance for a big-bang cutover weekend, system must remain fully operational throughout, correctness must be provable at every step. Design approach: run the legacy and new systems in parallel (dual-running) with continuous reconciliation between them, or migrate discrete ledger functions incrementally using a Strangler Fig pattern, cutting over piece by piece only once each piece is validated against production data. A full-cutover migration is rejected outright — not because it’s technically infeasible, but because the business explicitly stated zero tolerance for cutover-weekend risk, and a phased approach is the only one that satisfies that constraint.

Banking — correctness and auditability as first-class design constraints

Every transaction must be traceable; every system change needs an audit trail. “Eventually consistent” is frequently unacceptable for core ledger operations in a way it might be fine for a social media feed. This pushes banking architectures toward stronger consistency guarantees at the data layer (e.g., avoiding eventually-consistent reads for balance-critical operations) and heavier investment in continuous compliance evidence (CloudTrail, Config rules) than a typical consumer application requires.

Healthcare — PHI handling shapes the pipeline, not just access control

Scenario: Healthcare analytics on PHI. Requirements: process protected health information (PHI) under HIPAA (or regional equivalent) while running analytics across patient data. Controls required: encryption at rest and in transit as a baseline; strict IAM and access logging capable of demonstrably answering “who accessed this patient’s data, when, and why”; data residency awareness; and — critically — de-identification or tokenization applied before data reaches broader analytics tooling. The compliance requirement determines the shape of the data pipeline itself (where de-identification happens, what data crosses which boundary), not merely an access-control layer applied after the pipeline is built.

Retail — elasticity as the central design driver

Scenario: Retail 50x traffic spike. Requirements: absorb a single annual sale event driving roughly 50x baseline traffic, then return to normal for the remainder of the year. Design approach: Auto Scaling Groups (or serverless components where they fit) sized for baseline load with aggressive, pre-tested scale-out policies; CloudFront and caching layers to absorb read-heavy load before it reaches origin. Permanently provisioning for 50x peak capacity is rejected — it wastes spend roughly 50 weeks a year to be ready for a two-week event. The extreme spikiness of the traffic pattern is the design driver, not steady-state provisioning.

Media — global delivery combines two distinct problems

Scenario: Global video delivery with minimal buffering. Requirements: deliver large video files worldwide with the lowest possible buffering across varying end-user network conditions. Design approach: S3 for origin storage, CloudFront for edge-cached delivery (solves “get this large file physically close to the user”), and MediaConvert/MediaPackage for adaptive bitrate streaming (solves “adapt quality to this specific user’s actual network conditions”). These are genuinely separate problems — proximity and bitrate adaptation — combined into a single user-facing latency requirement.

SaaS — multi-tenancy as a cross-cutting concern

Multi-tenancy touches every architectural decision rather than living in one component: identity, billing, data isolation, and incident response all need tenant awareness designed in from the start, not retrofitted later.

Multi-cloud — usually inherited, not chosen

Scenario: Post-acquisition Azure estate. Requirements: a company operating primarily on AWS acquires a company with an existing Azure estate; users need to avoid maintaining separate credentials per cloud. Design approach: federate identity through a common IdP, or establish trust between AWS IAM Identity Center and Azure AD/Entra ID, rather than maintaining fully separate identity silos or forcing an immediate full migration of the Azure estate. Full architectural parity across both clouds is explicitly not the goal here — the goal is eliminating duplicated identity management for a constraint the organization didn’t choose (the acquisition), while other workloads may reasonably stay where they are.

Migration Strategy Comparison: Big-Bang Cutover vs Phased Dual-Running

Common Pitfalls

• Pitfall: Applying a generic migration playbook to a core financial system. Why: The playbook doesn’t account for the categorically higher correctness and auditability bar a ledger system carries. Fix: Use a phased, dual-running, or Strangler Fig approach with reconciliation testing for core financial systems.
• Pitfall: Building healthcare analytics pipelines without de-identification baked in. Why: Retrofitting compliance controls after the pipeline exists is more expensive and error-prone than designing them in from the start. Fix: Design de-identification/tokenization into the pipeline before data reaches broader analytics tooling.
• Pitfall: Permanently provisioning retail infrastructure for peak traffic. Why: It wastes significant spend for the ~50 weeks a year the system isn’t at peak. Fix: Size for baseline with aggressive, tested auto-scaling for the spike window.
• Pitfall: Multi-cloud efforts pursuing full architectural parity across both clouds. Why: The actual business need is usually just consistent identity and a handful of shared services, not duplicated infrastructure. Fix: Federate identity and scope multi-cloud work to the actual driver (acquisition, vendor requirement, regulation).

Interview Questions

• “A bank wants to migrate its core ledger to AWS with zero tolerance for a cutover weekend. Design the migration approach.” — tests whether phased/dual-running strategies are reached for over a standard big-bang migration playbook.
• “A healthcare client wants to run analytics across patient data. What does the pipeline design need to account for beyond a standard analytics architecture?” — tests whether compliance-driven pipeline design (de-identification, audit trails) is understood as foundational, not an add-on.
• “A retail client expects 50x traffic for one week a year. How do you size the architecture?” — tests whether elasticity is chosen over permanent peak provisioning.
• “Design global video delivery with minimal buffering for end users.” — tests whether the candidate separates the edge-proximity problem from the bitrate-adaptation problem.
• “An acquisition just brought your AWS-native company a significant existing Azure estate. What’s the practical first move on identity?” — tests whether federation is the reached-for answer over either full parity or fully separate silos.