API gateway with canary releases

I would put a weighted split in the gateway route, starting the canary at a small percentage and hashing on user ID so each user sticks to one version. Every request is tagged with route and version in metrics. A rollout controller like Argo Rollouts runs analysis at each step, comparing canary error rate and p99 latency against stable, not against a fixed number, and requiring a minimum request count before deciding. If healthy, it raises the weight in stages up to full cutover. If any check fails, it sets the canary weight to zero through the Git-backed route config and alerts the team. I would also insist on backward-compatible schema changes, because traffic rollback is useless if the data has already moved forward.

The client opens an HTTPS connection and the edge terminates TLS with an automatically rotated certificate. The JWT verifier checks signature, expiry, issuer and audience against cached JWKS keys. Any failure returns 401 and the request goes no further. Next, a token-bucket check in Redis, keyed by client, API key or route, returns 429 with Retry-After if the quota is exhausted. The route engine matches host, path, method and headers, applies transformations and resolves healthy endpoints from the registry. The canary splitter hashes a stable key such as user ID to pick stable or canary. The call then goes through a circuit breaker, timeout and bounded retries, optionally over mTLS. Metrics, traces and logs tagged with route and version are emitted, and the rollout controller uses them to decide the next weight.

Cheap, protective checks should run first and expensive or upstream-touching work last. A coarse per-IP limit can run even before authentication, so a flood of junk tokens cannot burn CPU on signature checks. Then JWT verification runs, so no unauthenticated request reaches routing or upstreams. After that comes the per-client quota, which needs the authenticated client ID as its key. Routing, transformation and canary splitting follow, and resilience controls wrap the actual upstream call. Observability wraps everything so that rejected requests are counted too. If you rate-limit by client ID before authenticating, an attacker can forge IDs and exhaust another tenant's quota. If you route before authenticating, you leak which paths exist and risk forwarding unauthenticated calls.

The gateway caches the JWKS document and selects a key using the kid in the token header. During rotation, the identity provider publishes the new key alongside the old one before it starts signing with it. Gateways refresh the cache on a schedule, so they usually learn the new key early. If a token arrives with an unknown kid, the gateway triggers a refresh, rate-limited so attackers cannot force constant fetches, and then retries the lookup once. If the kid is still unknown, it returns 401. The old key stays published until all tokens signed with it have expired. I would also alert on JWKS fetch failures, because a stale cache is the usual cause of a sudden spike in 401s.

Each bucket is a Redis key holding the token count and the last refill timestamp. The read-refill-decrement sequence must be atomic, or two gateway nodes can both read one remaining token and both allow the request. I would run it as a Lua script, which Redis executes atomically. The script computes tokens refilled since the last timestamp, caps them at bucket capacity, decrements if at least one token is available, and sets a TTL so idle keys expire. To avoid clock skew between gateway nodes, use Redis server time inside the script. The script returns remaining tokens and the wait time, which feeds the Retry-After header. For scale, shard keys across a Redis cluster. The key includes the client and route, so each check stays on a single shard.

It depends on what the limit protects. For general fairness quotas I usually fail open with a guard: each gateway node falls back to a local in-memory token bucket set to roughly the global limit divided by the node count. A Redis outage then does not become a full API outage, but abuse is still roughly bounded. For limits that protect something fragile or costly, such as an OTP-sending endpoint or a paid third-party API, I would fail closed, because over-delivery there causes real harm. Authentication is different and always fails closed. The Redis call needs a tight timeout so a slow Redis does not add latency to every request. Emit a metric whenever fallback mode is active.

Core gates are the 5xx error rate, p95 and p99 latency, and sometimes saturation signals such as CPU or a business metric like checkout success. Each is compared between canary and stable over the same window, not against a historical baseline, so traffic changes affect both groups equally. At 1 percent weight the sample is small, so one error can look like a large rate. I would require a minimum request count before evaluating, use statistical comparison rather than a raw threshold, and extend the soak time at low weights. Insufficient data counts as not healthy: hold the weight, never promote. Hard failures such as crash loops or a very high error rate should still trigger immediate rollback without waiting for significance.

