An object cache is a layer of server-side caching that stores the results of expensive operations, such as database queries, API responses and computed data structures, as individual objects that the application can retrieve by key instead of rebuilding them. In server performance work, it reduces database load and shortens response time for dynamic pages that cannot be cached as a whole.
The cache usually lives in RAM, either inside the application process or in a dedicated in-memory store such as Redis or Memcached. Unlike a full-page cache, it does not store finished HTML; it stores the building blocks the application uses to produce each page.
How an object cache works
An object cache works on a simple get, miss, compute, set cycle. When the application needs a piece of data, it first asks the cache for a key. On a cache hit, the stored value is returned in well under a millisecond on a local network. On a cache miss, the application runs the original query, stores the result under that key and returns it.
Each entry typically has a time to live (TTL), after which it expires. Entries can also be removed explicitly through invalidation when the underlying data changes, and the cache evicts entries automatically when memory is full, most often with an LRU (least recently used) policy.
The table below summarizes where object caches can be placed and how long their data survives.
| Type | Where data lives | Persistence | Shared between servers |
|---|---|---|---|
| Request-scoped cache | Application memory | One request only | No |
| In-process cache | Worker process memory | Until process restarts | No |
| Local daemon cache | Memcached or Redis on the same host | Until eviction or restart | No |
| Distributed cache | Dedicated cache servers or cluster | Until eviction, optionally persisted | Yes |
Key parameters and design choices
The value of an object cache depends on a handful of tunable parameters. The most important result metric is the hit ratio, the share of lookups answered from cache; for read-heavy workloads it often lies well above 90%, while a low ratio signals poor key design or overly short lifetimes.
| Parameter | Typical range | What it affects |
|---|---|---|
| Memory allocation | Tens of MB to many GB | How much data fits before eviction |
| TTL | Seconds to hours | Freshness versus hit ratio |
| Eviction policy | LRU, LFU or volatile variants | Which entries are dropped first |
| Key structure | Namespaced, versioned keys | Ease of targeted invalidation |
| Serialization format | Native, JSON or binary | CPU cost and memory size |
| Network latency | Sub-millisecond on a LAN | Benefit for very cheap queries |
A practical rule is to cache data that is expensive to build and read far more often than it changes. Caching cheap queries can even slow things down, because each lookup still costs a network round trip and serialization.
Object cache compared with other caching layers
An object cache is one of several complementary caching layers, each storing a different kind of result. Choosing the right layer for each problem matters more than tuning any single one.
| Cache layer | What it stores | Best for |
|---|---|---|
| Object cache | Query results and data objects | Personalized or dynamic pages |
| Full-page cache | Complete rendered pages | Anonymous, identical responses |
| OPcache | Compiled PHP bytecode | Avoiding script compilation |
| Varnish | HTTP responses in front of the server | High-volume public traffic |
| Database buffer pool | Data pages inside the database | Reducing disk reads |
The layers stack. A logged-in shop customer bypasses the full-page cache, but the product catalog, menu and settings still come from the object cache, while OPcache removes the cost of compiling the code that assembles the page.
Using an object cache with a web application
In content management systems such as WordPress, an object cache is enabled through a persistent cache backend that connects the built-in caching API to Redis or Memcached. Without it, cached objects disappear at the end of every request, so the same options and queries are reloaded on each page view.
- Measure first: identify the slowest and most frequent queries before caching anything.
- Choose a shared backend when several web servers serve the same site, so all of them see the same data.
- Invalidate on write: clear or update related keys whenever the source data changes.
- Monitor memory and evictions, because constant eviction means the cache is too small.
- Plan cache warming after deployments, when an empty cache can cause a burst of database load.
Common pitfalls with object caching
The classic difficulty is cache invalidation: deciding exactly when stored data no longer reflects reality. Mistakes here produce stale prices, outdated permissions or content that refuses to update, which users notice immediately.
| Problem | Cause | Fix |
|---|---|---|
| Stale data | Missing invalidation on update | Clear keys on write, shorter TTL |
| Cache stampede | Many requests rebuild one expired key | Locking or early recomputation |
| Low hit ratio | Overly specific keys or short TTL | Redesign keys, extend lifetimes |
| Memory exhaustion | Large objects or no limits | Size limits and eviction policy |
| Data leaks between users | Personal data under shared keys | Include user or tenant in key |
A further warning concerns treating the cache as storage. An object cache must be safe to empty at any moment, so the application should always be able to rebuild every entry from the authoritative database.
In plain words
An object cache is like a notepad next to a librarian. When someone asks a difficult question, the librarian searches the archive once, writes the answer on the notepad and reads it straight from there the next time anyone asks.
The server does the same with database answers. It keeps frequently needed results in fast memory, so it does not have to repeat slow work for every visitor. The key takeaway is that the notepad must be updated whenever the archive changes, or people will get old answers.
A real-world example
An online store with about 40,000 products sees its database server reach high CPU usage every evening. Most visitors are logged in, so the full-page cache helps little, and each product page runs dozens of queries for prices, stock, categories and site settings.
The team adds a Redis-based object cache with 2 GB of memory, an LRU eviction policy and a TTL of 15 minutes for catalog data. Price and stock keys are invalidated whenever an order or an import changes them. After a week, the hit ratio settles above 95%, the number of database queries per page falls sharply and average response time for logged-in visitors drops by more than half. The outcome is that the shop handles its evening peak on the existing hardware.