NCache RESP Server Architecture

Redis RESP Protocol Compatibility Server Architecture

NCache includes a Redis RESP Protocol Server that allows existing RESP-compatible client libraries and applications to connect to NCache. Each NCache server acts as a RESP endpoint. In a multi-server NCache cluster, RESP clients can connect using one of several architectures depending on how you want requests routed, how failover should work, and whether maximum performance or simpler connectivity is the primary goal.

NCache supports the following RESP architectures:

• CRC-Compliant Cluster
• One Endpoint
• Multiple Endpoints
• Behind a Load Balancer

Of these, the CRC-Compliant Cluster provides the best RESP performance because the client routes each request directly to the NCache server that owns the key.

CRC-Compliant Cluster

The CRC-Compliant Cluster architecture uses Redis Cluster-compatible key hashing and client-side routing. The RESP client learns the NCache cluster topology and sends each request directly to the server that owns the corresponding key.

This eliminates the additional server-to-server forwarding required by the other RESP architectures and provides the best RESP performance in NCache.

How It Works

• The client initially connects to any NCache server.
• NCache reports Redis Cluster support through cluster_enabled:1.
• The client retrieves the Redis hash-slot map from NCache.
• The client caches the complete 16,384-slot map.
• The client opens connections to the NCache servers identified in the slot map.
• For each key, the client computes its Redis CRC16 hash slot.
• The request is sent directly to the NCache server that owns that slot.
• No server-to-server forwarding is required for normal key operations.

Best RESP Performance

CRC-Compliant Cluster provides the highest RESP performance because requests go directly from the application to the NCache server that owns the key.

• Eliminates the extra server-to-server network hop.
• Distributes client traffic across all NCache servers.
• Avoids concentrating application traffic on a single entry server.
• Provides lower latency and higher throughput for distributed workloads.
• Best suited for high-performance and high-throughput RESP applications.

Redis-Compatible Key Distribution

NCache can use the same CRC16 hashing algorithm used by Redis Cluster.

• Enable with NCACHE_KEY_HASH=crc16.
• Supports the Redis CRC16 key-hashing algorithm.
• Exposes the standard 16,384 Redis hash slots.
• NCache continues to use its internal 1,000-bucket distribution architecture.
• Each NCache bucket corresponds to a range of Redis hash slots.
• Redis hash-tag syntax such as {customer}:profile is supported.

The published Redis slot map is derived from the same NCache distribution information used internally to locate keys. This ensures that the slot ownership reported to RESP clients remains consistent with the actual NCache data distribution.

Redis Cluster Compatibility

NCache exposes the cluster information required by Redis Cluster-aware clients.

• Redis-compatible hash-slot calculation.
• Redis-compatible CLUSTER SLOTS behavior.
• Redis-compatible CLUSTER KEYSLOT behavior.
• Existing Redis Cluster-aware client libraries can discover the cluster and route commands directly.

Cross-Slot Operations

Redis Cluster requires all keys used by a multi-key operation to belong to the same hash slot.
For example, an operation such as:

MGET key1 key2 key3

is rejected if the keys belong to different hash slots. This is standard Redis Cluster behavior.

Redis hash tags can be used when related keys must remain in the same slot:

• {cart}:items
• {cart}:total
• {cart}:customer

Because the value inside {} participates in the hash calculation, these keys are routed to the same slot and can be used together in supported multi-key operations.

Best Suited For

• Applications requiring the best RESP performance.
• High-throughput and low-latency workloads.
• Redis Cluster-aware client libraries.
• Applications that can directly reach every NCache server.
• Environments where Redis Cluster semantics are acceptable.

One Endpoint

The One Endpoint architecture provides the simplest RESP client configuration. The application connects to only one NCache server. That server accepts all requests and automatically forwards any request for a remotely owned key to the appropriate server in the NCache cluster.

The RESP client does not need to know that NCache is running as a cluster.

How It Works

• The application connects to one NCache RESP server.
• The application sends all RESP commands to that server.
• The receiving server determines which NCache server owns the key.
• If the key is owned locally, the request is processed directly.
• If another server owns the key, the request is forwarded to that server over RESP.
• The owning server processes the request and returns the result.
• The entry server relays the result back to the client.

Advantages

• Simplest RESP client configuration.
• Only one server address is required.
• Does not require Redis Cluster support in the client.
• NCache cluster topology remains hidden from the application.
• Multi-key operations are not subject to Redis Cluster cross-slot restrictions.

Considerations

• Requests for remotely owned keys require an additional network hop.
• All application traffic initially passes through the configured endpoint.
• The endpoint can become a throughput bottleneck under heavy load.
• If the configured server becomes unavailable, the client needs another mechanism to reconnect to a different server.

Best Suited For

• Applications expecting a single Redis-compatible endpoint.
• Applications using RESP clients without Redis Cluster support.
• Environments where simple client configuration is more important than maximum throughput.

Multiple Endpoints

