Design Scalable and Loosely Coupled Architectures

Core Idea

Resilient architecture = components that scale independently and survive the failure of any single component. Test at scale — don't assume performance under load.

Scaling Fundamentals

• Vertical scaling: bigger instance. Horizontal scaling: more instances. Know the cost trade-offs of each.
• Elasticity: automation (launch configs + Auto Scaling) applied to horizontal scaling so capacity tracks demand — demand is rarely linear, so elasticity means scaling both out and in.
• AWS Auto Scaling (cross-service) vs. Amazon EC2 Auto Scaling (EC2-specific) — know the scope difference and the scaling-policy types available for EC2 ASGs.
• Elasticity touches three Well-Architected pillars at once: performance efficiency, operational excellence, cost optimization.

Compute Options — When to Use Which

• Containers, serverless, and EC2 all solve "run my workload," but with different operational and cost profiles — match to workload needs, not default habit.
• For HPC on EC2: instance type + placement group + advanced networking selection matters; consult the Well-Architected HPC lens for depth.

Database & Caching for Scale

• RDS Read Replicas vs. Multi-AZ: Read Replicas give performance (read offload) and availability benefits; Multi-AZ standby gives only high availability — it cannot be read from directly and adds no read performance.
• A Read Replica is not a substitute for caching — it still pays the cost of a DB connection, auth, SQL parsing/optimization, and locking.
• Caching layer options: CloudFront, ElastiCache, DynamoDB Accelerator (DAX).
• RDS Proxy: pools/shares DB connections — critical for Lambda/serverless workloads that open many short-lived connections and would otherwise exhaust DB memory/compute. Reduces Aurora/RDS failover time and can offload credential/auth management to Secrets Manager + IAM.

Purpose-Built Databases

• Relational-database-for-everything doesn't scale past a point. Know when to reach for DynamoDB (NoSQL), Aurora (cloud-native relational), RDS (managed relational), Redshift (data warehouse) instead of a one-size-fits-all RDBMS.

Managed File Transfer

• AWS Transfer Family: managed SFTP/FTPS/FTP without operating your own file-transfer infrastructure — up to 3 AZs, backed by an auto-scaling, redundant fleet. The answer whenever a scenario says "we don't want to manage servers, patching, or one-off provisioning/audit scripts for file transfer."

Service-Oriented / Microservices Patterns

• SOA: reusable components via service interfaces. Microservices: SOA taken further — smaller, simpler components.
• Distributed systems must tolerate network data loss/latency without letting one component's failure cascade.
• Communication patterns: API-driven, event-driven, data streaming.

Serverless Fundamentals

• Defined by: no infra to provision/manage, scales by unit of consumption automatically, pay-for-value billing, built-in availability/fault tolerance.
• API Gateway: scales automatically, minimal management for most use cases.
• Lambda: event-driven compute; understand concurrency and how it governs scaling; pair with API Gateway to expose functions as API methods.
• SQS: very high throughput achieved by scaling producers and consumers horizontally — useful when frontend request rate outpaces backend processing rate.

Decoupling — the Conceptual Core

• Decoupling = components stay autonomous and unaware of each other while contributing to a larger system.
• Synchronous decoupling: both components must be available simultaneously for the interaction to succeed (still "decoupled" in interface, but coupled in availability).
• Asynchronous integration (via SQS/DynamoDB as durable stores): separates request ingestion from request processing — lets frontend and backend scale independently, improves UX for long-running work.
• Decoupling toolkit: Elastic Load Balancing, Amazon EventBridge (for more complex event routing), SQS, API Gateway, DynamoDB, and the broader serverless toolkit.

Exam Angle

Expect: "frontend outpaces backend, how do you decouple?" (SQS/async), "Read Replica vs. Multi-AZ" trick questions, "avoid managing file-transfer infra" (Transfer Family), and "why isn't a Read Replica a cache?" reasoning questions.

Practical Examples

Vertical vs. horizontal, concretely: Your m5.large database is maxing out CPU under load. Vertical scaling: resize to m5.4xlarge overnight (downtime, simple, but has a ceiling and a single point of failure). Horizontal scaling: add read replicas and route read traffic to them (no downtime for the primary, near-infinite read scale, but requires app-level read/write splitting logic).

Elasticity in action: A tax-filing web app gets 100x normal traffic every April 15th and near-zero traffic the rest of the year. An EC2 Auto Scaling group behind an ALB, with a target-tracking policy on RequestCountPerTarget, scales from 2 instances to 40 during the surge and back down to 2 afterward — you only pay for the 40 instances during the hours you actually need them.

Read Replica vs. Multi-AZ, worked scenario: Your RDS PostgreSQL instance is CPU-bound because of heavy reporting queries. Adding a Multi-AZ standby does nothing for this — the standby isn't readable and adds zero query capacity, it only exists for automatic failover. Adding a Read Replica and pointing the reporting queries at it directly reduces load on the primary — that's the actual fix here.

Why a Read Replica isn't a cache: A dashboard hits the same "top 10 products" query 500 times a second. Routing it to a Read Replica still means 500 real SQL round-trips (connection, auth, parse, plan, lock) per second. Putting ElastiCache (Redis) in front with a 60-second TTL means 1 real query per minute and 29,999 fast in-memory hits — this is why caching and read replicas solve different problems even though both "offload reads."

RDS Proxy + Lambda: A serverless API (API Gateway → Lambda → RDS) starts throwing too many connections errors under load because each Lambda invocation can open its own DB connection and Lambda can scale to hundreds of concurrent executions. Fix: put RDS Proxy between Lambda and RDS — Lambda connects to the proxy, the proxy maintains and reuses a small pool of real DB connections.

AWS Transfer Family: A logistics company's partners need to SFTP shipping manifests into an S3 bucket every night, and partners refuse to change their 20-year-old SFTP scripts. Instead of standing up and patching an EC2-based SFTP server, use AWS Transfer Family (SFTP endpoint) backed by S3 — zero servers to manage, and it auto-scales across 3 AZs.

Sync vs. async decoupling: A photo-sharing app resizes uploaded images into 5 thumbnail sizes. Synchronous approach: the upload API call blocks until all 5 resizes finish — slow, and if the resize service is down, uploads fail entirely. Asynchronous approach: the API drops a message on an SQS queue the instant the upload lands in S3, returns success immediately, and a fleet of worker Lambdas processes the resize queue independently — the upload path and the processing path now scale and fail independently of each other.

EventBridge for orchestration: An order in an e-commerce system needs to trigger inventory update, email confirmation, and fraud-check workflows — three unrelated services that shouldn't know about each other. The order service publishes one OrderPlaced event to EventBridge; each downstream service subscribes via its own rule. Adding a fourth consumer later (e.g., analytics) requires zero changes to the order service.