Both versions share the database for the whole rollout, so the schema must work with both. I use the expand-and-contract pattern. First, deploy an additive change, such as a new nullable column or table, that the old code ignores. Then canary the new code, which writes in a way the old version still tolerates, often writing both old and new fields. Only after full cutover, with no chance of rolling back, do you run the contract step that drops the old column. Destructive migrations and data rewrites must never ship in the same release as the code canary. Otherwise setting the weight to zero cannot undo the damage. Routing rollback is instant, but data rollback is not.

First, the gateway strips any identity headers the client sent, such as X-User-Id or X-Roles. Otherwise a client could inject them and impersonate someone. Then it either forwards the original validated token or injects trusted headers derived from the verified claims. Services should accept those headers only over mTLS from the gateway's identity, so nobody can bypass the gateway and send them directly. A stronger option is exchanging the token for a short-lived internal token scoped to the target service. Services can then verify it themselves and enforce fine-grained authorisation. The gateway handles coarse authentication and maybe scope checks, but object-level authorisation, such as whether this user owns this order, stays in the service.

Both, with different jobs. The gateway does coarse authentication: it validates the JWT signature against cached JWKS, checks expiry, issuer and audience, and rejects bad tokens before they consume backend capacity. It then forwards verified claims to services. Services still do authorisation, meaning whether this user may act on this specific resource, because only they understand the domain. For internal traffic I would use mTLS through a service mesh so a compromised pod cannot simply bypass the gateway and call services directly. Relying only on the gateway creates a hard shell with a soft interior, which is a weak zero-trust posture.

Run the gateway as stateless replicas across availability zones behind a layer-4 load balancer, and autoscale on CPU and connections. Keep state out of the request path: routes come from a control plane pushed to data-plane proxies, so the control plane going down does not stop traffic. Rate limiting depends on Redis, so I add a local limiter fallback and short timeouts on the Redis call. JWT verification is local with cached keys, avoiding a per-request IdP call. I keep business logic out of the gateway and measure gateway-added latency separately so regressions in plugins are visible quickly.

Token validation keeps working, because JWT verification is local: the gateway only needs the cached public keys, not a call per request. Users with valid, unexpired tokens keep working. New logins and token refreshes fail, so impact grows as tokens expire. That is why short token lifetimes are a trade-off against outage tolerance. The gateway should keep serving from the last good JWKS cache rather than clearing it when a refresh fails. It should still fail closed for unknown key IDs, because it cannot prove such a token is valid. If some routes use online token introspection, those routes need an explicit decision. Usually that means failing closed for sensitive operations, with alerting and a runbook.

The main defence is short access-token lifetimes, often minutes, paired with refresh tokens that the identity provider can revoke centrally. Then a stolen access token is only useful for a short time. For faster revocation, the gateway can check a denylist of revoked token IDs (jti) or revoked sessions, held in Redis or pushed to gateway memory. The list stays small because entries can expire when the original token would have expired. For high-risk routes such as payments or admin actions, the gateway can call the provider's introspection endpoint, accepting the extra latency and the dependency. Revocation is a sliding scale: the more real-time it is, the more state and latency you take on.

I would state assumptions explicitly. Suppose peak is 20,000 requests per second and a load test shows one gateway instance handles a few thousand RPS at target CPU with JWT verification and TLS. Divide peak by the tested per-node throughput, then add headroom so the fleet survives losing a zone and absorbs bursts. Typically that means running at 50 to 60 percent utilisation and spreading across at least three zones. Redis load is roughly one script call per rate-limited request, so about 20,000 operations per second, sized with cluster shards and replicas. Log volume is requests per second times average log size, which often drives cost more than compute. The key point is to measure per-node throughput with real filters rather than quoting vendor numbers.