The Multiple Endpoints architecture allows the RESP client to know about multiple NCache servers. This primarily improves connectivity and failover. It does not provide Redis Cluster-style key routing unless the CRC-Compliant Cluster architecture is enabled.

How It Works

• The client is configured with multiple NCache RESP server addresses.
• The client can establish connections to more than one server.
• Without Redis Cluster protocol support, the client does not know which server owns each key.
• The client generally selects one server for requests.
• If that server does not own a requested key, it forwards the request internally to the owning NCache server.
• The result is returned through the original server.

Multiple Endpoints Provide

• Multiple connection targets.
• Client-side connection redundancy.
• Failover to another NCache server if the active server becomes unavailable.

Multiple Endpoints Do Not Provide

Providing multiple RESP server addresses does not automatically distribute application requests across the NCache cluster. Without Redis Cluster routing, the client does not know the ownership of individual keys.

Therefore, Multiple Endpoints do not provide:

• Client-side key sharding.
• Direct routing to the server that owns each key.
• Redis hash-slot routing.
• The performance characteristics of CRC-Compliant Cluster mode.

Performance Considerations

A client may open connections to multiple servers but still send most application requests through one selected server.

As a result:

• One server may continue to receive most of the workload.
• Requests for remotely owned keys require server-to-server forwarding.
• Adding more endpoints improves failover but does not necessarily improve throughput.

Best Suited For

• Applications that want multiple endpoints for failover.
• RESP clients that support multiple connection addresses.
• Applications that do not want Redis Cluster semantics.
• Environments where availability is more important than direct client-side routing.

Behind a Load Balancer

NCache RESP servers can also be placed behind a load balancer. The application connects to a single virtual RESP address while the load balancer selects one of the NCache servers for the connection.

The application does not need to know the individual NCache server addresses.

How It Works

• The application connects to one virtual load-balancer address.
• The load balancer forwards the connection to an available NCache RESP server.
• The selected server determines which NCache server owns each key.
• Locally owned keys are processed directly.
• Remotely owned keys are forwarded to the appropriate NCache server.
• The response returns through the same client connection.

Advantages

• One stable RESP endpoint for applications.
• Backend NCache server topology remains hidden.
• Provides endpoint-level availability.
• NCache servers can be added, removed, or replaced behind the load balancer without changing the application configuration.

Considerations

A load balancer distributes client connections, but it does not understand NCache key ownership.

Therefore:

• It does not provide key-aware routing.
• A request can arrive at a server that does not own the key.
• Remote requests still require server-to-server forwarding.
• Performance is closer to the One Endpoint architecture than to CRC-Compliant Cluster mode.

Best Suited For

• Applications requiring one stable virtual RESP endpoint.
• Environments where backend server addresses should remain hidden.
• Deployments where endpoint failover is more important than maximum RESP performance.

CRC-Compliant Cluster and Load Balancers

CRC-Compliant Cluster and load-balancer-based routing represent two different connection models and should not normally be combined.

CRC-Compliant Cluster

• The RESP client knows that it is connecting to a cluster.
• The client retrieves the Redis slot map.
• The client learns the addresses of individual NCache servers.
• The client establishes direct connections to those servers.
• The client routes each key directly to its owner.

Behind a Load Balancer

• The RESP client believes it is connecting to one server.
• Individual NCache servers remain hidden.
• The load balancer selects the server that receives the connection.
• NCache performs any required server-side forwarding.

If a Redis Cluster-aware client connects through a load balancer and requests the cluster slot map, NCache must return the actual server addresses that own the slots. The client then connects directly to those servers and effectively bypasses the load balancer. If those individual server addresses are not reachable from the client environment, the cluster connection fails.

For this reason, choose either CRC-Compliant Cluster for direct client-side routing or a load balancer for a single virtual endpoint.

Architecture Comparison

Choosing the Right RESP Architecture

CRC-Compliant Cluster - Best Performance

Choose CRC-Compliant Cluster when maximum RESP throughput and low latency are the primary requirements.

• Best RESP performance in NCache.
• Direct client-to-owner routing.
• No additional server forwarding hop.
• Best distribution of application traffic across the cluster.

One Endpoint - Simplest Configuration

Choose One Endpoint when application simplicity is the primary requirement.

• One server address.
• No Redis Cluster support required.
• NCache transparently handles key routing.

Multiple Endpoints - Client Failover

Choose Multiple Endpoints when the application needs alternate NCache servers for connection failover but does not want Redis Cluster semantics.

• Multiple connection targets.
• Improved endpoint availability.
• Server-side key routing remains transparent to the client.

Behind a Load Balancer - Single Highly Available Endpoint

Choose a load balancer when applications should use one stable virtual address and the NCache cluster topology should remain hidden.

• One application endpoint.
• Load-balancer-based availability.
• Transparent NCache server-side routing.

For applications where performance is the primary consideration and Redis Cluster-compatible clients can directly reach all NCache servers, CRC-Compliant Cluster is the recommended RESP architecture.

What to Do Next?

• Edition Comparison
• Schedule a Demo
• Try NCache