pool

Redis Connection Pool

Redis connections are expensive to establish and can’t be shared across concurrent requests without coordination. Valkyrie handles the pooling and checkout mechanics, but cache operations also need a key prefix and a timeout — bundling all three into an opaque Pool means every cache call gets a consistent setup without passing three separate arguments around.

Types

Pool

opaque </>

Pool is opaque because a Pool that wasn’t started through start_pool would have no supervisor behind it — cache operations would silently fail or crash with confusing Valkyrie errors instead of a clear startup failure.

pub opaque type Pool

Values

get_connection

</>

pub fn get_connection(pool: Pool) -> valkyrie.Connection

Pool is opaque, so cache.gleam can’t read the conn field directly. These accessors are the trade-off for keeping the type safe — a small price for preventing invalid pools from being constructed.

get_prefix

</>

pub fn get_prefix(pool: Pool) -> String

The prefix is derived from the pool name at startup, so cache.gleam doesn’t need to know the naming convention — it just asks the pool for its prefix and uses it to build keys and flush patterns.

get_timeout

</>

pub fn get_timeout(pool: Pool) -> Int

Having the timeout live on the pool rather than as a per-call argument means you can’t accidentally use 500ms for one operation and 5000ms for another on the same connection, which would make debugging latency issues much harder.

start_pool

</>

pub fn start_pool(store: driver.CacheStore) -> Pool

Individual Redis connections can drop under load or during network blips. Running them under a OneForOne supervisor means a single dropped connection gets restarted without affecting the other connections in the pool. The named process gives us a stable handle that keeps working even after a connection is recycled behind the scenes.