A typical schedule moves through small steps such as 1, 5, 25, 50 and then 100 percent, with a soak period and SLO analysis at each step. Early steps limit the blast radius, and later steps check behaviour under real load, such as cache pressure or connection pools. Per service, I would configure the step weights, soak durations, minimum sample sizes, which metrics gate promotion with what thresholds, and whether a manual approval is needed before full cutover. Critical services like payments might use longer soaks or require business-metric checks. The schedule lives in version control next to the deployment manifest. Every weight change the controller makes is recorded with its reason, so incidents can be traced back to rollout decisions.

Separate the control plane from the data plane. The control plane stores versioned configuration, validates it, and pushes it to gateway nodes, for example over an xDS-style streaming API. Nodes apply each config atomically: an update either fully applies or is rejected, never half-applied. If the control plane goes down, nodes keep serving with the last known good config. Every config version is recorded, so we can report which nodes run which version and can roll back. Weight changes are small and frequent, so they must propagate within seconds. Riskier changes such as new routes or auth policies should themselves go out gradually, to a subset of gateway nodes first.

The new weight propagates to the gateway nodes, and from then on new requests hash to stable. Requests already in flight to canary pods normally complete, unless the canary is so broken that they time out or trip the breaker. Long-lived connections such as HTTP/2 streams, gRPC channels or WebSockets are a special case: they may stay on canary until they close, so the gateway or the canary pods should drain them gracefully within a deadline. Stable must have enough capacity to take back the canary's share at once, so we keep stable scaled to full traffic during the rollout. Finally, the controller records the rollback event, alerts the owning team and blocks automatic re-promotion until a human acts.

Use several controls together. First, a small retry cap, often one or two attempts, with exponential backoff and jitter so clients don't retry in sync. Second, a retry budget: retries may add only a small percentage on top of normal request volume to an upstream, so when failures are widespread, retries stop instead of multiplying load. Third, the circuit breaker opens and fails fast when error rates cross a threshold. Fourth, retry at one layer only. If client, gateway and service mesh each retry three times, one failure can turn into dozens of calls. Finally, honour Retry-After and treat 429 and 503 from upstreams as signals to back off, not to retry harder.

Start from an end-to-end latency budget for the route, and propagate it as a deadline. The gateway sets the overall request timeout, and each attempt gets a per-try timeout small enough that a retry still fits within the overall budget. The gateway passes the remaining time downstream, for example as a gRPC deadline or a header, so services can stop work the caller has already given up on. Inner timeouts must be shorter than outer ones. Otherwise the gateway times out while backends keep working uselessly. Base values on measured p99 latency plus margin, not guesses, and review them per route: a report export and a profile fetch need very different budgets.

Terminating TLS at the edge lets the gateway inspect headers and tokens, but traffic inside the network would otherwise travel in plaintext. That exposes tokens and personal data to anyone with internal network access, and a compromised pod could pretend to be the gateway. mTLS encrypts each hop and authenticates both sides: the upstream knows the caller really is the gateway, and the gateway knows it reached the real service. Workload identities, often SPIFFE-style IDs, come from short-lived certificates issued and rotated automatically by an internal CA or a mesh. This supports zero-trust: services can enforce that only the gateway, or specific callers, may reach them. The cost is handshake CPU and certificate management, which connection reuse and automation keep manageable.

Make authentication deny-by-default. Every route requires a valid token unless it is explicitly listed as public, such as health checks or login, and that list is reviewed in code. Any error in the auth filter, such as a malformed token, missing JWKS or an internal exception, returns 401 or 503, never a pass-through. Config validation rejects any route definition that has no auth policy. Network policy ensures upstreams accept traffic only from the gateway over mTLS, so bypassing the gateway does not work. Continuous tests call each route without a token and with expired or tampered tokens, and assert 401. A metric counts upstream requests without verified identity, and any non-zero value should page someone.

