การแคชและการบีบอัดการตอบสนองของ API

Recomputing the same response for every request wastes CPU and database time. Caching stores computed results so repeat requests return instantly, cutting both latency and load.

• In-process memory fastest, but per-instance.
• Distributed cache (Redis/Memcached) shared across servers.
• HTTP/CDN cache at the edge.

The most common pattern: check the cache, return on hit, otherwise compute, store, and return. This is called cache-aside.

A time to live balances freshness against hit rate. Volatile data needs short TTLs; reference data can live much longer. Always set some expiry to avoid stale buildup.

The hard part of caching is invalidation. On writes, either delete the affected keys or update them (write-through). Stale data here is a common production bug.

For cacheable API responses, set Cache-Control so browsers and CDNs can reuse them, removing the request entirely on a hit.

ETag and If-None-Match let the server reply 304 Not Modified with no body when data is unchanged, saving bandwidth.

Return only the fields clients need, paginate large lists, and avoid over-fetching. Smaller payloads serialize faster and transfer quicker.

Enable gzip or Brotli on JSON responses. Combined with caching, this minimizes both compute and transfer per request.

When a hot key expires, many requests may hit the database at once (a cache stampede). Mitigate with locks, request coalescing, or stale-while-revalidate.

• Cache-aside with sensible TTLs.
• Invalidate on writes.
• Use Cache-Control and ETags.
• Trim and compress payloads.
• Guard against stampedes.

After a user updates their profile, the API keeps returning the old data for several minutes. What is the most likely cause?

You learned to cut backend work with layered caching (cache-aside, TTLs, invalidation on writes), HTTP caching via Cache-Control and ETags, payload trimming, and compression, while guarding against cache stampedes.