Why Does a Single Computer Need to Talk to Itself?

Rethinking Shared Caching for Multi-Process C# Applications

Introduction

When developers first learn about web application caching, the advice is almost always the same:

"Use Redis."

It's good advice.

Redis is fast, reliable, battle-tested, and powers countless applications around the world.

So naturally, many developers reach for Redis whenever multiple web processes need to share data.

But here's an interesting question:

What if every one of those processes already lives inside the same computer?

Do they really need to communicate as if they were on different machines?

That simple question is what inspired the idea behind Single-Host Shared State (SHSS).

Imagine an Office Building

Suppose three employees work in the same office.

Whenever one employee wants to ask another a question, they don't walk across the room.

Instead...

They write a letter.

They seal it in an envelope.

They hand it to a courier.

The courier drives around the city.

Eventually the courier comes back into the same building and delivers the letter.

It works.

But it feels... unnecessary.

That's roughly what can happen when multiple processes running on the same computer communicate through technologies originally designed for network communication.

Redis is excellent at delivering messages between computers.

But sometimes every participant is already sitting in the same room.

The Hidden Wall Inside Every Computer

Here's something many new developers don't realize.

Running on the same computer does not mean sharing memory.

Imagine IIS running four worker processes.

Worker A

Worker B

Worker C

Worker D

Although they're on the same machine, each process lives inside its own protected memory space.

Think of them as four apartments in the same apartment building.

Each apartment has its own furniture.

Its own refrigerator.

Its own bookshelf.

Nothing is automatically shared.

So if every worker builds its own cache...

Worker A
  Customer List

Worker B
  Customer List

Worker C
  Customer List

Worker D
  Customer List

Now you've accidentally stored the same information four times.

Not only does this waste memory, every worker also needs time to "warm up" its own cache.

The Common Solution

Redis solves this problem by creating one central cache.

Worker A ──┐
Worker B ──┼──► Redis
Worker C ──┤
Worker D ──┘

Now everyone shares the same data.

Problem solved.

And for applications running across multiple servers, this is absolutely the right solution.

Redis was built specifically for that purpose.

But What If Redis Never Leaves the Machine?

Now imagine Redis itself is running on the same computer.

Every request still travels through networking APIs.

Every response still follows communication protocols.

Everything is still organized as if two separate computers are talking to each other—even though they're only a few gigabytes of RAM apart.

That's a bit like using the office courier to deliver a message to someone sitting three desks away.

It works.

But perhaps there's a more direct path.

A Different Way of Thinking

Instead of pretending every process is a remote computer...

What if we simply accepted that they're neighbors?

Rather than talking through network protocols, they could communicate using features the operating system already provides.

Windows has several technologies designed specifically for local communication.

Some allow processes to send messages directly.

Others even allow multiple processes to access the same physical memory.

The operating system becomes the messenger instead of the network.

Meet Single-Host Shared State (SHSS)

The SHSS idea is surprisingly simple.

Instead of every web worker owning its own cache, we create one lightweight cache process — and every worker simply asks that process for data.

Worker A ──┐
Worker B ──┤
Worker C ──┼──► Shared Cache Process
Worker D ──┘

There's only one cache.

One copy of the information.

One place to keep everything warm.

Why Is This Interesting?

The exciting part isn't that SHSS tries to replace Redis.

It doesn't.

Redis solves a much bigger problem.

Instead, SHSS asks a narrower question:

"If every process already lives inside the same operating system, can we design specifically for that situation?"

Sometimes the answer is yes.

By removing layers that only exist for distributed systems, a local-only architecture can often become:

simpler
lighter
more memory efficient
lower latency

Not because Redis is slow...

But because SHSS is solving a much smaller problem.

A Good Analogy

Imagine you're building transportation.

If you need to travel between countries...

You build airports.

If you need to travel between cities...

You build highways.

If you need to walk across your living room...

You don't build either.

You simply walk.

Redis is like an airport.

It's incredibly powerful.

SHSS is like rearranging the furniture in your own house.

Both are excellent designs.

They simply solve different problems.

The Goal of SHSS

SHSS isn't trying to compete with distributed caching systems.

Its goal is much narrower.

It explores what becomes possible when we intentionally design for a single computer with multiple application processes.

For developers working with IIS Web Gardens, Windows Services, local worker processes, or other single-host applications, this perspective opens an interesting engineering question:

It's not about: "How do computers share memory?"

"How do processes on the same computer share memory?"

Sometimes, changing the question leads to a completely different architecture.