Single-Host Shared State (SHSS): A Specialized High-Performance Caching Architecture for Multi-Process C# Web Applications

A Technical Theory White Paper on Single-Host Shared State (SHSS) Caching Architecture.

Abstract

Distributed in-memory caches such as Redis have become a standard component of modern web application architectures. They provide an excellent solution for applications requiring shared state across multiple servers, cloud instances, containers, and geographically distributed deployments. Their flexibility, mature ecosystem, and operational reliability make them the appropriate choice for horizontally scaled systems.

However, not every deployment operates under distributed constraints.

A significant number of enterprise applications continue to run entirely on a single physical or virtual machine while utilizing multiple application processes, such as IIS Web Gardens, multiple Windows Services, or several local worker processes. In these environments, applications face a different engineering challenge: how to efficiently share a common in-memory state across isolated processes without introducing the architectural costs associated with a network-oriented cache.

This paper presents Single-Host Shared State (SHSS), a specialized caching architecture designed specifically for single-machine, multi-process environments. Rather than treating inter-process communication as network communication, SHSS leverages operating system IPC mechanisms—including Windows Named Pipes and Memory-Mapped Files—to centralize cache ownership within a dedicated local daemon while providing high-performance shared access to multiple application processes.

The objective of SHSS is not to replace Redis or compete with distributed caching platforms. Instead, it addresses a narrower class of problems where all participating processes reside on the same operating system instance and where minimizing communication latency, memory duplication, and runtime overhead becomes the primary optimization target.

Within this deployment model, SHSS offers an alternative architectural approach that emphasizes locality, simplicity, and operating-system-native communication over network abstraction.

1. Introduction

Modern web applications frequently evolve beyond a single application process. IIS Web Gardens, multiple worker services, scheduled background jobs, and process isolation all improve scalability and fault tolerance, but they introduce a fundamental challenge:

Each process owns an independent virtual memory space.

Consequently, traditional in-process caches cannot be shared directly between workers. Each process gradually constructs its own copy of application state, increasing memory consumption while introducing cache warm-up delays and consistency challenges.

The industry's standard solution is to externalize shared state into a distributed cache such as Redis.

For distributed systems, this architecture is well justified.

For single-host deployments, however, the engineering tradeoffs become less obvious.

When every participating process executes on the same operating system instance, communication never leaves the machine. Nevertheless, many architectures continue routing cache requests through abstractions originally designed for network communication. Although these abstractions are highly optimized and provide valuable features—including persistence, replication, clustering, and remote accessibility—they may exceed the requirements of applications whose entire execution environment remains local.

This observation motivates the exploration of a different design philosophy:

Can shared application state remain centralized while relying exclusively on operating-system-native inter-process communication instead of network protocols?

This paper investigates that possibility.

2. Design Philosophy

The purpose of SHSS is not to build another distributed cache.

Instead, SHSS begins with a much narrower design assumption:

Every participating process executes on the same host.

Accepting this constraint fundamentally changes the optimization priorities.

Distributed cache systems must solve problems including:

• Remote communication
• Cross-machine consistency
• Authentication
• Replication
• Failover
• Network partition tolerance
• Cluster management
• Persistent storage

SHSS intentionally excludes these concerns.

By restricting operation to a single operating system instance, the architecture can instead prioritize:

• Extremely low communication latency
• Minimal memory duplication
• Unified cache ownership
• Efficient inter-process coordination
• Reduced serialization overhead
• Lower operational complexity

Rather than asking how to synchronize many computers, SHSS asks a simpler question:

How can multiple isolated processes efficiently access the same in-memory state when they already reside on the same machine?

3. Proposed Architecture

SHSS centralizes cache ownership into a dedicated local process responsible for maintaining application state throughout the lifetime of the host.

Individual web workers no longer own independent cache instances. Instead, they communicate with the cache daemon using operating-system IPC.

IIS Worker A        IIS Worker B        IIS Worker C
      │                    │                    │
      └────────────────────┼────────────────────┘
                           │
              Operating System IPC
     (Named Pipes / Shared Memory / Events)
       Single-Host Shared State Daemon
                           │
             Unified In-Memory Application State

This architecture establishes several properties:

• A single authoritative cache exists for the entire machine.
• Application workers become stateless consumers of shared state.
• Cache warm-up occurs only once.
• Memory duplication across worker processes is minimized.
• Communication remains entirely local to the operating system.

The operating system effectively becomes the communication fabric rather than the network stack.

4. Communication Strategy

Instead of treating local communication as network traffic, SHSS utilizes operating-system IPC mechanisms specifically designed for communication between local processes.

Depending on workload characteristics, different IPC technologies provide different performance and engineering tradeoffs.

Named Pipes provide a message-oriented communication channel with relatively simple programming semantics while avoiding the overhead associated with network protocol stacks.

Memory-Mapped Files allow multiple processes to access shared physical memory directly. For workloads dominated by frequent reads or fixed-layout data structures, this approach minimizes data movement and can substantially reduce communication latency.

The objective is not merely faster data transfer.

Rather, it is to eliminate unnecessary abstraction layers when communication never leaves the local machine.

5. Scope

SHSS is intentionally specialized.

It is most applicable when:

• Applications execute entirely on one server.
• Multiple local processes require shared cache access.
• Memory duplication becomes significant.
• Extremely low latency is desirable.
• Horizontal scaling is not an immediate architectural requirement.

It is not intended as a replacement for Redis in distributed environments.

When multiple servers, containers, or cloud instances require shared state, distributed cache systems remain the appropriate architectural solution.

SHSS instead occupies a different design space:

A high-performance shared-state architecture optimized exclusively for single-host deployments.