Tag request metrics with a small set of bounded labels: route template (not the raw path with IDs), method, status class, upstream service and version (stable or canary, or a release ID). These have few distinct values, so the time-series count stays manageable. Never use user ID, request ID or raw URL as metric labels. Those belong in traces and logs, which are designed for high-cardinality data. Use histograms for latency so percentiles can be aggregated across nodes. With OpenTelemetry, set the version as a resource or span attribute so traces can be filtered by version too. Exemplars linking a metric bucket to a trace help engineers jump from a canary latency spike to concrete slow requests.

The gateway sees every request, so its logs can easily capture tokens, API keys, phone numbers, emails or payment data in headers, query strings and bodies. Under India's Digital Personal Data Protection Act, and under general good practice, you should collect only what is needed and protect it. Concretely: never log Authorization headers or full tokens, redact known sensitive fields and query parameters, avoid logging bodies by default, and hash or pseudonymise user IDs where that is enough. Restrict log access by role, encrypt logs at rest, and set retention periods. Sampling can cut volume, but errors and auth failures should be kept for security investigations.

Blue-green runs two full environments and switches all traffic from one to the other at once. Rollback is a fast switch back, but every user is exposed the moment you switch, and you pay for double capacity during the release. A canary exposes a small, growing share of users and uses real traffic data to decide, so the blast radius is smaller and risks only visible under load surface gradually. The cost is a longer rollout and more tooling. This design combines them: canary steps up to full weight, then a blue-green style cutover makes the new version the stable baseline, keeping the old one briefly for quick rollback. Pure blue-green suits releases where mixed versions cannot coexist, such as incompatible protocol changes.

Missing or stale data must never count as healthy. If metrics for a step are absent, delayed past a threshold or below the minimum sample size, the controller pauses at the current weight and alerts. It must not promote. If data stays missing for too long, rolling back to zero is the safer default, because nobody can see what the canary is doing. The controller should keep its state durably, such as current step, weights and decision history, so a restart resumes correctly instead of resetting or skipping steps. It is also worth having an independent safety net: gateway-local outlier detection and circuit breakers that react to a broken canary even if the central controller is down.

Use another stable identifier. Common choices are a first-party cookie or device ID issued on the first request, or a session ID. The gateway hashes that value the same way it hashes user IDs. If there is no identifier at all, it can assign a version randomly and then set a cookie recording the assignment, so later requests stick. Client IP is a weak fallback because many users share IPs behind carrier-grade NAT, which is common on Indian mobile networks, and an IP can change mid-session. When a user logs in, you may switch to hashing the user ID. Accept that a user could switch version once at that moment, or keep the cookie key for the rest of the session.

The gateway cannot canary itself through its own splitter, so the split happens one layer up: at the load balancer or DNS layer in front of the gateway fleet. Deploy the new gateway build to a small set of nodes, or one zone, and shift a small share of load balancer traffic to them. Watch the same signals: error rates, latency, 401 and 429 rates, and CPU. A sudden change in 401s often means an auth regression. Config changes, which are more frequent than binary changes, go through validation, staged rollout to node subsets and automatic revert. Keep the previous build ready, because a gateway outage takes down every API.

Certificates are issued by a public CA using ACME, or by a certificate manager for internal names, and renewed well before expiry. A renewal window around two-thirds of the lifetime gives time to retry failures. The new certificate and key go into a secret store, and gateway nodes hot-reload them: new handshakes use the new certificate, while existing connections continue until they close naturally. No restart is needed. Monitoring tracks days-to-expiry on every served certificate and alerts long before the deadline, because expired certificates remain a common cause of outages. Private keys never go into images or logs, and access to them is tightly restricted.

