A ramp deployment gradually shifts a percentage of requests from the old version to the new one — 5%, then 20%, then 50%, then 100% — without caring which user sent which request. It's the load balancer's dumbest, most useful trick: a weighted split at the request level, evaluated fresh every time.

People confuse ramp with canary and A/B, but the distinction matters:

• Canary: a small fleet running new code, watched closely for regressions before scaling up. The fleet is the unit.
• A/B testing: users are bucketed by attribute (user ID hash, cohort) and stay in their bucket. Statistical measurement is the goal.
• Ramp: each request is independently routed by weight. Same user might hit v1 then v2 then v1 again in the same session.

Concrete example. You deploy v2 of a search API behind an Envoy proxy with a weighted cluster: 95% to v1, 5% to v2. A user makes three autocomplete calls in a second — one might hit v2, two hit v1. You watch p99 latency, error rate, and CPU on v2 for 15 minutes. Green? Bump to 20%. Green again? 50%. Then 100%. Red? Set weight back to 0% instantly — no drain, no restart, just a config push.

The trap. Ramp is unsafe for anything with client-side state that assumes server-side compatibility. If v2 changes a response schema, a user bouncing between v1 and v2 will get inconsistent shapes and your frontend will throw. Ramp works cleanly only when every request is independently valid under either version — the same contract discipline you need for rolling deployments, but stricter, because the flip-flopping happens per-request instead of per-connection.

Rule of thumb: the 5-20-50-100 ladder with observation windows scaled to your traffic. At each step, wait long enough to see at least ~10,000 requests hit the new version before promoting. At 1,000 rps and 5% weight, that's ~200 seconds. At 100 rps and 5% weight, it's over half an hour — don't skip the wait just because the dashboard looks fine after two minutes. Small samples hide tail-latency regressions.

Ramp shines for stateless backend services with backward-compatible contracts: search, recommendations, pricing, feature enrichment. It's a poor fit for anything with sticky sessions, WebSocket upgrades, or multi-request workflows where mid-flow version switches corrupt state.