Capacity, availability and staying up under load.
10 items · all topics
How do you architect a highly available, zero-downtime database migration in AWS RDS?
Zero downtime means you never ask for a maintenance window. Bring the new database up next to the old one, keep it in sync while the old one carries all the traffic, check the data constantly, then switch connections over in a few seconds, with a way back you set up before you need it.
Your traffic is spiky and unpredictable during business hours. Design an EC2 Auto Scaling policy that reacts fast without overspending overnight.
Target tracking should be the default scaling policy, since it only needs one metric and handles the math itself. Layer scheduled actions on top for the predictable part of the day, and treat step scaling as the exception for spikes that need a bigger, immediate jump than target tracking gives you.
When would you use EC2 Spot Instances in production, and how do you design a workload to survive interruptions?
Spot is unused EC2 capacity sold at a steep discount, usually 60 to 90 percent off On-Demand, with the trade that AWS can reclaim it with two minutes of warning. It's a good fit for anything stateless, retryable, or checkpointed, and a bad fit for anything that can't tolerate an interruption.
How do you prepare an EC2-based application to fail over to a second AWS region if the primary region has an outage?
Disaster recovery for EC2 is really three separate problems: getting a bootable image into the DR region ahead of time, having a way to launch capacity there fast, and having something outside both regions to redirect traffic. The RTO and RPO you're targeting decide how much of that you keep running warm versus building on demand.
Multi-AZ deployments, read replicas, and Aurora all get mentioned as RDS availability features. What's actually different between them, and when do you use each?
Multi-AZ is a synchronous standby that exists purely for failover, not for serving traffic. A read replica is asynchronous and exists to serve read traffic, with failover as a secondary, slower use. Aurora replaces both mechanisms with a shared, distributed storage layer, which is why an Aurora Replica can do double duty that a standard RDS replica can't.
Compare blue-green, canary, and rolling deployments. When would you choose each?
Rolling replaces instances gradually, blue-green switches all traffic between two full environments at once, and canary sends a small slice of real traffic to the new version while watching metrics. They differ mainly in rollback speed, cost, and how much confidence you gain before full exposure.
When would you scale vertically instead of horizontally?
Go vertical when the bottleneck doesn't split: database buffer cache, cache memory, network bandwidth on one node, a single-threaded lock. Go horizontal when the work partitions cleanly. The real question isn't which is better, it's whether the thing that's saturated can be divided across machines at all.
Two CI pipelines try to create the same Git release tag at the same time. What happens?
The remote accepts one push and rejects the other, because ref updates are atomic. The danger isn't the collision, it's a pipeline that "fixes" the rejection with --force, which silently moves an existing release tag onto a different commit. Serialize releases and protect tags server-side.
Someone moved a production Git tag to a different commit. Why is that dangerous?
A release tag is a promise that a version name means one exact, unchanging set of code. Moving it breaks that promise everywhere at once: rollbacks, audits, incident timelines, and any pipeline that deploys by tag now point somewhere different from what people believe, and some clones won't even notice the change.
Nobody knows which Git branch or tag corresponds to production. How would you fix the release process?
Establish one unbroken chain of identity from commit to running process, then make the pipeline the only way anything reaches production. Start by discovering what's actually deployed today, you can't design a release process around a system you can't describe.