It combines the service registry with its own observations. The registry, for example Kubernetes endpoints or Consul, lists instances that pass readiness checks, so instances that are starting or draining are excluded. That is active health checking. The gateway also does passive outlier detection: if an instance returns several consecutive 5xx errors or connection failures, the gateway temporarily ejects it from its load-balancing pool and lets it back in after a cooldown. A cap on the percentage of hosts that can be ejected prevents one bad signal from emptying the pool. The canary and stable versions are separate endpoint groups, so an unhealthy canary pool does not affect stable selection.

Each region runs its own gateway fleet, and clients reach the nearest healthy region through geo-DNS or anycast. Rate limiting gets harder: a truly global limit needs cross-region coordination, which adds latency to every request. Most designs keep a Redis per region and split each client's quota across regions, either statically or adjusted periodically based on observed traffic. They accept that a client can briefly exceed the global limit by a small margin. For strict limits, such as billing-related quotas, a periodic asynchronous sync of usage counters keeps things close without blocking requests. Canary rollouts usually go one region at a time, which adds another safety boundary.

The gateway handles north-south traffic, meaning external clients coming in. It owns TLS for public domains, end-user authentication, API keys, per-client quotas, request transformation and public API versioning. A mesh handles east-west traffic between services. It provides service-to-service mTLS, retries, timeouts, circuit breaking and traffic splitting for internal calls. They overlap on resilience and canary splitting. The rule I use is to put each control at one layer per hop, so retries and timeouts are not stacked. Many platforms use the same proxy technology for both, which keeps configuration concepts consistent. If the platform has no mesh, the gateway's canary splitting covers only the externally facing service, and internal dependencies need their own rollout approach.

The gateway splitter does not apply there, because consumers pull messages and are not routed requests. Options include running a small number of canary consumer instances in the same consumer group, so they naturally take a share of partitions roughly in proportion to their count. Or you can route a slice of messages, keyed by user ID, to a separate canary topic. Messages produced by the new version must stay compatible with old consumers, so schema compatibility rules in a schema registry matter. Compare error rates, processing lag and dead-letter counts by version, the same way as the HTTP SLOs. Rollback means scaling canary consumers to zero. Messages already processed incorrectly may need a replay plan.

Treat gateway configuration as code. It lives in version control, goes through review, and runs through validation in CI: schema checks, conflict detection for overlapping routes, and a check that every route has an auth policy. Run automated tests that replay sample requests against the new config and assert the expected upstream, status codes and headers. Deploy config progressively to a subset of gateway nodes, watching error and 404 rates, before going fleet-wide. Keep the last known good version so revert is one action and nodes can fall back on their own if a config fails to load. Audit logs record who changed what, which matters because a gateway config change can open access to everything.

1. AIdempotent requests such as GET, or writes carrying an idempotency keyCorrect answer
2. BNone, because retries always cause retry storms
3. CAll requests, as long as there are at most three retries
4. DOnly POST requests, because they carry a body

Why: Retrying a non-idempotent write may apply it twice; idempotent methods or idempotency keys make repeats harmless, and retry budgets keep storms in check.

1. A429 Too Many Requests
2. B403 Forbidden
3. C401 UnauthorizedCorrect answer
4. D400 Bad Request

Why: An expired token means the caller is not authenticated, which is signalled with 401. 403 is for authenticated callers who lack permission.

1. ARetry-AfterCorrect answer
2. BCache-Control
3. CWWW-Authenticate
4. DLocation

Why: Retry-After tells the client how long to wait before retrying, which helps well-behaved clients back off.

1. ACONNECT
2. BPOST
3. CPATCH
4. DPUTCorrect answer

Why: HTTP semantics define PUT as idempotent: repeating it produces the same state. POST and PATCH are not guaranteed to be idempotent.

1. ADisable authentication for the canary
2. BPromote, because no errors were seen
3. CHold or extend the step and never treat missing data as healthyCorrect answer
4. DDelete the stable version

Why: Absence of evidence is not evidence of health. The controller must wait for a sufficient sample, or roll back if data stays unavailable.

