Design Resilient Architectures 2 Flashcards

A financial services company runs a multi-tier application across two Availability Zones. The database tier uses Amazon RDS MySQL with a standby replica. During a planned maintenance window, the primary RDS instance fails over to the standby. Applications experience 30–60 seconds of connection errors. Which approach BEST minimizes this disruption for future failovers?

Answer: Enable RDS Proxy to pool and proxy database connections, absorbing the failover transparently

RDS Proxy maintains a warm pool of connections to the database and handles failover transparently by routing connections to the new primary. Applications connect to the proxy endpoint, which dramatically reduces failover-related connection errors to just a few seconds rather than 30–60 seconds. DynamoDB is a different paradigm requiring application rewrites. A second standby doesn't reduce failover time. Increasing retry intervals just makes applications wait longer, not recover faster.

An e-commerce platform uses Amazon SQS to decouple order processing. During a flash sale, order volume spikes 20x and the processing Lambda function starts throwing throttling errors. Messages pile up in the queue, and some orders are being processed multiple times. Which combination of settings addresses BOTH throttling and duplicate processing?

Answer: Set the SQS visibility timeout higher than the Lambda function's maximum execution time and enable Lambda event source mapping with a batch size of 1

Setting the SQS visibility timeout greater than the Lambda execution time prevents messages from becoming visible again while still being processed, which is the root cause of duplicate processing. When a Lambda function takes longer than the visibility timeout, SQS makes the message visible again, causing another invocation to pick it up. The visibility timeout must exceed the function's maximum runtime. A DLQ with maxReceiveCount of 1 would discard messages after one failure, not solve throttling. FIFO queues help with ordering but not inherently with throttle-caused duplicates. Increasing Lambda timeout alone doesn't fix the visibility/duplicate problem.

A company's web application stores session data in a single Amazon ElastiCache Redis node. If the node fails, all active users are logged out. The team wants to maintain session continuity even during a node failure with minimal changes to the application code. What is the MOST resilient solution?

Answer: Enable Redis cluster mode with automatic failover using a Multi-AZ replication group

A Multi-AZ ElastiCache Redis replication group with automatic failover maintains a standby replica. On primary failure, ElastiCache automatically promotes the replica and updates the DNS endpoint, typically within 1–2 minutes. The application continues to use the same endpoint with minimal code changes. DynamoDB is a valid architectural alternative but requires significant application refactoring. Application-level replication to a second independent node requires complex custom code. RDS is not optimized for session storage and introduces unnecessary latency.

A microservices architecture on Amazon ECS uses an Application Load Balancer. One downstream service is intermittently slow, causing upstream services to exhaust their connection pools while waiting, eventually crashing them in a cascading failure. Which design pattern DIRECTLY addresses this cascade scenario?

Answer: Implement the Circuit Breaker pattern with a timeout and fallback response in the upstream services

The Circuit Breaker pattern detects when a downstream service is failing or slow, and 'opens the circuit' to stop sending requests to it temporarily. This prevents upstream services from blocking on a slow dependency, exhausting their connection pools, and crashing — the classic cascading failure scenario. The circuit breaker provides fast failure and a fallback response, allowing the overall system to remain functional. CloudWatch alarms detect the problem but don't prevent the cascade. API Gateway rate limiting reduces load but doesn't protect upstream callers from blocking. Increasing resources may help the downstream service but doesn't protect upstreams during the slow period.

A company runs a critical batch processing workload on EC2 Spot Instances inside an Auto Scaling group. Jobs take between 45 and 90 minutes to complete. Spot interruptions are terminating instances mid-job, losing all progress. Which strategy provides the BEST balance of cost savings and resilience?

Answer: Use Spot Instances with a diversified instance type pool across multiple AZs, implement checkpointing to S3, and handle the 2-minute interruption notice to save state

The optimal approach combines multiple resilience mechanisms: instance type and AZ diversification reduces the probability of simultaneous interruptions; checkpointing to S3 means a job can resume from its last saved state rather than restart from scratch; and handling the 2-minute interruption notice allows graceful state saving before termination. This preserves cost savings while making the workload interruption-tolerant. On-Demand eliminates savings. 'lowestPrice' in a single AZ maximizes interruption risk. Reserved Instances without checkpointing still loses progress on the Spot portion when interrupted.

A global SaaS application is deployed in us-east-1 and eu-west-1. The company uses Route 53 with a failover routing policy: us-east-1 is PRIMARY and eu-west-1 is SECONDARY. A network event degrades us-east-1 but does NOT fail the Route 53 health check endpoint, so traffic is never routed to eu-west-1. Users in North America experience high latency and errors. How should the health check be redesigned to catch this scenario?

Answer: Use a Route 53 calculated health check that combines the HTTP endpoint check with a CloudWatch alarm monitoring application-level error rates and latency

A calculated health check lets you combine multiple health signals. By integrating a CloudWatch alarm that monitors application-level metrics (5xx error rates, p99 latency) with the basic HTTP endpoint check, the health check fails when the application is degraded even if the endpoint technically responds. This catches 'brown-out' scenarios where the service is reachable but performing poorly. TCP checks are simpler and less informative than HTTP. Reducing the check interval speeds detection but doesn't fix the fundamental problem that the check measures the wrong thing. A second subnet check still only measures reachability, not application quality.