Definition
- CDN – a geographically distributed network of edge servers caching static/cacheable content (images, scripts, video) close to users to cut network latency.
- Redis – an in-memory data store caching dynamic data (sessions, balances, counters) close to the application to cut database/compute latency.
- Complementary – CDN serves the static shell from the edge; Redis serves the dynamic personalized data from the data center.
- Semantic cache – stores embeddings of cached questions; new requests are matched by cosine similarity rather than exact key; paraphrases hit the cache.
- Threshold – the similarity threshold is the critical tuning knob; too low returns wrong answers, too high misses paraphrases.
CDN: placing copies of the bank's brochures in every branch so a customer in Chennai picks one up locally instead of waiting for it from Mumbai. Redis: the teller keeping frequently needed figures on a notepad at the counter instead of running to the vault. Semantic cache: a help desk that remembers answers by meaning, so 'penalty for closing my deposit early' and 'how much do I lose breaking my FD' reuse the same cached answer.
Understanding the Concepts
What problem does a CDN solve?
Network latency across continents is dominated by the speed of light. A CDN places edge servers in many locations and serves cached copies from the nearest edge. Ideal for static assets and cacheable responses.
Without CDN: Mumbai origin → Chennai user = 200ms round trip With CDN: Chennai edge → Chennai user = 10ms round trip
What problem does Redis solve?
Redis caches dynamic data close to the application, avoiding slow DB queries or expensive recomputation. Sub-millisecond network hop in the same data center.
package com.bank.cache;
import org.springframework.data.redis.core.StringRedisTemplate;
import java.math.BigDecimal;
import java.time.Duration;
public class BalanceCache {
private final StringRedisTemplate redis;
private final AccountRepository accountRepo;
public BigDecimal getBalance(String accountId) {
String cached = redis.opsForValue().get("balance:" + accountId);
if (cached != null) return new BigDecimal(cached); // cache hit: ~0.5ms
BigDecimal balance = accountRepo.findBalance(accountId); // cache miss: ~5ms DB query
redis.opsForValue().set("balance:" + accountId, balance.toString(), Duration.ofSeconds(30));
return balance;
}
}
How are they complementary?
| Aspect | CDN | Redis |
|---|---|---|
| Distance optimized | User ↔ content | Application ↔ data |
| Data type | Static (images, JS, CSS) | Dynamic (sessions, balances) |
| Location | Edge (geographically distributed) | Data center (same DC as app) |
| Use together | Serves static shell from edge | Serves personalized data from DC |
You would NOT cache a private balance at public CDN edges, and you would NOT use Redis to serve video globally.
What is a semantic cache?
For LLM applications, traditional caching keys on exact input match. A semantic cache stores an embedding for each cached question and matches by cosine similarity.
package com.bank.ai;
public class SemanticCache {
private final VectorStore vectorStore;
private final EmbeddingModel embedder;
private final double threshold;
public String getCachedAnswer(String question) {
float[] embedding = embedder.embed(question);
SearchResult closest = vectorStore.findNearest(embedding);
if (closest.getScore() >= threshold) {
return closest.getAnswer(); // paraphrase hit!
}
return null; // cache miss → call LLM
}
public void cacheAnswer(String question, String answer) {
float[] embedding = embedder.embed(question);
vectorStore.store(embedding, answer);
}
}
What is the similarity threshold trade-off?
- Too low → returns answers for loosely related questions (wrong answers). - Too high → rarely matches paraphrases (useless cache). - Tune against real data; combine with guardrails (only cache stable, non-personalized answers).
What are common mistakes?
// WRONG: caching personalized answers without tenant scoping
// User A asks about their loan; User B asks a similar question → gets User A's answer!
// CORRECT: scope semantic cache per tenant
vectorStore.store(embedding, answer, tenantId); // tenant-scoped
What should a senior engineer know?
- CDN, Redis, and semantic cache can all appear in one system at different layers.
- CDN must never cache authenticated, user-specific responses at shared edges.
- Semantic caches need TTL because underlying knowledge changes.
- The unifying idea: all caches store the result of expensive work and reuse it; they differ in which distance they shrink and how they match.
How do you invalidate each cache layer?
Each layer has a different invalidation strategy. CDN: purge API or TTL expiry. Redis: explicit delete on write plus TTL. Semantic cache: TTL plus version tagging when underlying knowledge changes.
package com.bank.cache;
public class CacheInvalidation {
public static void main(String[] args) {
System.out.println("CDN invalidation:");
System.out.println(" - TTL-based: cache headers (max-age=3600)");
System.out.println(" - Purge API: cdn.purge('/static/rates.js')");
System.out.println(" - Versioned URLs: /static/rates.v42.js (cache-bust)");
System.out.println();
System.out.println("Redis invalidation:");
System.out.println(" - Explicit delete on write: redis.delete('balance:SAV2001')");
System.out.println(" - TTL: key expires after 30 seconds automatically");
System.out.println(" - Kafka event: other instances consume and invalidate");
System.out.println();
System.out.println("Semantic cache invalidation:");
System.out.println(" - TTL: cached answers expire after 24 hours");
System.out.println(" - Version tag: when FD rates change, clear rate-related entries");
System.out.println(" - Never cache volatile or personalized answers");
}
}
Expected output:
CDN invalidation:
- TTL-based: cache headers (max-age=3600)
- Purge API: cdn.purge('/static/rates.js')
- Versioned URLs: /static/rates.v42.js (cache-bust)
Redis invalidation:
- Explicit delete on write: redis.delete('balance:SAV2001')
- TTL: key expires after 30 seconds automatically
- Kafka event: other instances consume and invalidate
Semantic cache invalidation:
- TTL: cached answers expire after 24 hours
- Version tag: when FD rates change, clear rate-related entries
- Never cache volatile or personalized answers
Visual Overview
Three Cache Layers in a Banking Platform
┌──────────────────────────────────────────────┐
│ CDN (edge) │
│ Static assets: JS, CSS, images │
│ Served from nearest edge server │
└──────────────────┬───────────────────────────┘
▼
┌──────────────────────────────────────────────┐
│ Redis (data center) │
│ Dynamic data: sessions, balances, counters │
│ Sub-millisecond lookup │
└──────────────────┬───────────────────────────┘
▼
┌──────────────────────────────────────────────┐
│ Semantic Cache (LLM layer) │
│ Match by embedding similarity │
│ Paraphrased questions reuse cached answers │
└──────────────────────────────────────────────┘
Key Takeaway
A CDN and Redis are both caches but they shrink different distances. A CDN is geographically distributed and caches static content close to users to beat network latency dominated by the speed of light. Redis is an in-memory store that caches dynamic data close to the application to beat database latency. They are complementary: the CDN serves the static shell from the edge, Redis serves the personalized data from the data center.
A semantic cache is a newer pattern for LLM applications. Traditional caches key on exact match, so two differently worded but equivalent questions miss each other. A semantic cache stores embeddings and matches by cosine similarity, so paraphrases hit the cache. The similarity threshold is the critical tuning knob and must be tuned against real data.
At National Bank of India, Pankaj put a CDN at the edge for the portal's static assets, Redis near the application for balances and sessions, and a semantic cache in front of the AI help assistant so customers asking the same question in different words reused a cached answer. The semantic cache was scoped per tenant so one customer's personalized answer was never served to another.
Remember one sentence: a CDN brings content closer to users at the edge, Redis brings data closer to the application, and a semantic cache matches by meaning so paraphrases reuse answers, and they stack as complementary layers in a modern system.
---