1. AExpand-and-contract migrations, with additive changes first and removals only after full cutoverCorrect answer
2. BGive the canary its own copy of production data
3. CLock the database during canary
4. DDrop old columns in the same release

Why: Additive changes keep the schema compatible with both versions, so traffic rollback stays safe. Destructive changes wait until rollback is no longer needed.

1. AStrip it and set identity headers only from verified token claimsCorrect answer
2. BUse it as the rate-limit key before authentication
3. CLog it as the trusted identity
4. DForward it unchanged

Why: Client-supplied identity headers can be forged. Only identity derived from a verified token should be passed upstream.

1. AIt removes the need for per-version metrics
2. BHashing is faster to compute than a random number
3. CIt keeps each user on one version, avoiding inconsistent behaviour across requestsCorrect answer
4. DIt guarantees exactly the configured percentage on every request

Why: Consistent hashing gives session stickiness, so a user does not alternate between old and new behaviour, and canary metrics reflect coherent user journeys.

1. A404 Not Found
2. B403 ForbiddenCorrect answer
3. C500 Internal Server Error
4. D401 Unauthorized

Why: The identity is proven but not allowed to do this action, which is an authorisation failure and maps to 403.

1. AkidCorrect answer
2. Bsub
3. Caud
4. Djti

Why: The kid (key ID) header identifies which key in the JWKS signed the token. That makes key rotation possible with several keys published at once.

1. AThe long-term average rate
2. BThe maximum burst allowed at onceCorrect answer
3. CThe TTL of the Redis key
4. DThe number of Redis shards

Why: Capacity caps how many tokens can accumulate, which sets the largest burst. The refill rate sets the sustained average.

1. AUse client-side locking in each gateway
2. BRun the logic in a Lua script executed by RedisCorrect answer
3. CRead with GET and write with SET separately
4. DRely on Redis persistence (AOF)

Why: Redis runs a Lua script atomically, so concurrent nodes cannot both consume the same last token.

1. AIt makes each user's assignment deterministic, so they consistently see one versionCorrect answer
2. BIt guarantees exactly equal latency on both versions
3. CIt removes the need for metrics
4. DIt encrypts the user ID

Why: Deterministic hashing maps the same key to the same bucket every time. Users get a consistent experience, and per-user effects can be attributed to a version.

1. AHave the client send an idempotency key that the server deduplicatesCorrect answer
2. BIncrease the gateway timeout
3. CDisable the circuit breaker
4. DSend it over HTTP/2

Why: An idempotency key lets the server detect a repeated request and return the original result instead of performing the action twice.

1. AAll requests are rejected permanently
2. BA limited number of trial requests go through to test whether the upstream has recoveredCorrect answer
3. CAll requests pass and failures are ignored
4. DTraffic is sent only to the canary

Why: Half-open sends a few probe requests. Success closes the breaker, and failure reopens it.

1. ATo avoid many clients retrying at the same instant and overwhelming the upstreamCorrect answer
2. BTo encrypt retry traffic
3. CTo bypass rate limits
4. DTo make retries faster

Why: Randomising retry delays spreads retries over time and prevents synchronised waves of load.

1. AThe number of canary steps
2. BThe JWT expiry window
3. CA cap on retries as a fraction of normal request volume to an upstreamCorrect answer
4. DMoney allotted for cloud retries

Why: A retry budget limits extra load from retries, so widespread failures don't multiply traffic into a retry storm.

1. AHistorical data is always deleted
2. BStable has no metrics
3. CIt uses less storage
4. DBoth groups see the same traffic mix and conditions, so differences reflect the versionCorrect answer

Why: Running the comparison at the same time controls for time-of-day, seasonality and incidents that affect both versions equally.

1. AAccept it if the expiry is valid
2. BPin the allowed algorithms per issuer and reject anything elseCorrect answer
3. CConvert it to RS256
4. DAsk the client to resend

Why: Allowing only expected algorithms prevents unsigned tokens and algorithm-confusion attacks.

