Blue-Green, Canary, Rolling, Failover, Progressive Delivery, and the traffic controls that make API releases safe
A practical guide to zero-downtime releases, controlled traffic shifting, and resilient gateways
By João Ricardo Dutra••Complete material
Abstract
Modern APIs are expected to evolve continuously without becoming unavailable. That expectation sounds simple, but it changes the entire architecture of software delivery. A is no longer merely the act of replacing one binary with another; it is a controlled movement of traffic, risk, configuration, state, and user exposure. This article explains the principal API strategies and traffic-management patterns used to make that movement safer: ,, Rolling, ,,, weighted traffic splitting, feature flags, , and designs, ,, and related mechanisms. The goal is to give architects, API engineers, DevOps professionals, SREs, and platform teams a mental model that is vendor-neutral yet concrete enough to apply to API gateways, load balancers, Kubernetes ingress and Gateway API resources, service meshes, cloud API management platforms, and traditional reverse proxies.
Contents
34.1 Introduction: from maintenance windows to controlled software delivery
34.2 The conceptual foundation: ,, routing, and
34.3 Core strategies
34.4 Traffic-management patterns used by API gateways
34.5 Reliability mechanisms that make deployments safer
34.6 How the patterns relate to each other
34.7 Choosing the right strategy
34.8 Practical example: a controlled API rollout
34.9 Common mistakes and architectural traps
34.10 Conclusion
Glossary and References
34.1 Introduction: from maintenance windows to controlled software delivery
For much of software history, was treated as an event. A team prepared a , announced a maintenance window, stopped a system, copied new files or installed a new package, restarted services, and hoped that production behaved like the test environment. This model was tolerable when releases were infrequent and applications were relatively isolated. It became increasingly expensive as the web, mobile applications, online banking, e-commerce, cloud services, and API-driven ecosystems made software continuously available and deeply interconnected.
The rise of Continuous Integration and Continuous Delivery changed the question. Instead of asking, "How do we make a large safe every few months?", engineering teams began asking, "How do we make small releases routine, observable, reversible, and low-risk?" The strategies discussed in this article grew from that shift. formalized the idea of keeping two production-capable environments and switching traffic between them. Martin Fowler documented the pattern in 2010 while discussing automated delivery and the emerging practices that would soon be associated with the Continuous Delivery movement [1]. releases later became a widely used method for exposing only a small population to a new version before broad promotion [2].
The metaphor behind "" predates software. Miners historically used canaries as an early warning mechanism for dangerous gases: the bird was exposed before the larger human population. Software borrowed the same risk-management principle. Instead of exposing every customer to a new at once, a small percentage becomes the first cohort. If telemetry shows errors, latency, or business regressions, the rollout can stop before the grows.
As cloud infrastructure, containers, Kubernetes, service meshes, feature flags, and sophisticated API gateways matured, became even more programmable. In 2018, RedMonk analyst James Governor introduced the term "" after observing Microsoft's progressive experimentation practices. The term broadened the discussion beyond automation: software could be deployed first, released later, exposed gradually, and governed by telemetry, user cohorts, experimentation, and automated safety controls [8].
This evolution matters beyond engineering convenience. Reliable reduces outages in systems that society increasingly depends on: payments, government services, transportation, communication, healthcare platforms, education, logistics, and commerce. When an API gateway can shift 5% of traffic to a new implementation, observe the outcome, and reverse the change in seconds, becomes a form of operational risk management. The technology is invisible to most users, but its social value is visible whenever a critical service remains available during change.
For the reader, these patterns provide a vocabulary for reasoning about one of the hardest problems in production engineering: how to change a system while it is being used. By the end of the article, and will no longer look like isolated DevOps buzzwords. They will fit into a broader model that connects , API gateway routing, health checks, ,,, feature flags, version compatibility, and .
34.2 The conceptual foundation: ,, routing, and
Before comparing strategies, it is useful to separate four concepts that are often mixed together.
: placing a version of software or configuration into an environment where it can run.
: making a capability available to users or consumers. A feature may be deployed but not yet released.
: controlling which requests reach which versions, regions, backends, or clusters.
: keeping service available when components, regions, networks, or new releases fail.
These distinctions explain why an API gateway is so important. The gateway sits on the request path and can act as a programmable control point between consumers and backends. Depending on the platform, it can route by percentage, header, identity, path, host, region, API version, subscription, or health. In other words, the gateway can turn a strategy into a traffic policy.
Figure 1 - Separating from is what allows exposure to be controlled independently of infrastructure change.
34.2.1 The risk vocabulary: ,,, and
: the scope of users, requests, services, or regions affected if a change fails.
: returning traffic or software to a previous known-good version.
: fixing the new version and deploying a corrected instead of returning to the old one.
: a deliberate observation period after a rollout step, allowing metrics and delayed failures to surface.
: a probe or signal used to determine whether an instance or backend should receive traffic.
: whether a process is ready to serve production traffic, which is not always equivalent to merely being alive.
: a Service Level Objective, such as a latency or availability target used to judge whether the remains acceptable.
: the amount of unreliability tolerated before an is violated; often used to balance delivery speed and reliability.
: the ability to infer system behavior from signals such as metrics, logs, traces, events, and business indicators.
34.2.2 Stateless traffic is easy; state makes everything harder
diagrams often show a request moving cleanly from version v1 to v2. Real systems carry state. Sessions may be sticky. Gateways may cache responses. OAuth tokens may reference scopes that changed. Databases may migrate schemas. Asynchronous messages may remain in queues. Long-lived connections such as WebSockets may stay attached to an older gateway node. The strategy must therefore be compatible with the state model of the application.
This is why backward compatibility is a hidden prerequisite for safe . During a rolling or , two versions frequently coexist. If v2 writes a database representation that v1 cannot read, a 5% can still corrupt the experience of the 95% of traffic that remains on v1. Techniques such as expand-and-contract database migrations, tolerant readers, versioned events, and additive API changes reduce this risk.
34.3 Core strategies
Table 1 - The six core strategies, their central idea, and the trade-off each one accepts.
Strategy
Main idea
Primary strength
Main trade-off
Two production-capable environments; traffic is switched from the current environment to the new one.
Fast cutover and
Extra infrastructure and state synchronization
A small percentage or cohort receives the new version first; exposure grows progressively.
Small
Needs strong telemetry and routing control
Instances or nodes are replaced gradually.
Efficient use of infrastructure
Old and new versions coexist
/ Big Bang
The old version is stopped and the new one starts afterward.
Operational simplicity
Downtime and large
Successive user or environment rings receive the change in stages.
Controlled organizational exposure
Cohort design and coordination
A broader model combining gradual exposure, feature control, telemetry, and automation.
Fine-grained risk control
More platform and process maturity
34.3.1
keeps two production-capable environments that are as equivalent as practical. The "blue" environment represents the version currently serving production traffic; the "green" environment holds the next version. The team deploys and validates the new in green, then changes a routing layer - commonly a load balancer, DNS control, ingress, service mesh, or API gateway - so that production traffic moves to green. Fowler's description emphasizes the cutover problem: having two environments turns a risky in-place update into a routing decision [1].
For APIs, the pattern is especially attractive when a gateway cluster itself must be upgraded. A new gateway fleet can be built with the same API definitions, policies, certificates, trust stores, identity integrations, plugins, and network routes. After synthetic tests and production-like validation, the external load balancer sends traffic to the green fleet. If the new cluster behaves incorrectly, the organization can redirect traffic to blue while the original environment is still intact.
Before cutover
Clients -> Load Balancer -> BLUE Gateway Cluster -> API Backends
GREEN Gateway Cluster (validated, no production traffic)
After cutover
Clients -> Load Balancer -> GREEN Gateway Cluster -> API Backends
BLUE Gateway Cluster (kept temporarily for rollback)
Figure 2 - Two production-capable environments turn a risky in-place update into a routing decision that can be reversed.
Best fit: high-risk gateway upgrades, infrastructure replacement, configuration migrations, and changes where immediate is valuable.
Watch for: database compatibility, session affinity, caches, certificate differences, environment drift, and the cost of temporarily running duplicate capacity.
34.3.2
A exposes a new to a deliberately limited slice of real production traffic. The initial cohort may be 1%, 5%, 10%, an internal user group, a region, a tenant, or a group of API consumers. If technical and business metrics remain healthy, the share increases. Fowler described the pattern as putting the new version on part of the infrastructure and routing a subset of users to it before broad [2]. Modern cloud gateways often make the idea explicit: Amazon API Gateway, for example, supports settings that divert a configurable percentage of stage traffic to a [6].
The power of is not the percentage itself. It is the feedback loop. A useful compares error rate, p95/p99 latency, timeouts, saturation, authorization failures, dependency errors, and business-level outcomes between baseline and candidate. Mature platforms can automate this comparison and halt or reverse the rollout when thresholds are exceeded.
Figure 3 - The value of a is the feedback loop, not the percentage: baseline and candidate must be measured separately.
Best fit: changes whose behavior can be evaluated safely with a small production cohort and where real traffic provides valuable evidence.
Watch for: low-volume APIs that do not generate enough data, non-idempotent operations, cohort contamination, hidden state coupling, and metrics that aggregate the old and new versions together.
34.3.3
A updates instances incrementally instead of creating a complete parallel environment. If a cluster has six nodes, one or two may be removed from service, updated, health-checked, and returned before the next nodes are replaced. Kubernetes uses this model for Deployments by gradually replacing old Pods with new ones while keeping the application available [4].
Rolling updates are infrastructure-efficient and often the default container-platform strategy. The trade-off is coexistence: during the rollout, v1 and v2 serve traffic at the same time. That demands protocol compatibility, safe database evolution, careful cache behavior, and predictable session handling. A can also be slower than because the fleet must be rolled back node by node.
Figure 4 - Rolling updates trade duplicate infrastructure for a coexistence window in which both versions must remain compatible.
Best fit: stateless services, horizontally scaled gateways, and routine releases where duplicate environments would be unnecessarily expensive.
Watch for: mixed-version behavior, long-lived connections, configuration skew, maxUnavailable/maxSurge choices, and whether checks truly represent production .
34.3.4 / Big Bang
is the simplest strategy conceptually: stop the old version, replace it, then start the new version. Traditional maintenance windows are essentially deployments. The model is still appropriate for some internal systems, development environments, batch workloads, or applications where running two versions is technically impossible.
Its weakness is the size of the commitment. Because there is no overlap, availability is sacrificed during the transition. Because every user sees the new version immediately, the is maximal. For a public API or payment gateway, that is rarely desirable unless a maintenance window is acceptable and explicitly designed into the service contract.
34.3.5
organizes exposure into successive groups rather than only percentages. A common sequence might be: engineering users, internal employees, selected partners, a low-risk customer segment, one region, several regions, and finally the global population. The concept is strongly associated with large-scale software services because user cohorts provide a richer safety boundary than random traffic alone.
For APIs, rings can be mapped to API keys, OAuth client IDs, tenants, subscriptions, regions, products, or contractual partner groups. A gateway can recognize the consumer and route it to a candidate backend. This makes valuable when "who" receives the matters more than "what percentage" receives it.
34.3.6
is the umbrella concept that connects several practices in this article. It extends Continuous Delivery by controlling not only whether software can be deployed, but how exposure expands after . The approach gained a name in 2018 when James Governor described "" after Microsoft's progressive experimentation model [8]. In modern practice, it typically combines staged rollout, feature flags, , experimentation, automated analysis, and clear ownership of decisions.
One of its most important ideas is the separation of from . Code can reach production infrastructure while a feature remains disabled. A can then expose it to employees, then 1% of customers, then 10%, then 50%, and finally everyone. This reduces the organizational pressure to make every production an irreversible "launch moment."
34.4 Traffic-management patterns used by API gateways
strategies describe how versions are introduced. Traffic-management patterns describe how requests are steered while those versions coexist. In API architecture, the two layers are inseparable.
34.4.1 Weighted traffic splitting
sends a defined share of requests to each backend. A gateway might route 95% to v1 and 5% to v2, then change the weights to 80/20, 50/50, and finally 0/100. The Kubernetes Gateway API documents this exact style of gradual splitting between two service versions [5]. Azure API Management backend pools also support weight and priority attributes for distributing requests among backends [7].
34.4.2 Header-, identity-, and tenant-based routing
Percentage routing is not always the safest choice. Gateways can route deterministically using request metadata. An internal testing group might send X--Ring: beta. A partner application may be identified by OAuth client_id. A multi-tenant SaaS platform may expose v2 only to selected tenants. This creates stable cohorts, which makes debugging easier because the same consumer consistently reaches the same .
Typical routing signals include:
HTTP headers and cookies
JWT claims and OAuth client identifiers
API keys, products, or subscriptions
hostnames and URL paths
geography or region
device or application version
source network or internal identity
34.4.3
can use the same routing machinery as , but the objective is different. primarily asks whether a is safe. asks which variant produces a better outcome. An API gateway may route comparable cohorts to two recommendation algorithms, checkout flows, pricing services, or response formats while analytics compare conversion, engagement, latency, or another business metric. Because business experimentation and reliability experimentation can look similar in infrastructure, teams should be explicit about the purpose of the split.
34.4.4 / traffic mirroring
duplicates production requests to a candidate system while the response returned to the user still comes from the established version. This is powerful for validating a new gateway, runtime, search engine, fraud model, or API implementation against realistic traffic without letting the candidate affect user-visible responses.
Client -> API Gateway -> v1 backend -> response returned to client
\--> copy of request -> v2 shadow backend -> response ignored/compared
Figure 5 - Mirroring validates a candidate against real traffic, but duplicated write paths must be isolated or neutralized.
Mirroring requires care with side effects. A duplicated POST /payments request must not create a second real payment. Shadow environments often need request transformation, isolated dependencies, disabled write paths, synthetic accounts, or idempotency controls.
34.4.5 and feature flags
A places code or infrastructure into production before the capability is broadly visible. Feature flags are a common control mechanism. The code may already be deployed, but the feature remains disabled or enabled only for an approved cohort. In API platforms, flags can exist inside the application, in the gateway policy layer, or in a dedicated feature-management service.
This separation of "deploy" and "" is one of the strongest safety improvements in modern delivery. It allows platform teams to validate infrastructure separately from product teams deciding when users should see a feature.
34.4.6 API versioning as a traffic-management tool
Versioning is often discussed as an API design topic, but it is also a -routing mechanism. A gateway can keep /v1/orders mapped to the existing backend while /v2/orders routes to a new implementation. Version selection can also occur through media types, headers, hostnames, or consumer configuration. This allows migration to proceed on a consumer-by-consumer timeline rather than forcing every client to upgrade simultaneously.
34.5 Reliability mechanisms that make deployments safer
34.5.1 Health checks, , and automatic removal
A strategy is only as reliable as its health signals. A process can be "alive" while unable to serve useful traffic. checks should therefore validate the dependencies that determine whether the instance can safely receive requests. Gateways and load balancers use these signals to avoid routing traffic to nodes that are starting, draining, unhealthy, or disconnected from critical dependencies.
34.5.2 and graceful shutdown
When a gateway node is removed during a , it should normally stop accepting new traffic before it is terminated. Existing HTTP keep-alive sessions, streaming requests, WebSockets, or in-flight transactions need time to complete. This period is commonly called , deregistration delay, or graceful shutdown. Without it, a technically "zero-downtime" rollout may still generate avoidable connection resets.
34.5.3 Circuit breakers, retries, and backend pools
Traffic routing and fault handling meet in the backend pool. If a new backend begins failing, a gateway may need to stop routing to it, retry on another instance, or open a to prevent repeated calls to an unhealthy dependency. Cloud API-management platforms increasingly expose these controls as explicit backend policies. Azure API Management, for example, documents backend pools and circuit-breaker configuration as part of backend management [7].
Retries must be designed carefully. Retrying an idempotent GET is usually safer than replaying a payment-creation POST. The gateway needs an idempotency strategy, retry budget, timeout hierarchy, and awareness of whether the downstream operation can be repeated safely.
34.5.4 and
These patterns describe availability topology rather than strategy, but they are closely related to . In architecture, multiple regions or gateway clusters serve production traffic simultaneously. In architecture, a secondary environment remains ready but receives little or no normal traffic. The latter reduces simultaneous complexity; the former can improve capacity usage and regional but requires stronger consistency and routing design.
Figure 6 - Availability topology decides what can actually do: a standby that never serves traffic is rarely proven.
34.5.5
is the controlled redirection of traffic after failure. It may occur between nodes, availability zones, regions, data centers, or backend versions. Mechanisms include global load balancers, DNS , API gateways, ingress controllers, and service meshes. A plan should specify detection time, decision authority, traffic shift, state recovery, and how the organization will fail back after the incident.
34.5.6 vs.
is attractive because it appears to restore a known state. However, database writes, schema changes, messages, and external side effects can make a true reversal impossible. - deploying a corrected version - may be safer when production data has already evolved. Mature delivery pipelines therefore define both paths in advance instead of assuming is always trivial.
34.6 How the patterns relate to each other
Many arguments about strategies are caused by treating patterns as mutually exclusive. In practice, organizations combine them. A environment can use traffic shifting before the final switch. A can be governed by . can use feature flags. regions can each run a independently. The useful question is not "Which single pattern are we using?" but "Which mechanisms control infrastructure replacement, user exposure, traffic routing, and failure recovery?"
Table 2 - The patterns are not rivals; each one answers a different question about controlled change.
Question being solved
Relevant patterns
Infrastructure replacement
, Rolling,
Exposure control
,, Feature Flags,
Request steering
, Header Routing, Identity Routing, API Versioning
Validation
, Health Checks, Automated Analysis,
Failure containment
,,,
Availability topology
,
Operating model
Continuous Delivery,
34.7 Choosing the right strategy
There is no universally best pattern. The correct choice follows from risk, reversibility, state, cost, traffic volume, and the organization's ability to observe the result.
How costly is downtime?: If downtime is unacceptable, becomes less attractive and zero-downtime strategies become important.
How quickly must happen?: can provide very fast traffic reversal when the old environment remains intact.
Can two versions coexist safely?: and Rolling require compatibility between versions, shared data, and dependencies.
Do you have enough traffic for statistical confidence?: A low-volume API may not reveal regressions quickly during a 1% .
Can traffic be segmented deterministically?: If consumers can be identified by tenant, API key, or JWT claim, ring-based rollout may be safer than random percentages.
Is duplicate infrastructure affordable?: may temporarily double compute or gateway capacity.
How mature is ?: Progressive strategies without trustworthy telemetry can create false confidence.
Are operations idempotent?: Retries, mirroring, and can be dangerous for write operations without idempotency controls.
What is the database migration model?: Schema compatibility often determines whether is actually possible.
34.7.1 A practical decision guide
Table 3 - A starting point, not a rule: the scenario determines which mechanism carries the risk.
Scenario
Likely starting point
Gateway platform upgrade with strict requirement
Frequent stateless microservice
High-risk API behavior change with strong telemetry
+
to employees, then partners, then customers
New backend that must be tested with real traffic but cannot affect users
Multi-region disaster recovery
or +
Small internal service where maintenance is acceptable
may be sufficient
34.8 Practical example: a controlled API rollout
Consider a payment API exposed through an API gateway. Version v1 is stable. Version v2 introduces a new fraud-scoring integration and a refactored authorization path. The team does not want to expose every transaction to v2 immediately.
Step 1 - Deploy without broad exposure
Deploy payments-v2 beside payments-v1. Keep v1 as the default backend. Validate startup, certificates, OAuth/JWT validation, downstream connectivity, schemas, and synthetic transactions.
Step 2 - Create a small
Route 5% of eligible traffic to v2. Keep high-risk or unsupported clients pinned to v1 if necessary.
Step 3 - Observe both technical and business signals
Keep the 5% long enough to observe periodic jobs, cache effects, external dependencies, and delayed failures.
Step 5 - Promote gradually
Move to 20%, 50%, and 100% if the candidate remains within agreed thresholds.
Step 6 - Stop or reverse on regression
If error rate or business outcomes degrade, set v2 weight to 0 and investigate. The key is that routing policy contains the .
Figure 7 - Promotion is a policy change, not a redeployment: each step is a decision informed by telemetry.
34.8.1 Example with Kubernetes Gateway API
The following simplified example demonstrates the idea using an HTTPRoute with two backend references. The Gateway API supports weighted traffic splitting between service versions [5].
Promotion becomes a policy change rather than a redeployment. The weights can move from 95/5 to 80/20, then 50/50, and finally 0/100. An equivalent pattern can be implemented in many API gateways, service meshes, ingress controllers, and cloud load-balancing products, although syntax and capabilities vary.
34.8.2 What the example teaches
The most important lesson is that and exposure are separate decisions. Version v2 can exist in production infrastructure before it receives meaningful traffic. The API gateway becomes a valve. determines whether the valve opens further. This is the essence of applied to APIs.
34.9 Common mistakes and architectural traps
Calling any two-server setup "": is about two production-capable environments and controlled cutover, not simply having redundancy.
Using without version-level metrics: If telemetry merges v1 and v2, the can fail while aggregate dashboards still look healthy.
Assuming health means : A process that returns HTTP 200 from /health may still be unable to reach identity providers, databases, or critical backends.
Ignoring database compatibility: The database often makes difficult. Treat schema migration as part of design.
Mirroring unsafe writes: can duplicate side effects unless the candidate is isolated or requests are transformed.
Retrying non-idempotent operations blindly: A retry policy can turn a transient timeout into duplicate business transactions.
Leaving the old environment forever: environments should have an explicit retention and retirement policy; otherwise "temporary capacity" becomes permanent cost and drift.
Choosing percentages without enough traffic: A 1% on a low-volume API may not exercise the failure modes that matter.
Treating strategy as a substitute for testing: Progressive rollout reduces exposure; it does not eliminate the need for functional, integration, security, performance, and testing.
Ignoring configuration and certificates: Gateway incidents often come from policy, route, trust store, certificate, secret, or identity configuration changes rather than application code.
34.10 Conclusion
,,,,, and are different answers to the same operational question: how can a system change while users continue to depend on it? reduces cutover risk by keeping an alternate environment ready. limits the initial . trades duplicate infrastructure for controlled instance-by-instance replacement. adds deliberate user cohorts. turns all of these mechanisms into a broader operating model driven by controlled exposure and feedback.
For APIs, the API gateway is often where these ideas become real. can implement a . Identity-based routing can create rings. Version routing can support long migrations. Traffic mirroring can validate a candidate. Backend health, circuit breakers, , and can prevent problems from becoming service-wide outages. The gateway is therefore not merely a security or protocol component; it can be part of the software delivery control plane.
The strongest organizations do not choose a fashionable pattern and apply it everywhere. They design safety around the specific failure modes of each API: state, side effects, client compatibility, traffic volume, business criticality, , and constraints. In that sense, strategy is architecture. It determines not only how code reaches production, but how much uncertainty the system can absorb while it is changing.
My view is that is the most useful framing for modern API platforms because it treats as a continuous decision rather than a single switch. ,, Rolling, feature flags, traffic splitting, and become tools inside that model. The practical objective is not "zero risk" - which does not exist - but smaller blast radii, faster detection, controlled exposure, and faster recovery. That combination is what turns frequent change from a threat to availability into a routine engineering capability.
Key takeaways
optimizes cutover and .
optimizes blast-radius control.
optimizes infrastructure efficiency.
optimizes cohort-based exposure.
combines exposure control with telemetry and automation.
API gateways make these strategies actionable through routing, health, and policy controls.
Glossary
Table 4 - Essential vocabulary of the chapter.
Term
Definition
A split whose objective is to learn which variant produces a better business outcome, rather than whether a is safe.
Availability topology in which multiple regions or gateway clusters serve production traffic simultaneously.
Availability topology in which a secondary environment remains ready but receives little or no normal traffic.
A deliberate observation period after a rollout step, allowing metrics and delayed failures to surface.
The scope of users, requests, services, or regions affected if a change fails.
Two production-capable environments where traffic is switched from the current environment to the new one.
A exposed first to a small percentage or cohort, with exposure growing progressively.
Control that stops repeated calls to an unhealthy dependency after a failure threshold.
Period in which a node stops accepting new traffic but lets in-flight requests complete before termination.
Placing code or infrastructure into production before the capability is broadly visible.
Placing a version of software or configuration into an environment where it can run.
The amount of unreliability tolerated before an is violated.
The controlled redirection of traffic after failure, between nodes, zones, regions, or backend versions.
Control mechanism that keeps a deployed feature disabled or enabled only for an approved cohort.
A probe or signal used to determine whether an instance or backend should receive traffic.
The ability to infer system behavior from metrics, logs, traces, events, and business indicators.
Operating model that controls how exposure expands after , combining staged rollout, flags, telemetry, and automation.
Whether a process is ready to serve production traffic, which is not always equivalent to merely being alive.
Strategy in which the old version is stopped and the new one starts afterward.
Making a capability available to users or consumers; a feature may be deployed but not yet released.
Keeping service available when components, regions, networks, or new releases fail.
Successive user or environment rings receiving the change in stages.
Fixing the new version and deploying a corrected instead of returning to the old one.
Returning traffic or software to a previous known-good version.
Strategy in which instances or nodes are replaced gradually.
Duplicating production requests to a candidate system while the user still receives the established version's response.
A Service Level Objective, such as a latency or availability target used to judge whether the remains acceptable.
Controlling which requests reach which versions, regions, backends, or clusters.
Sending a defined share of requests to each backend, such as 95% to v1 and 5% to v2.
API gateways, service meshes, ingress controllers, and cloud delivery platforms evolve continuously. Before applying any example, confirm the resource version, the capabilities of your implementation, and the current stability status of each feature in the vendor documentation.
