updated response caching docs and addressed discrepancies

docs/source/routing/performance/caching/response-caching/faq.mdx

@@ -25,7 +25,7 @@
 
 ### How do schema updates affect my cache?
 
-Cached data remains valid across schema updates. When a new schema is deployed, the router immediately invalidates cache entries that depend on changed portions of the schema, ensuring responses always match the current schema. Cache entries for unchanged schema portions remain available.
+The router does not automatically invalidate cache entries when a schema is updated. Cache entries expire based on their TTL or through explicit invalidation via the invalidation API. If a schema change affects the structure of cached data, you should either wait for TTL expiration or use the invalidation API to clear affected entries.
 
 ### Does the router cache error responses?
 
@@ -63,7 +63,10 @@
 
 ### How does caching work for operations with multiple root fields?
 
-The router caches the entire operation response as a single unit. This means operations with overlapping root fields don't currently share cache entries—each unique operation gets its own entry.
+The router caches at the subgraph fetch level, not the entire operation. Each root field query and entity fetch is cached separately using a key that includes the subgraph name, type, query hash, and authorization context. This means:
+
+- **Root fields**: Each root field query to a subgraph gets its own cache entry. Different operations that result in the same subgraph query can share cache entries.
+- **Entities**: Entity fetches are cached per entity representation. When different operations request the same entity with the same fields, they can share the cached entity data.
 
 ### When should I use invalidation vs. TTL-based caching?
 

docs/source/routing/performance/caching/response-caching/quickstart.mdx

@@ -31,8 +31,15 @@
 In `router.yaml`, configure `response_cache`:
 - Enable response caching globally
 - Configure Redis using the same conventions described in [distributed caching](/router/configuration/distributed-caching#redis-url-configuration)
+- **Configure a TTL** either globally under `subgraph.all.ttl` or for each individual subgraph—the router requires a TTL to be configured and will fail to start without one
 - Configure response caching per subgraph, with overrides per subgraph for disabling response caching and TTL
 
+<Note>
+
+A TTL must be configured globally or for every subgraph. The router uses this as the fallback cache duration when a subgraph response doesn't include a `Cache-Control` header with a `max-age` directive. When a response does include `Cache-Control: max-age`, the router uses that value instead of the configured TTL.
+
+</Note>
+
 For example:
 
 ```yaml title="router.yaml"
@@ -46,6 +53,7 @@
   subgraph:
     all:
       enabled: true
+      ttl: 300s # Required: fallback TTL when responses don't include Cache-Control headers
       # Configure Redis for all subgraphs
       redis:
         urls: ["redis://localhost:6379"]