1. ACompression
2. BThe upstream also authenticates the gateway through its client certificateCorrect answer
3. CAutomatic rate limiting
4. DJWT issuance

Why: In mutual TLS both sides present certificates, so each party verifies the other's identity as well as encrypting traffic.

1. AVersion (stable or canary)
2. BUser IDCorrect answer
3. CStatus class
4. DRoute template

Why: User IDs have huge numbers of distinct values, which creates an explosion of time series. That data belongs in traces and logs.

1. A5,000
2. B10,000
3. C100
4. D1,000Correct answer

Why: 5 percent of 20,000 is 1,000. Hash-based splitting approximates the weight over a large user population.

1. AContinue serving with the last known good configurationCorrect answer
2. BRoute everything to canary
3. CDisable authentication
4. DStop serving traffic

Why: Separating the planes means a control-plane outage only freezes config changes. Live traffic keeps flowing.

1. ATo let downstream services stop work once the caller's time budget is used upCorrect answer
2. BTo replace authentication
3. CTo raise the rate limit
4. DTo extend timeouts indefinitely

Why: Passing the remaining time lets each hop give up promptly, avoiding wasted work on requests the client has already abandoned.

1. ANetwork policy plus mTLS so upstreams accept only the gateway's identityCorrect answer
2. BLonger JWT lifetimes
3. CDisabling logs
4. DRelying on obscure service hostnames

Why: Enforcing at the network and identity layer means direct calls that skip the gateway are rejected, which gives defence in depth.

1. AFails fast for calls to the unhealthy upstream until a probe succeedsCorrect answer
2. BEncrypts traffic between the gateway and the upstream
3. CDoubles the retry count to recover faster
4. DMoves all traffic to the canary version

Why: An open breaker stops sending requests to a failing upstream and returns errors or fallbacks immediately, then lets trial requests through in half-open state to test recovery.

1. AIts counter never resets
2. BIt must authenticate twice
3. CIt can send up to about 200 requests in a short span across two windowsCorrect answer
4. DIt is blocked for two full minutes

Why: A client can use the full quota at the end of one window and again at the start of the next, roughly doubling the burst. Token buckets and sliding windows smooth this out.

1. ATo let tokens live forever
2. BTo tolerate small clock differences between the issuer and the gatewayCorrect answer
3. CTo speed up signature checks
4. DTo avoid fetching JWKS

Why: Servers' clocks drift slightly. A small leeway prevents valid tokens from being rejected at the boundary while keeping expiry meaningful.

1. AThe gateway cannot read headers
2. BThe gateway sees plaintext requests, so internal hops need re-encryption to stay protectedCorrect answer
3. CClients no longer need certificates validated
4. DRate limiting stops working

Why: Termination decrypts traffic at the gateway. Without re-encryption, data travels internally in plaintext.

1. AScans code for vulnerabilities
2. BTemporarily ejects upstream hosts that show repeated errors from the load-balancing poolCorrect answer
3. CBlocks users with unusual IPs
4. DRotates TLS certificates

Why: Outlier detection watches real responses and removes misbehaving instances for a cooldown, complementing registry health checks.

1. ABlue-green shifts all traffic between two full environments at onceCorrect answer
2. BBlue-green never allows rollback
3. CBlue-green requires user-ID hashing
4. DBlue-green only works with queues

Why: Blue-green is a full switch between environments. A canary gradually raises a share of traffic while measuring health.

1. AThey are converted to HTTP/1.0
2. BThey bypass authentication
3. CThey move to the new version immediately
4. DThey stay on their current version until they close or are drainedCorrect answer

Why: Weights apply when a connection is established, so long-lived connections need explicit draining to fully shift traffic.

1. ACanary version
2. BRoute template only
3. CUser ID from the token
4. DClient IP address, possibly combined with other signalsCorrect answer

Why: Without a verified identity, client IP is the usual key. Shared IPs behind NAT mean it should be combined with other signals or set generously.