Architecture Interview Guide

Application Load Balancer (ALB) enables path-based routing to direct traffic to different microservices:

• /browse → Target Group 1 — handles traffic for browsing (e.g. cloudwithraj.com/browse)
• /buy → Target Group 2 — handles traffic for purchases (e.g. cloudwithraj.com/buy)
• /* (catch all) → Target Group 3 — handles all other traffic

Each microservice can have its own compute (EC2 with Auto Scaling Group or Lambda), and its own database (Amazon Aurora, DynamoDB, etc.). The ALB sits behind a domain (e.g. cloudwithraj.com) and routes requests to the appropriate target group based on the URL path. This allows each microservice to scale independently using an Auto Scaling Group behind Amazon EKS.

An event-driven architecture decouples the producer and processor. The producer (human) invokes an API and sends information in a JSON payload. API Gateway puts it into an event store (SQS), and the processor (Lambda) picks it up and processes it. API Gateway and Lambda can scale and be managed/deployed independently.

Flow: API Gateway → SQS (Event Store) → Lambda

Benefits

1. Scale and fail independently — Services are only aware of the event router, not each other. If one service fails, the rest keep running. The event router acts as an elastic buffer that accommodates surges in workloads.
2. Develop with agility — No need to write custom code to poll, filter, and route events; the event router automatically filters and pushes events to consumers. The router removes the need for heavy coordination between producer and consumer services.
3. Audit with ease — An event router acts as a centralized location to audit your application and define policies to restrict who can publish/subscribe and control access to your data. Events can be encrypted in transit and at rest.
4. Cut costs — Event-driven architectures are push-based, so everything happens on-demand. No continuous polling means less network bandwidth, less CPU utilization, less idle fleet capacity, and fewer SSL/TLS handshakes.

The main differences between traditional microservices and event-driven architecture:

1. Synchronous vs Asynchronous — Traditional microservice is synchronous: the request and response happen in the same invocation. With Event Driven, the user gets a confirmation that the message is inserted into SQS, but doesn't get the response from the actual message processing by the Lambda in the same invocation. Instead, the backend Lambda sends a response via websocket APIs, or the user can query the status afterwards.
2. Independent Scaling — With EDA, API Gateway and Lambda/Database can scale independently. Lambda can consume messages at a rate that doesn't overwhelm the database.
3. Built-in Retries — With EDA, retries are built in. With microservices, if Lambda fails, the user needs to send the request again. With EDA, once the message is in SQS, even if Lambda fails, SQS will automatically retry.

Microservice with Event Driven Flow: API Gateway → SQS → Lambda → DynamoDB, with Websocket API for async responses.

Advanced event-driven patterns using multiple AWS services for routing and fan-out:

Flow: API Gateway → SQS 1 → Lambda 1 → EventBridge (Event Store + Router)

EventBridge Rules

Based on values in the message, EventBridge can fire different targets via rules:

• Rule 1 → Step Function
• Rule 2 → Lambda 2
• Rule 3 → SQS 2

SNS Fan-Out

Based on values in the message, SNS can fire different targets using filters:

• Filter 1 → SQS 3
• Filter 2 → Lambda 1 / Lambda 2
• Filter 3 → EKS Application

1. Presentation Layer — Customers consume the application using this layer. Generally, this is where the front end runs (e.g. amazon.com website). Implemented using an external-facing load balancer distributing traffic to VMs (EC2s) running a webserver, with Auto Scaling Groups across multiple Availability Zones.
2. Application Layer — This is where the business logic resides. For example, you browse products on amazon.com, find a product you like, and click "add to cart". The flow comes to the application layer, validates the availability, and creates a cart. Implemented with an internal-facing load balancer and VMs running applications.
3. Database Layer — This is where information is stored: product information, shopping cart, order history, etc. The application layer interacts with this layer for CRUD (Create, Read, Update, Delete) operations. This could be implemented using one or a mix of databases — SQL (e.g. Amazon Aurora) and/or NoSQL (DynamoDB).

Why is this so popular in interviews? This architecture comprises many critical patterns — microservices, load balancing, scaling, performance optimization, high availability, and more. Based on your answers, the interviewer can dig deep and check your understanding of the core concepts.

In a multi-site active-active disaster recovery setup, your application runs simultaneously in two or more AWS regions, each serving live production traffic.

How It Works

• Amazon Route 53 uses latency-based or weighted routing to distribute traffic across regions.
• Each region has a full stack: Load Balancer, compute (EC2/EKS/Lambda), and database.
• Amazon DynamoDB Global Tables or Amazon Aurora Global Database provides multi-region, multi-active database replication with low-latency reads and writes in every region.
• Amazon S3 Cross-Region Replication keeps objects in sync across regions.

Key Characteristics

• RPO ≈ 0 (near-zero data loss with synchronous/asynchronous replication)
• RTO ≈ 0 (no failover needed — both sites are already active)
• Highest cost among DR strategies, but provides the best availability
• Each region can handle 100% of total traffic if the other region goes down

Hybrid cloud connects on-premises data centers with AWS cloud, enabling workloads to run across both environments.

Key AWS Services for Hybrid

• AWS Direct Connect — Dedicated private network connection from on-premises to AWS (bypasses the public internet for consistent performance and lower latency).
• AWS Site-to-Site VPN — Encrypted connection over the public internet between on-premises and AWS VPC. Simpler and cheaper than Direct Connect.
• AWS Outposts — AWS infrastructure and services delivered to your on-premises data center. Run AWS compute, storage, and databases locally with seamless connection to the AWS region.
• AWS Storage Gateway — Bridges on-premises storage with cloud storage (S3, EBS, Glacier). Supports file, volume, and tape gateway modes.
• Amazon EKS Anywhere — Run Kubernetes clusters on-premises using the same EKS tooling and APIs as in the cloud.

Common Use Cases

• Regulatory requirements that mandate certain data stays on-premises
• Gradual cloud migration (lift-and-shift over time)
• Low-latency processing at the edge with cloud bursting for peak demand

Every system design decision involves trade-offs. Understanding these is critical for interviews:

CAP Theorem

A distributed system can only guarantee two of three: Consistency, Availability, Partition Tolerance. Since network partitions are unavoidable, the real choice is between CP (consistent but may be unavailable during partition) and AP (available but may return stale data).

Key Trade-Offs

• Consistency vs Availability — Strong consistency (every read gets latest write) costs availability. Eventual consistency improves availability but users may see stale data temporarily.
• Latency vs Throughput — Optimizing for low latency (fast individual requests) can reduce overall throughput, and vice versa. Batching improves throughput but increases per-request latency.
• Cost vs Performance — Higher performance (more instances, provisioned IOPS, reserved capacity) costs more. Spot instances save money but risk interruption.
• Simplicity vs Scalability — Monolithic architectures are simpler but harder to scale. Microservices scale independently but add operational complexity (networking, observability, deployment).
• SQL vs NoSQL — SQL provides ACID transactions and strong consistency but harder to scale horizontally. NoSQL scales easily and handles unstructured data but sacrifices joins and complex queries.

The three most commonly asked system design patterns in cloud architect interviews:

1. Three-Tier Web Application — Presentation (ALB + EC2 webservers), Application (internal ALB + EC2 app servers), Database (Aurora/DynamoDB). Covers load balancing, auto scaling, multi-AZ, caching (ElastiCache), and CDN (CloudFront). Almost every interview includes a variant of this.
2. Event-Driven Microservices — API Gateway → SQS/SNS/EventBridge → Lambda/EKS consumers → DynamoDB. Demonstrates decoupling, async processing, fan-out patterns, retry/DLQ handling, and independent scaling. Shows you understand modern cloud-native design.
3. Real-time Data Pipeline — Data producers → Amazon Kinesis Data Streams → Lambda/KDA (processing) → S3 (data lake) + DynamoDB (hot data) → Athena/QuickSight (analytics). Demonstrates streaming data ingestion, transformation, storage tiering, and visualization.

Combining three-tier architecture with microservices gives you the best of both worlds — a familiar layered structure with independent deployability:

How They Combine

• Presentation Layer — Frontend served via CloudFront + S3 (static), or EC2/ECS behind an external ALB. This layer only handles UI rendering and API calls.
• Application Layer (Microservices) — Instead of a single monolithic app server, the business logic is split into independent microservices (e.g., Order Service, Payment Service, User Service). Each runs in its own container on EKS or ECS, with its own internal ALB or service mesh routing.
• Database Layer (Database per Service) — Each microservice owns its own database (e.g., Order Service uses DynamoDB, User Service uses Aurora). No shared database — this ensures loose coupling.

Key Differences from Traditional Three-Tier

• Each microservice can be deployed, scaled, and updated independently
• Different technology stacks per service (polyglot architecture)
• Inter-service communication via APIs, message queues, or event bus
• More complex operationally but far more scalable and resilient

Start monolith, evolve to microservices. Many successful companies (Amazon, Netflix) started as monoliths and migrated to microservices when the team size and scaling requirements justified the operational complexity.

Prompt: "Design a global e-commerce platform like Amazon that handles 100K orders/day, serves users in US, Europe, and Asia, and survives a full region failure."

Step 1 — Clarify Requirements

Step 2 — High-Level Architecture

Step 3 — Key Trade-Offs to Discuss

• DynamoDB vs Aurora for orders: Aurora gives SQL joins for complex order queries and strong consistency. DynamoDB Global Tables would give multi-region writes but only eventual consistency — risky for inventory counts.
• Inventory race conditions: Use Aurora's SELECT FOR UPDATE or DynamoDB conditional writes to prevent overselling. Discuss: at 100K orders/day, hot product contention is real.
• Region failover: Route 53 health checks detect region failure (30-60s). Aurora Global Database promotes secondary to primary (~1 min). Cart data in Redis Global Datastore is already replicated.

Prompt: "Design a real-time analytics system that processes 1 million events/second from a mobile app, computes trending content every 5 minutes, and powers a live dashboard."

Step 1 — Requirements

• Throughput: 1M events/second peak (~86B events/day)
• Latency: Dashboard updates within 30 seconds of event generation
• Analytics: Trending content (5-min window), user engagement metrics, real-time anomaly detection
• Retention: Hot data (7 days real-time), warm (90 days queryable), cold (archive)

Step 2 — Architecture Layers

Step 3 — Key Design Decisions

• Kinesis vs MSK: Kinesis for tight AWS integration and serverless consumer (Flink). MSK if team has Kafka expertise or needs Kafka Connect ecosystem.
• Lambda vs Flink for processing: Lambda for simple event-by-event transforms. Flink for windowed aggregations, joins between streams, and complex event processing. At 1M events/s, Flink is the right choice.
• Hot shard prevention: Partition by user_id (high cardinality). If a viral event causes skew, use random partition key suffix with application-level aggregation.

Prompt: "Design a real-time chat system like Slack or WhatsApp for 10M users with group chats, message delivery guarantees, and read receipts."

Step 1 — Requirements

Step 2 — Architecture

Step 3 — Message Delivery Flow

1. User A sends message via WebSocket → WebSocket server receives it
2. Write to DynamoDB (persist) + publish to SQS FIFO (delivery)
3. Lookup User B's WebSocket server in Redis → route message to that server
4. If User B is online → deliver via WebSocket. If offline → send push notification via SNS
5. User B's client sends read receipt → update DynamoDB → notify User A

Prompt: "Design a multi-tenant SaaS platform where enterprise customers demand data isolation, custom domains, and guaranteed performance SLAs."

Tenant Isolation Models

Architecture (Bridge Model — Most Common)

Key Design Challenges

• Noisy neighbor: One tenant's heavy usage impacts others. Solution: per-tenant rate limiting at ALB/API Gateway, resource quotas, and tenant-aware auto-scaling.
• Data migration: Moving a growing tenant from Pool to Bridge (or Bridge to Silo). Design the data model to support promotion without downtime.
• Cost attribution: Track per-tenant resource consumption for usage-based billing. Tag all resources, use CloudWatch metrics with tenant dimension, and generate per-tenant invoices from the CUR.

Scenario-based architecture questions that test your ability to think through trade-offs, not just name services.

1. You're building an e-commerce platform that needs to process orders, send notifications, update inventory, and trigger shipping — all when a customer clicks "Buy." Would you use synchronous microservices or event-driven architecture? Design the flow.
   Answer Guide

   EDA with SNS/SQS fan-out. Order placed → SNS topic → SQS queues for each downstream service. Discuss idempotency, dead-letter queues, and how to handle partial failures.
2. Your monolithic application is deployed on a single EC2 instance. The team wants to move to microservices. What migration strategy would you recommend — big bang rewrite or incremental? Name the specific pattern you'd use.
   Answer Guide

   Strangler Fig pattern. Route traffic through an ALB, gradually extracting services behind new paths. Never rewrite from scratch — it's the riskiest approach.
3. Design a three-tier architecture for a healthcare application that processes 10,000 transactions/second. The data must stay in a single country due to regulations. Walk through each tier and the security boundaries between them.
   Answer Guide

   Web tier (ALB + CloudFront with geo-restriction), App tier (ECS/EKS in private subnet), Data tier (Aurora with encryption). Discuss SGs between tiers, NACLs, and data residency.
4. Explain the CAP theorem. A teammate says "we need strong consistency AND high availability." How do you respond? Give a real-world AWS example of a CP system and an AP system.
   Answer Guide

   You can't have both during a partition. CP example: Aurora (favors consistency, may reject writes during failures). AP example: DynamoDB (eventual consistency, always available).
5. You have a microservice making synchronous REST calls to 5 downstream services. If one downstream service is slow (3-second response), the entire request takes 15 seconds. How do you fix this?
   Answer Guide

   Circuit breaker pattern for failing services, async processing via SQS for non-critical calls, parallel calls where possible, and timeout limits on each call.
6. Design a multi-site active-active architecture for a global SaaS platform serving users in US, Europe, and Asia. How do you handle data consistency across regions?
   Answer Guide

   DynamoDB Global Tables for active-active with eventual consistency, Aurora Global Database for SQL with read replicas per region. Route 53 latency-based routing. Discuss conflict resolution.
7. Your event-driven system is processing 1 million events per day through EventBridge. Some events are being processed out of order and duplicates are appearing. How do you solve both problems?
   Answer Guide

   SQS FIFO for ordering (MessageGroupId), idempotency keys in DynamoDB for deduplication. Discuss the trade-off: FIFO queues have lower throughput (3,000 msg/s with batching).
8. A team proposes using microservices for a 3-person startup building an MVP. What's your recommendation and why?
   Answer Guide

   Start with a well-structured monolith. Microservices add operational complexity (service mesh, distributed tracing, CI/CD per service) that a 3-person team can't sustain. Evolve when team and scale justify it.
9. You need to design a system where reads outnumber writes 100:1 and the data model for reads is very different from writes. What pattern would you recommend?
   Answer Guide

   CQRS (Command Query Responsibility Segregation). Write to Aurora/DynamoDB, project into read-optimized views (ElastiCache, OpenSearch). Events synchronize the two sides.
10. Your distributed order processing system spans 4 microservices. An order requires all 4 to succeed — but if the third one fails after the first two committed, how do you handle the rollback?
    Answer Guide

    Saga pattern with compensating transactions. Each service publishes events — if step 3 fails, trigger compensating actions for steps 1 and 2. Orchestrated (Step Functions) vs choreographed (events).