Scaling & Reliability

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.

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.

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.