Someone proposes turning on Hibernate's second-level cache for every entity to fix slow reads, with no size or expiry configured per region. How do you evaluate that proposal, and what would you actually cache?

## What the second-level cache actually is The second-level cache is a `SessionFactory`-scoped store of entity **state keyed by identifier** (plus optional collection and query caches). On a cache hit for `em.find(Entity.class, id)`, Hibernate rebuilds the entity from cached state without touching the database. Three consequences follow immediately, and they decide the whole discussion: 1. **It serves lookups by id.** It does not serve `select ... where status = ?`. A JPQL query always goes to the database unless the separate **query cache** is enabled. 2. **The query cache is a different thing with different economics.** It stores the *identifiers* a query returned, keyed by the query text and parameters, and it is invalidated whenever any table in the query's space is written. On a write-active table it is invalidated constantly, so hit ratios collapse and you pay maintenance for nothing. It also still needs the entity cache to resolve those ids, or it issues n lookups. 3. **Collection caching stores ids too**, so a cached collection still resolves each element — usefully cheap only when those elements are themselves cached. ## Why "cache everything" is the wrong instinct **It does not remove work; it makes work cheaper.** A 1 + N fan-out with a warm cache is still N lookups: N map hits, N entity rehydrations, N objects. Faster, yes; but the correct fix — a fetch join, an entity graph, batch fetching, a projection — makes N *zero*. Caching a bad fetch plan freezes it in place and makes the eventual fix harder to justify. **Unbounded regions are unbounded.** Without a maximum entry count or size and without a TTL/TTI, a region converges on the whole table. On-heap that is direct GC pressure and eventually an OutOfMemoryError; the failure looks like a memory leak because it is one. Off-heap or distributed it becomes a cost and latency problem instead. **Writes invert the economics.** Every update must invalidate or update the entry, and under `read-write` semantics Hibernate takes a soft lock around the change. For a hot, frequently-updated entity the cache adds coordination on the write path and delivers few hits on the read path. **Staleness has a blast radius.** Anything that changes rows without going through this `SessionFactory` — another service, a migration, a DBA fix, a bulk `update` HQL statement — leaves the cache serving old data with no signal. That is a correctness risk, not a performance one, and it must be reasoned about per entity. **Clustering multiplies the questions.** In more than one node, entries are replicated or distributed, and invalidation crosses the network. A cache that is a clear win on a single node can be a net loss across six. ## What genuinely belongs in it The profile of a good candidate: - **Small and bounded** — currencies, countries, tax rates, product categories, feature definitions, permission types. - **Read-mostly or immutable** — changes are rare and deployment-shaped rather than user-shaped. Immutable entities can use the `read-only` strategy, which is the cheapest and safest. - **Accessed by identifier** — because that is what the cache serves. Association navigation to a to-one is exactly this pattern, which is why reference data behind `@ManyToOne` is the sweet spot. - **High reuse across sessions** — many requests want the same few rows. - **Tolerant of bounded staleness**, with an explicit expiry expressing what "bounded" means. What does not belong: user-generated content, orders, events, anything append-heavy or hot-updated, and anything large enough that caching it is really "keep the table in RAM" — a decision to make deliberately, if at all. ## Bounding every region Whatever provider is in use, each region gets an explicit maximum size (entries or bytes) and an explicit expiry (time-to-live, and time-to-idle if reuse is bursty). Two reasons: memory becomes a number you chose rather than a consequence of table growth, and expiry caps the staleness window for anything modified outside Hibernate. Regions should be named per entity or per group so they can be sized differently and observed separately. ## Deciding with evidence - Establish the **hit ratio** per region from Hibernate's statistics. A region below roughly 80–90% hits is usually not paying for its memory and invalidation cost; a region at 99% on a tiny table is doing exactly its job. - Watch **eviction/expiry rates**. High eviction means the region is too small or the data is not reusable. - Watch **puts versus hits**. A region with many puts and few hits is caching write-through traffic, which is pure overhead. - Remove regions that fail these tests. An unused cache is not free. ## The order of operations Fix the fetch plan, bound the queries, project what the screen needs, batch the writes. Re-measure. Then, for whatever remains and fits the reference-data profile, add a **named, bounded, expiring** region and prove the hit ratio. Caching last is not conservatism — it is that caching only makes remaining work cheaper, and everything above removes work outright. ## How to answer the proposer Agree on the goal, disagree on the instrument: ask for the statement count and row count behind the slow screens first. In my experience most of the wins are in the fetch plan, and the caching that survives is a short list of reference tables — which is a much easier thing to operate than a cache on every entity.