eduKate SG

Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.

Data Caching and Materialisation | Performance, Freshness, Invalidation, Consistency and Recomputed State

Data caching stores a reusable copy of data or a computed result so future requests can be served faster or more cheaply. Materialisation persists a derived result that could otherwise be recomputed from source data, such as a summary table, pre-joined view, aggregate, feature set or search index.

A cache is valuable because it is not the source. That same fact is also its central risk.

Caches and materialised data improve performance by trading computation for stored state. Instead of repeatedly asking the authoritative system to calculate the same answer, a derived result is preserved and reused. The engineering challenge is to ensure that the performance gain does not silently turn yesterday’s answer into today’s apparent truth.

ARTICLE ID: DATA.MANAGEMENT.040
Canonical function: governed derived state for performance, reuse and bounded staleness
Owner boundary: this article owns caching, materialisation, invalidation and recomputation. Data Synchronisation and Reconciliation owns general multi-system convergence; Data Warehousing and Analytics owns historical analytical stores; Data APIs and Data Services owns machine-facing access interfaces.

The Simple Answer

A cache follows a simple idea:

Authoritative State → Derive Result → Store Copy → Serve Quickly → Detect Change → Invalidate or Refresh → Verify Freshness

The copy is useful only while its relationship to the source remains understood.

Why Cache?

The economic value comes from avoiding repeated work while keeping staleness within acceptable bounds.

Cache vs Source of Truth

A cache should normally be reconstructible from authoritative data. If a cached value becomes the only surviving copy of a business fact, the architecture has accidentally promoted derived state into canonical state.

The source owns the fact. The cache owns a performance representation of that fact.

Materialised Views

A materialised view stores the result of a query so consumers do not need to recompute it every time.

Examples include:

The materialised view should retain lineage to the source tables and transformation version that produced it.

Precomputation

Precomputation spends resources earlier so later reads become cheaper. This is useful when many users repeatedly ask similar questions.

The trade-off is that precomputed results must be refreshed when underlying data changes.

Cache Keys

A cache key identifies which request or logical state a cached value represents.

Good keys include every parameter that changes meaning. If currency, locale, permissions or model version affect the result but are absent from the key, one consumer can receive another consumer’s representation.

Key Collisions

A key collision occurs when two logically different results map to the same cache identity. This can create incorrect or even privacy-sensitive leakage.

Cache identity is therefore a data-modelling problem, not merely a performance setting.

Time to Live

A time-to-live, or TTL, defines how long a cached value may remain before expiry.

A suitable TTL depends on the receiver:

One global TTL for all data is usually wrong.

Expiry Is Not Refresh

Expiry marks a cached value invalid or eligible for replacement. It does not guarantee that a fresh value is already available.

Systems should define what happens after expiry: synchronous recomputation, asynchronous refresh, stale serving, or failure.

Cache-Aside Pattern

In cache-aside designs, the application checks the cache first. On a miss, it reads from the source and places the result into the cache.

This is simple and flexible, but invalidation must still occur when source state changes.

Read-Through Caching

A read-through cache retrieves missing values from the underlying source automatically. The application interacts primarily with the caching layer.

This can simplify application logic but makes the cache infrastructure part of the critical data path.

Write-Through Caching

Write-through designs update cache and backing store in a coordinated path before acknowledging completion.

This can improve immediate consistency but increases write latency and still needs failure handling when one component succeeds and another does not.

Write-Behind Caching

Write-behind designs accept changes in the cache or intermediary state and persist them to the backing store later.

This can improve performance but promotes the cache into a temporary authority role. Durability, ordering, replay and failure recovery therefore become much more important.

Invalidation

Invalidation marks a cached value as no longer trustworthy after source state changes.

The famous difficulty of cache invalidation comes from one question: how does the derived copy know that the source fact it represents has changed?

Time-Based Invalidation

Time-based invalidation expires values after a TTL. It is simple, but staleness may persist until the timer ends.

This is appropriate where bounded staleness is acceptable.

Event-Based Invalidation

Event-based invalidation reacts when the source emits a relevant change event. It can reduce staleness but depends on reliable change capture and event delivery.

A missed invalidation event can create a permanently stale cache unless periodic reconciliation exists.

Version-Based Invalidation

Cached values can carry a source version or generation number. Consumers compare versions and reject stale entries when the source version advances.

This works well when source versions are stable and cheaply observable.

Manual Invalidation

Manual invalidation remains useful for exceptional corrections, but relying on people for ordinary cache coherence is fragile.

Emergency invalidation tools should record who triggered them, why, which keys or regions were affected and whether refresh succeeded.

