Redis RESP Protocol Server Architecture
NCache RESP Server Architecture
NCache RESP Server is a Redis Serialization Protocol (RESP)-compatible server that runs natively on Windows and provides in-memory distributed caching. Redis applications can connect to NCache RESP Server using their existing Redis client libraries by updating their connection settings, without requiring changes to the application code. This enables applications to use NCache within a Windows-based application and infrastructure environment while continuing to communicate through the familiar Redis interface. NCache RESP Server supports RESP2 and executes supported Redis commands through the NCache caching engine.
NCache RESP Server provides a Redis-compatible interface to the existing NCache distributed cache architecture. Each configured cache host runs a RESP listener that accepts connections from Redis applications. The listener processes Redis requests and executes the corresponding operations through the NCache cache engine, which manages data storage, distribution, and availability according to the configured cache topology. Redis clients and native NCache clients therefore access the same underlying cache through their respective interfaces.
Redis Client Request Processing
When a Redis application sends a command, the RESP listener receives and parses the request, identifies the command and its arguments, and passes it to the appropriate handler. The handler performs the requested operation through the NCache cache engine, and the result is returned to the application as a RESP response. For distributed caches, NCache also determines which server owns the requested key. Depending on the routing approach, the receiving server either forwards the operation to the owning server or provides routing information that allows a Redis cluster-aware client to contact that server directly.
Redis RESP Protocol Connection Models
NCache RESP Server supports three connection models for Redis applications:
- CRC-Compliant Cluster
- One Endpoint
- Multiple Endpoints
The selected model determines which RESP endpoints an application connects to, how requests are routed, and how failover behaves when a server becomes unavailable. For Partitioned and Partition-Replica topologies, CRC-Compliant Cluster is the recommended model because it provides the best RESP performance. The client learns the cluster layout and sends requests directly to the server that owns each key. This avoids additional server-to-server forwarding and removes the single-entry-server bottleneck that exists in the other connection models.
One Endpoint and Multiple Endpoints can still work with Partitioned and Partition-Replica topologies, but they do not provide maximum performance because the client typically sends requests through one active server and that server forwards requests for remotely owned keys. If you are using a Partitioned or Partition-Replica cache, use CRC-Compliant Cluster for the best performance and better failover behavior.
1. CRC-Compliant Cluster
Use CRC-Compliant Cluster when you are using Partitioned or Partition-Replica topologies. In this model, a Redis cluster-aware client learns the NCache cluster layout and communicates directly with the server that owns each key.
In CRC-Compliant Cluster mode, NCache uses Redis-compatible CRC16 hashing and exposes Redis Cluster routing information to the client. The client uses that information to route requests directly to the correct NCache server.
This model provides the best results for distributed RESP workloads because:
- The client talks directly to the server that owns the key.
- NCache does not need to forward normal key-based operations between servers.
- Client traffic is distributed across the cluster instead of passing through one entry node.
- It provides the best RESP performance for Partitioned and Partition-Replica caches.
- It provides better availability and failover characteristics because the client is aware of multiple servers instead of depending on a single fixed endpoint.
When a request reaches a server that does not own the key, NCache can return the routing information needed by the Redis cluster-aware client to reach the correct server. This lets the client correct its routing information and contact the appropriate endpoint.
2. One Endpoint
Use One Endpoint when simple connectivity is more important than maximum throughput, especially for a single-node development environment or other simple deployments. In this model, the Redis application connects to only one NCache RESP endpoint.
The connected server receives all requests from the application. If the requested key is owned locally, the server processes the request directly. If another server owns the key, the connected server forwards the request to the appropriate cache server and returns the result to the client.
This model is easy to configure because the application uses only one server address. However, it has important limitations in multi-node deployments:
- The application maintains its active RESP connection to one server.
- In a cluster, requests for remotely owned keys require server-to-server forwarding.
- In Partitioned and Partition-Replica topologies, this means additional hops and lower performance than CRC-Compliant Cluster.
- If the configured endpoint becomes unavailable and no other reconnection mechanism is in place, the application stops until it reconnects elsewhere.
Because of this, One Endpoint is best suited to:
- Single-server or development environments.
- Simple client setups that expect one Redis-compatible endpoint.
- Scenarios where client simplicity is more important than failover and maximum performance.
3. Multiple Endpoints
Use Multiple Endpoints when you want better connectivity and failover than One Endpoint, but do not require Redis Cluster routing. This model is suitable for multi-node deployments, such as Replicated topology environments with two or more nodes, where the application should have alternate servers available.
In this model, the client is configured with more than one NCache RESP endpoint. The client typically maintains an active connection to one server at a time and uses the others as alternative connection targets. If the active server becomes unavailable, the client can fail over and reconnect to another configured endpoint.
This model improves availability compared to One Endpoint because:
- The client has multiple server addresses available.
- If one server goes down, the client can fail over to another endpoint.
- It is better suited than One Endpoint for multi-node deployments that need connection redundancy.
However, Multiple Endpoints still does not provide the direct-routing behavior of CRC-Compliant Cluster:
- The client usually sends operations through one active connection.
- Requests for remotely owned keys may still be forwarded internally between servers.
- In Partitioned and Partition-Replica topologies, it improves failover but does not provide the best performance.
Because of this, Multiple Endpoints is best suited to:
- Multi-node deployments that require failover.
- Replicated topology environments with two or more nodes.
- RESP clients that can be configured with multiple server addresses.
- Scenarios where availability is more important than direct client-side routing.
Important
If you are using a Partitioned or Partition-Replica cache, use CRC-Compliant Cluster. One Endpoint and Multiple Endpoints can still work, but they do not provide maximum performance because requests may be routed through one active server and then forwarded internally. CRC-Compliant Cluster provides the most optimized RESP routing model for these topologies.
