Explain the internal working of query plan caching?

Query planning — deciding which subgraphs to call, in what order, and how to stitch the results — is a moderately expensive step, but it only depends on the shape of an operation, not on the actual variable values passed at runtime. That's the property query plan caching exploits.

When the gateway or router receives an operation, it computes a cache key derived from the operation's structure (and, for Router, elements like the operation name where relevant to disambiguate variants). If a plan for that exact shape was already computed, it's reused directly instead of running the planning algorithm again — only the actual subgraph fetches use the request's specific variable values.

By default this cache is an in-memory LRU local to each gateway/router instance, so a freshly started instance has to (re)build its cache from cold. Apollo Router additionally supports a distributed cache backend, such as Redis, so query plans (and APQ entries) can be shared across an entire fleet of router instances rather than each one rebuilding the same plans independently.