# Hot deploy & cache — Use case > Push a definition. Watch the gateway pick it up — no restart, no warm-up, no traffic loss. Backed by a distributed cache that survives reschedules. *Platform teams · Runtime · For platform teams* ## Deploy at lunch. Don't tell ops. Every definition, policy, and transform hot-loads on the running gateway. No restarts, no rolling reboots, no lost in-flight requests — and the distributed cache survives every pod reschedule. [Request a demo](https://calendly.com/apinizer/15min) · [Read the docs](https://apinizer.com/developers/docs) --- ## The problem *The problem* ### Most gateways pretend a deploy is a small thing. It isn't. A redeploy means a rolling restart. A rolling restart means warm caches go cold, connection pools rebuild, JWKs re-fetch, and tail latency spikes for ten minutes. Engineers learn to deploy on Fridays at 04:00 — which means they don't deploy. Apinizer's runtime treats a deploy as a config refresh: the gateway picks up the new shape in place, and the distributed cache holds steady. --- ## At a glance - **0** — restarts (per definition apply) - **<200ms** — propagation (across Workers) - **0** — in-flight requests lost --- ## Capabilities ### Zero-restart deploys Apply a definition — the gateway picks up the new shape in place. In-flight requests finish on the old shape; new ones land on the new. ### Distributed cache Hazelcast-backed cache shared across every Worker. Survives reschedules; invalidations propagate cluster-wide in under a second. ### Coordinated invalidation Bust a cache key once; every Worker drops it. No more 'one node has the stale value' tickets. ### Per-key TTLs Cache strategies per endpoint, per consumer, per response variant. Fast lanes for hot data, conservative TTLs for sensitive lookups. ### Pre-warmed pools Connection pools, JWK sets, OAuth introspection caches — all kept warm across deploys. New pods inherit warm state from peers. ### Cache analytics Hit rate, miss rate, eviction reason — per endpoint, per region. Tune what's worth caching before it becomes a cost problem. --- ## Real-world examples ### Retail **Scenario:** Istanbul e-commerce ships 40 policy changes during Black Friday **Outcome:** Rate limits, headers, A/B routes — all hot-deployed during peak. Zero rolling restarts, zero abandoned carts attributable to platform. **Metric:** 40 deploys, 0 restarts ### Banking **Scenario:** Frankfurt private bank refreshes JWKs without a maintenance window **Outcome:** Identity provider rotates keys. The gateway picks up the new JWKs in place; in-flight tokens validate on the old key, new ones on the new. ### Public transit **Scenario:** Amsterdam transit authority caches schedule API across 6 Workers **Outcome:** 97% cache hit rate on schedule lookups during peak commute. Invalidation on disruption fans out in 400ms. **Metric:** 97% hit rate ### Insurance **Scenario:** Stockholm insurer A/B-tests a new pricing endpoint mid-day **Outcome:** Hot-deploy carves 5% of traffic to the new shape. Telemetry confirms; the next apply moves the cutover to 100%. No deploy window negotiated. ### Banking **Scenario:** Warsaw bank serves loan calculator from cache during marketing campaign **Outcome:** Calculator API absorbs 12k RPS during a TV ad. Backend never sees more than 200 RPS; cache shoulders the rest with per-input TTLs. **Metric:** 60× backend reduction ### Telecom **Scenario:** Prague carrier ships pod reschedules without losing cache warmth **Outcome:** Hazelcast keeps state across the cluster. When a pod reschedules, the new pod inherits the cache from peers — no cold-start storm to the backend. ### Media **Scenario:** Milan publisher invalidates 4M cache keys per breaking story **Outcome:** Editorial publishes; the gateway invalidates affected keys cluster-wide. CDN pulls fresh in under a second; readers never see stale headlines. ### E-government **Scenario:** Baku ministry refreshes 200 endpoints during business hours **Outcome:** APIops applies land hot. The platform team stops scheduling deploys for nights; the operations runbook loses its longest section. --- ## Apply, propagate, serve — in that order, every time. - **01 · Apply** — Push a definition via UI, APIops, or pipeline. The Manager validates and broadcasts to every Worker. - **02 · Propagate** — Workers receive the change in under a second. The cache layer keeps hot keys; nothing is dropped. - **03 · Serve** — In-flight requests complete on the old shape. New requests land on the new — no restart, no warm-up, no spike. - **04 · Observe** — Analytics shows the cutover, cache hit rates, and tail latency in real time. Roll back is another apply. --- ## Recommended modules - [Cache](https://apinizer.com/products/cache) — Hazelcast-backed distributed cache with coordinated invalidation across every Worker. - [API Gateway](https://apinizer.com/products/api-gateway) — The runtime that hot-loads definitions, policies, and transforms without dropping a request. - [Analytics Engine](https://apinizer.com/products/analytics-engine) — Real-time evidence that a deploy did what you expected — and rollback evidence when it didn't. - [Monitoring](https://apinizer.com/products/monitoring) — Synthetic probes that fire seconds after an apply — confirm green before the team sees the alert. --- ## Resources - [Hot deploy semantics](https://docs.apinizer.com/en) — What apply, propagate, serve looks like under the hood — and why it doesn't drop requests. - [Cache product](https://apinizer.com/products/cache) — Hazelcast-backed distributed cache with coordinated invalidation and per-key TTLs. - [Analytics Engine](https://apinizer.com/products/analytics-engine) — Live deploy cutover, hit rate, and tail-latency telemetry — per definition. - [Architecture overview](https://docs.apinizer.com/en/concepts/architecture) — How the Manager publishes and Workers pick up changes without a restart. - [APIops manifests](https://apinizer.com/developers/apiops) — Hot deploys driven from Git — the same apply that promotes across environments. - [Changelog](https://docs.apinizer.com/en/release-notes/change-log) — Recent runtime improvements — cache, hot deploys, and propagation guarantees. --- ## Related use cases - [API lifecycle management](https://apinizer.com/solutions/api-lifecycle-management) — For platform teams - [Multi-cluster deployment](https://apinizer.com/solutions/multi-cluster-deployment) — For platform teams - [APIops (CI/CD)](https://apinizer.com/solutions/apiops) — For developers - [Observability & audit](https://apinizer.com/solutions/observability-audit) — For platform teams --- ## Next step *Deploy without the dread* **Push at noon. Sleep at midnight.** A 30-minute walkthrough — apply, propagate, cache, observe — on a Kubernetes of your choice. [Book a Demo](https://calendly.com/apinizer/15min) · [Read the docs](https://apinizer.com/developers/docs) --- ## Links - Products: https://apinizer.com/products - AI Gateway: https://apinizer.com/products/ai-gateway - Solutions: https://apinizer.com/solutions - Pricing: https://apinizer.com/pricing - Developers: https://apinizer.com/developers - Documentation: https://docs.apinizer.com/index-en - Blog: https://apinizer.com/blog - Contact: https://apinizer.com/company/contact © 2026 Apinizer. All rights reserved.