Freshness Contracts

Every cache should have a receiver-facing freshness expectation.

See Data Contracts and Data Products.

Stale-While-Revalidate

Some systems serve a slightly stale value immediately while refreshing it in the background.

This can provide low latency and resilience where bounded staleness is acceptable. It is inappropriate where presenting stale state could cause material harm.

Cache Stampede

A cache stampede occurs when a popular value expires and many consumers simultaneously request recomputation, overwhelming the source.

Mitigations include:

Prewarming

Prewarming fills caches before expected demand. It can be useful after deployment, failover or known traffic events.

Prewarming should not load obsolete or unauthorised values merely because they were popular previously.

Eviction

Caches have finite capacity. Eviction chooses which entries to remove.

Policies may favour recency, frequency, size or explicit priority. The right policy depends on access patterns and recomputation cost.

Hot Keys

A hot key receives disproportionate traffic and can overload one cache partition or source path.

Detection and sharding strategies may be needed for highly skewed workloads.

Distributed Caches

Distributed caches partition or replicate values across several nodes to scale capacity and throughput.

This introduces distributed-state questions: replica consistency, failover, rebalancing and partial partition loss.

Local vs Shared Cache

A local process cache is extremely fast but each application instance can hold different state. A shared cache centralises state but adds network latency and shared-service dependency.

Some systems use both layers and accept different freshness guarantees at each.

Consistency Models

Caches can be strongly coordinated, eventually consistent or explicitly stale within a defined window.

The model should follow consequence. A content recommendation can tolerate more staleness than an authorisation decision.

Never Cache Authorisation Carelessly

Security decisions can change rapidly when roles are revoked. If authorisation results are cached, TTL and invalidation should reflect the consequence of delayed revocation.

Security-sensitive caches should fail closed where stale access could expose protected data.

Materialised Aggregates

Analytical platforms often materialise aggregates such as daily revenue, monthly active users or attendance rates.

These aggregates must remain bound to the metric definition and source versions that produced them.

See Semantic Layers and Metric Governance.

Incremental Materialisation

Instead of recomputing a full table, incremental materialisation updates only affected partitions or records.

This improves efficiency but increases dependence on complete change detection. Periodic full reconciliation can catch missed incremental changes.

Full Rebuild

A full rebuild recomputes derived state from authoritative sources. It is expensive but conceptually powerful because it removes accumulated incremental drift.

Derived products should be rebuildable whenever practical.

Recomputation as Recovery

Because materialised data is derived, corruption can often be repaired by discarding the bad state and recomputing from source evidence.

This is only safe when source history and transformation versions remain available.

Search Indexes as Materialised State

A search index is a materialised representation optimised for retrieval. It should be reproducible from authoritative documents and indexing logic.

Reconciliation should detect missing, stale and revoked documents.

Vector Indexes as Materialised State

AI vector indexes are also materialised views. They derive chunks and embeddings from source content.

A vector index needs source lineage, embedding-model version, chunking version and deletion propagation.

See AI Data Management.

Feature Caches

Machine-learning systems may cache or materialise model features for repeated serving. Training and serving should use compatible feature definitions and versions.

Lineage

Every important materialised product should be traceable to:

See Metadata and Data Lineage.

Observability

Useful cache and materialisation signals include:

Hit rate alone is not enough. A 99% hit rate on stale or unauthorised values is not success.

Testing

Tests should cover:

See Data Testing and Reliability Engineering.

Cache Poisoning

Cache poisoning occurs when incorrect or malicious data is inserted into a cache and then served repeatedly as if authoritative.

Controls can include validated source paths, signed or authenticated updates, bounded write authority and rapid purge capability.

Privacy

Caches create additional copies of data. Sensitive values can persist after the source changes unless invalidation and expiry are reliable.

Cache storage, logs and backups should follow the classification of the underlying data.

Deletion

When a source record is deleted or access is revoked, derived caches must be identified and invalidated according to their purpose and legal obligations.

A deletion that reaches the database but not the cache is incomplete from the receiver’s perspective.

Availability During Source Failure

Caches can improve resilience by serving previously computed values while the source is unavailable.

The service should make the freshness state explicit. Serving stale-but-known data can be better than failing for some uses and unacceptable for others.

Graceful Degradation

A system can define degraded modes:

Cost

Caching saves compute and source load but creates storage, invalidation, replication and operational cost.

The economic question is:

Saved Computation + Reduced Latency + Reduced Source Load − Storage − Refresh − Complexity − Staleness Risk

See Data Economics and Valuation.

Education Example

