Caching as a Semantic Problem: Redis, Pre-Aggregation, and Mixed Granularity Data

-

 


Caching is usually treated as a performance hack.

Add Redis.
Cache query results.
Invalidate aggressively.
Hope nothing breaks.

That approach works, until you introduce semantics.

Once users can ask the same question in multiple ways, simple query caching starts to fall apart.

Why Query Caching Breaks Down

Consider these two questions:

“Sales by category by month”

“Monthly sales for product categories”

Syntactically different.
Semantically identical.

A traditional cache sees:

  • Two queries

  • Two cache keys

  • Two entries

A semantic system should see:

  • One intent

  • One reusable result

This is where caching stops being technical and starts being conceptual.

The Shift: Cache Meaning, Not Queries

Instead of caching:

  • SQL strings

  • Serialized result sets

The idea is to cache:

  • Semantic tuples

  • At defined grains

  • With known aggregation rules

For example:

  • (Time:Month, Product:Category, Measure:Sales)

Once that tuple exists, many questions can reuse it.

Mixed Granularity Is the Hard Part

Real data is messy.

Some dimensions arrive at:

  • SKU level Others at:

  • Category Or:

  • Brand

If you insist on leaf-level purity, you either:

  • Explode storage

  • Or recompute constantly

The alternative is semantic awareness of granularity.

Redis as a Granularity-Aware Cache

Redis works well here because:

  • Keys are cheap

  • Structures are flexible

  • Access is fast enough to experiment

Instead of: cache:query:{hash}

You start thinking in:

cache:tuple:Time:2025-03|Product:Category:Bike|Measure:Sales

The cache knows:

  • What level the data represents

  • What it can roll up to

  • What it can safely combine with

Pre-Aggregation Without Over-Commitment

The goal isn’t to pre-aggregate everything.

It’s to pre-aggregate:

  • Common levels

  • Stable dimensions

  • High-fan-out queries

Then allow:

  • On-the-fly composition

  • Partial reuse

  • Fallback to source data

Redis becomes a semantic accelerator, not a source of truth.

Why This Feels Different

This approach:

  • Reduces duplicate computation

  • Improves cache hit rates organically

  • Aligns performance with meaning

Most importantly:

It allows the system to explain why a result was fast or slow.

That’s rare and valuable.

A Quiet Benefit: Explainability

Because cached data is semantically labelled, you can say:

  • “This result used cached monthly category aggregates”

  • “This part was computed at runtime due to missing grain”

Performance stops being magical.

It becomes understandable.

Closing Thought

Caching isn’t about speed.

It’s about reusing understanding.

Once you treat it that way, tools like Redis start to look very different.

Comments

Post a Comment

Popular posts from this blog

A Secure Blazor Server Azure Deployment Pipeline

-
Image
I wanted to kick off the year with something practical, modern, and production-ready. This post is based on my own experience deploying my new website, dotnetconsult.tech , using GitHub Actions into Azure App Service . In this post, I’ll walk through how to set up a secure development and deployment flow using: Blazor Server GitHub Azure App Service GitHub Actions with OpenID Connect (OIDC) This approach avoids stored secrets entirely and reflects how I now set up every new .NET project  whether it’s for a client, a SaaS product, or an internal tool.
Read more

Stop Wrapping EF Core in Repositories: Use Specifications + Clean Architecture

-
GitHub project which accompanies this article is available here    Wrapping Entity Framework Core in repositories has become a default in many .NET codebases. But defaults deserve to be challenged. This post shows: why repository-over-EF breaks down how Clean Architecture + Specification Pattern fixes it and how EF Core InMemory tests prove the approach works The problem with “Repository Pattern over EF Core” EF Core already gives you: DbSet<T> → repository behavior DbContext → unit of work Yet many projects add another repository layer anyway. It usually starts simple: Add(order) GetById(id) Update(order) Then order-processing requirements arrive: “Get open orders for customer” “Get orders awaiting payment older than 7 days” “Get paged orders sorted by date with items” Soon you’re staring at this: OrderRepository ├── GetOpenOrdersForCustomer(...) ├── GetOrdersAwaitingPayment(...) ├── GetOrdersWithItemsAndPayments(...) ├── ...
Read more

Server-Sent Events in .NET 10: Do You Really Need SignalR?

-
Image
Real-time updates have become a default expectation in modern web applications. Dashboards refresh automatically, notifications arrive instantly, and long-running operations stream progress back to the UI. In the .NET ecosystem, SignalR has traditionally been the go-to solution for these scenarios. However, with .NET 10 , Server-Sent Events (SSE) have become a first‑class, production-ready option that deserves serious consideration. In many cases, SignalR may actually be overkill . This post explores: What Server-Sent Events are How SSE works in .NET 10 The benefits of SSE over SignalR When SignalR is the right choice How to decide which approach fits your application What Are Server-Sent Events (SSE)? Server-Sent Events provide a simple, standards-based way for a server to push data to a browser or client over HTTP. Key characteristics: One-way communication (server → client) Built on plain HTTP Uses the text/event-stream content type Automatically reconnects if the connection dr...
Read more