Proxy cache vs Memcached
Bahriya gives you two ways to cache, and they solve different problems. The proxy cache sits transparently in front of an HTTP container and caches whole responses. Memcached is an application-controlled key-value store your code reads and writes directly. This article helps you pick — and shows how they work together.
Bahriya gives you two ways to cache, and they solve different problems. The proxy cache sits transparently in front of an HTTP container and caches whole responses. Memcached is an application-controlled key-value store your code reads and writes directly. This article helps you pick — and shows how they work together.
Proxy cache — transparent response caching
The proxy cache is a managed response cache in front of your HTTP container. You enable it and configure it; you do not change your application code. When a request arrives, the platform checks the cache first. A hit is returned in milliseconds and never reaches your container. A miss goes through, the response is stored, and the next identical request benefits.
Because it caches by request (method, path, query, and any header dimensions you add), it is ideal for read-heavy public endpoints where many callers ask for the same URL. It respects standard Cache-Control behaviour and can serve a stale response as a fallback if your container is briefly unreachable. See Cache-Control and TTL for the tuning details.
The trade-off: it caches at the granularity of a whole response, keyed on the request. If every response is different — per-user content, live data — the hit rate collapses.
Memcached — application-controlled key-value cache
Memcached hands the cache to your application. Your code picks the key, the value, and the TTL, and reads and writes explicitly. That control is the point: you can cache a database query result, a rendered fragment, a session, or a counter — anything, under any key you like — and invalidate an entry precisely by deleting its key.
The trade-off is the mirror image: you have to write the caching logic yourself, including the miss path, and you manage the keys.
When to use which
| If you want to… | Use |
|---|---|
| Cache whole HTTP responses with no code changes | Proxy cache |
| Speed up a read-heavy public API or catalogue endpoint | Proxy cache |
| Serve stale-on-error fallback when the origin is briefly down | Proxy cache |
| Cache per-user or per-session data | Memcached |
| Cache a database query or computed result under your own key | Memcached |
| Store rate-limit counters or view counts | Memcached |
| Cache page fragments and invalidate them precisely | Memcached |
| Cache something keyed on more than the request URL | Memcached |
| Cache highly dynamic, always-different responses | Neither — cache the expensive pieces with Memcached instead |
They work well together
These are not competing choices. A common, effective setup uses both: the proxy cache absorbs repeat traffic to public read endpoints at the edge, while Memcached caches the per-user data, query results, and fragments behind them. The proxy cache protects your compute budget from bursty read traffic; Memcached keeps the dynamic work fast.
Note that the proxy cache is managed for you — when enabled it appears in your Memcached list as read-only, managed by the container, and you configure it through the container's settings rather than directly.
Related
From the blog