An education portal materialises a daily class-attendance summary so teachers do not recompute millions of attendance events on every dashboard load. The summary stores source date, metric definition and refresh time.

If a late attendance correction arrives, the affected class-day partition is recomputed. A periodic full reconciliation checks that incremental updates have not drifted from the underlying events.

Commerce Example

An online store caches product details and availability separately. Descriptions may tolerate a longer TTL. Availability requires faster invalidation because stale stock can create failed orders.

One product does not need one freshness rule for every field.

AI Example

An AI system caches retrieved context for repeated questions. The cache key includes document-set version and access scope. When a source document is updated or revoked, the document-set version changes and old cached contexts become invalid.

This prevents an old answer from surviving merely because it was fast to reuse.

Common Failure Modes

A Cache and Materialisation Checklist

  1. What authoritative source can rebuild this state?
  2. Why is caching or materialisation needed?
  3. What exactly does the cache key identify?
  4. What maximum staleness can the receiver tolerate?
  5. How is invalidation triggered?
  6. What happens if invalidation is missed?
  7. Can the state be fully rebuilt?
  8. How is incremental refresh reconciled?
  9. Are permissions and classifications preserved?
  10. How are deletions propagated?
  11. Is freshness visible to consumers?
  12. What happens during source failure?
  13. How are stampedes and hot keys controlled?
  14. Are source and transformation versions recorded?
  15. Can stale or ambiguous state fail closed where consequence is high?

A Maturity Ladder

  1. Cached: repeated values are stored for speed.
  2. Expired: TTLs bound ordinary staleness.
  3. Invalidated: source changes actively retire stale entries.
  4. Versioned: cached state is tied to source and transformation versions.
  5. Rebuildable: derived state can be recomputed from authority.
  6. Reconciled: incremental materialisations are checked independently.
  7. Observable: hit rate, freshness, lag and invalidation health are visible.
  8. Adaptive: workload, incidents and receiver needs continuously tune materialisation strategy.

The Deeper Principle: Performance Is a Managed Distance from Authority

Caching creates distance between the receiver and the authoritative source in exchange for speed, resilience or cost savings. That distance can be measured in time, versions or transformations.

Good caching does not pretend the distance is zero. It manages the distance explicitly through freshness contracts, invalidation, lineage and rebuildability so performance improves without turning derived state into untraceable truth.

Data Management Series

Final idea: cache and materialise for speed, but never lose the route back to authority. Every derived copy should know what it represents, how stale it may be, how it is invalidated, and how to prove that it can be rebuilt when trust is in doubt.

Explore the connected learning guides

Choose the question that brought you here. Open one useful guide, try a small task, and stop when you have what you need.

Take one question further

The same learning habit can travel across subjects, while each subject keeps its own methods. These routes help you notice a difficulty, understand one part of it, and return to something you can do.

A word is familiar, but using it is difficult.

Move from recognising a word to retrieving it in a new context. Understand vocabulary plateaus.

Try it without the guide: Choose one word you already know. Close the guide and use it in a new sentence. Explain why it fits; try another context tomorrow.

A piece of writing has ideas, but the reader loses the thread.

Make the order of events and the links between sentences clear. Explore composition writing.

Try it without the guide: Choose one short paragraph. Read the relevant explanation, close it, and revise the paragraph. Ask someone to tell you what happened and why.

The Mathematics seems familiar, but marks still disappear.

Find the first point where the working stops being reliable. Find Secondary 4 A-Math mark leakage.

Try it without the guide: For a Secondary 4 A-Math question you have attempted, locate the first uncertain line. Repair that step, then try a comparable question without the worked answer.

A Science fact is remembered, but the explanation is incomplete.

Connect the evidence to a scientific idea and the resulting change. Follow the Primary Science learning route.

Try it without the guide: Choose a familiar Primary Science example. Explain the evidence, the idea and the result without notes. Then change one condition and explain your prediction.

Two accounts of the world seem to disagree.

Check the question, source, date and evidence before combining claims. Explore the World Knowledge research library.

Try it without the guide: Take one claim. Find the source best placed to support it, note its date, and state what remains uncertain. Return to your original question.

There is plenty of help, but independence is hard to see.

Check what the learner can understand and do after support is removed. Understand how education works.

Try it without the guide: Choose one small task the child has practised. Agree on a calm, brief attempt without prompts. Use what happens to choose one next step, then stop.

For the structure behind these connections, read the eduKateSingapore runtime manifest and the eduKate ecosystem boot contract. The reader map describes public navigation; those manifests preserve the wider ownership and return rules.

eduKate Asia

Subscribe to
our newsletter