微服务架构下API网关缓存问题：缓存类型与服务描述一致性

Great question—caching in API gateways is a critical optimization for cutting latency, reducing backend load, and saving bandwidth. Let’s break this down step by step:

1. Common Data Types Cached in API Gateways #

API gateways typically cache several categories of data, tailored to different use cases:

• Static Resources & Full API Responses: This is the most widespread scenario—static assets like images, CSS, or static HTML, plus API responses that rarely change (e.g., product catalog details, static configuration lists). Caching the full response body eliminates redundant calls to backend services for repeat requests.
• Computed/Aggregated Results: For APIs that run heavy computations or aggregate data from multiple services (like daily sales reports, user activity summaries), caching the final result avoids redoing expensive processing on every request.
• Auth & Authorization Data: Validated JWT tokens, user permission sets, or role-based access control (RBAC) rules are often cached. This skips repeated calls to authentication/authorization services for every incoming request, speeding up auth checks significantly.
• Routing Metadata: Gateway-specific routing rules, API version mappings, and endpoint configurations are cached locally to reduce frequent lookups to external configuration centers, making routing decisions faster.
• Partial Response Fragments: For dynamic content (like a personalized dashboard), gateways might cache static fragments (e.g., shared navigation bars, common footer content) instead of the full response. This balances dynamic personalization with caching efficiency.

2. Service Description Caching in Microservice Gateways #

Short answer: Yes, most modern API gateways do cache service descriptions (like instance addresses, health statuses, ports, and metadata from service discovery tools such as Eureka, Consul, or Kubernetes Service).

Why? Querying the service discovery registry on every request would introduce unnecessary latency and put extra load on the registry. Caching these descriptions keeps routing decisions fast and reliable.

How to Maintain Cache Consistency #

To ensure the gateway’s cached service data stays in sync with the actual service registry, here are the standard industry approaches:

• Active Push + TTL Expiry: Most service registries support pushing updates to gateways whenever a service instance changes (e.g., goes online, offline, or reports a health status shift). Gateways also set a time-to-live (TTL) on cached entries—if a push is missed, the cache expires automatically, and the gateway fetches fresh data from the registry as a fallback.
• Periodic Polling & Validation: Gateways periodically pull the latest service list from the registry (every few seconds to minutes) and compare it with the local cache. Any discrepancies trigger an immediate cache update. This acts as a safety net for missed push notifications.
• Health Check Integration: Gateways often run their own health checks on cached service instances. If an instance fails a health check, the gateway immediately marks it as unavailable in the cache and notifies the registry, which then triggers a cache refresh across all connected gateways.
• Versioned Cache Keys: Service descriptions are stored with versioned cache keys. When the registry updates a service’s metadata, it increments a version number. Gateways only update their cache if the version number in the registry is higher than the one in their local cache, reducing unnecessary cache update operations.

内容的提问来源于stack exchange，提问作者Zeina