Solidis logoSolidis

Architecture Overview

Understanding Solidis's internal structure and SOLID design principles.

System Architecture
Overview of how Solidis components work together
SolidisClientConnectionTCP · TLS · ReconnectRequesterQueue · Pipeline · TimeoutParserRESP2 · RESP3 · Binary-safePubSubChannel · Pattern · ShardDebugdebug event · No argumentsSolidisClientSolidisFeaturedClienttree-shakable384 commands

Core Components

SolidisClient
Core entry point that creates and coordinates all components
  • ·Component initialization and lifecycle management
  • ·Configuration management
  • ·Event coordination between components
  • ·Extension system for custom commands
  • ·Session recovery after a reconnect: authentication, protocol, database and subscriptions
Connection
Manages TCP/TLS socket connections
  • ·Socket connection establishment
  • ·Automatic reconnection with configurable retry delay
  • ·TLS/SSL support
  • ·Connection state management
Requester
Handles command pipelining and request states
  • ·Command queue management
  • ·Pipeline optimization
  • ·Request/response correlation
  • ·Command timeout handling
  • ·Transaction (MULTI/EXEC) coordination
Parser
Processes RESP2/RESP3 protocol with optimized buffer handling
  • ·RESP protocol parsing (RESP2 and RESP3)
  • ·Zero-copy bulk replies
  • ·Low memory overhead
  • ·Multi-byte character support
  • ·Binary-safe data handling
PubSub
Maintains subscription state for Pub/Sub functionality
  • ·Channel subscription management
  • ·Pattern subscription support
  • ·Message routing to event handlers
  • ·Subscription state recovery after reconnection
Debug
Centralized debug logging system
  • ·Entries delivered through the debug event
  • ·Entries name commands, never their arguments

SOLID Principles in Action

Solidis follows SOLID design principles, so it is easy to maintain, test and extend.

SSingle Responsibility
Each component has a single, well-defined responsibility
Example: Parser only handles RESP protocol parsing, not connection management
OOpen/Closed
Open for extension through extend(), closed for modification
Example: Add custom commands without modifying core client code
LLiskov Substitution
A subclass of the client works wherever the client does
Example: SolidisFeaturedClient extends SolidisClient
IInterface Segregation
Minimal, focused interfaces between components
Example: PubSub exposes only subscription-related methods
DDependency Inversion
Commands depend on a send() method, not on the client class
Example: The same command functions run on the client and on a transaction
Command Execution Flow
From a call such as client.get() to the result its await receives
1
Client receives command
User calls a command method (e.g., client.set('key', 'value'))
2
Requester queues command
Command is added to the pipeline queue and serialized to the RESP protocol with its batch
3
Connection sends data
The serialized pipeline is written to the TCP socket
4
Parser processes response
Parser reads and parses RESP responses from Redis with binary-safe buffer handling
5
Requester resolves promise
Parsed response is matched to the original command and the promise is resolved
6
Result returned to user
The parsed result is returned to the user's await statement
Performance Optimizations
The design decisions that make Solidis fast

Binary-Safe Parser

The parser reads socket chunks incrementally and never modifies them. Bulk replies are views of that data, so holding a Buffer reply keeps its chunk in memory.

Pipeline Batching

Commands are batched into pipelines automatically to cut round trips; maxCommandsPerPipeline caps their size.

Zero-Copy Buffers

Bulk replies are views of the received data, and each pipeline is serialized into one buffer, which keeps garbage collection low.

Lazy Connections

With lazyConnect, the constructor does not connect; the client connects on connect() or on its first command.