No eviction under memory pressure, so no miss storms hammering your backend — your working set lives on NVMe instead of being held hostage in RAM, and Flint holds the whole set rather than the part that fits. No warm-up either: a restart comes back with its data, not with an empty cache and a cold-start stampede at your origin. It speaks the Redis protocol, scales behind one endpoint, and costs storage economics instead of memory economics.
Or just email info@crestwayai.com — tell us your working-set size and what you're caching today.
Every drill, incident, and debugging session on this fleet is captured as structured operational knowledge the moment it happens — not as tribal memory, but as material an operations agent can act on. The agent that runs the managed fleet meters usage, heals failed replicas, rotates drained credentials, and plans capacity against that accumulated knowledge; every action it takes is allowlisted, journaled, and auditable, it fails closed, and it pages a human the moment it cannot verify its own fix. Most managed services put people behind the dashboard and call it automation. Flint was designed the other way around: the system explains itself in a form an agent can execute, which is also why the failure claims on this page all come with runnable drills — the agent and you are reading the same evidence.
A RAM cache that cannot hold your working set does not cost you microseconds — it costs you the evictions. Every evicted key is a request that falls through to your origin, and on a hot key it is not one request but every concurrent one at once: the thundering herd that turns a cache miss into an incident. Flint holds the whole set, so those misses stop happening.
A cache call is not a memory access — it is a network call, and in practice two: client → proxy, then proxy → cache node. Each hop costs hundreds of microseconds (a cross-AZ round trip is ~500 µs–1 ms), and a RAM cache behind a proxy crosses exactly the same wires — both designs pay that part identically. The only difference is the last step inside the node, a RAM lookup versus an NVMe read: under 200 µs (0.2 ms) at p50 in every row of the Valkey-versus-Flint table below. That step is the whole of what Flint trades — everything else on the path is identical. What share of your latency it represents depends on your topology, so use your own hop times: the more network sits between your client and your cache, the smaller the medium's share of what anyone measures. The other side of that ledger does not depend on topology at all — a miss costs a full round trip to your origin, and on a hot key, all of them at once.
Client-observed GET latency on one AWS i4i.2xlarge (8 vCPU, 61 GB RAM, 1.7 TB NVMe), 1 KB incompressible values, uniform random keys — the worst-case access pattern. Valkey 8.1 holds 20 GB (near its RAM ceiling on this box); Flint serves 112 GB on the same machine — a dataset Valkey cannot run at all.
| configuration | dataset | p50 | p99 | throughput |
|---|---|---|---|---|
| Valkey (all data in RAM) | 20 GB | 31 µs | 55 µs | 161 K/s |
| Flint — hot tier (page-cached) | 112 GB | 79 µs | 223 µs | 84 K/s |
| Flint — steady state, uniform over all 112 GB | 112 GB | 207 µs | 415 µs | 36 K/s |
| Flint — fully cold (caches dropped) | 112 GB | 223 µs | 775 µs | 27 K/s |
Even fully cold, a Flint read is sub-millisecond at p99 — inside the latency budget of most cache callers (a cross-AZ hop alone costs ~500 µs–1 ms). Real traffic is skewed, so production mixes sit near the hot-tier row. Every write in every row went through the full persistent write path — write-ahead log before the ack, fsync on the bounded cadence.
The 5 TB wall: ElastiCache Serverless documents a maximum of 5,000 GiB per cache (and 32 GiB per hash slot — a single hot slot hits eviction or out-of-memory errors even sooner). Growing past the cap means sharding across caches in your own client code. A Flint cluster scales past 200 TB behind the same single endpoint — and past that, federation keeps the endpoint while adding clusters.
Measured July 2026 with redis-benchmark 7.0 over
RESP, same box, same client, same day. Reproduce it yourself: the
harness (industry-standard memtier_benchmark scenarios) ships in the
open repo as tools/memtier_bench.sh.
July 22, 2026 — the shipping artifact itself. Two numbers frame everything below: every latency is client-observed, end to end — client → TLS handshake → token auth → proxy → storage engine and back, the full path a customer request travels — and the dataset is 434 GB on NVMe served by a box with 61 GB of RAM (7× beyond memory: most of this data CANNOT be cached anywhere). Measured on a single i4i.2xlarge running a released build of the shipping stack — proxy, storage engine, control plane, live replica pair and metering agent all running throughout, exactly as a production node does — with 100 M × 1 KB incompressible keys. memtier_benchmark, 4 threads × 8 clients, 60 s per scenario.
| scenario — client-observed, end to end, 434 GB data / 61 GB RAM | throughput | p50 | p99 | p99.9 |
|---|---|---|---|---|
| GETs, uniform over ALL 100 M keys (7× RAM) | 87,141/s | 0.34 ms | 0.86 ms | 1.34 ms |
| GETs, hot 5 GB slice | 82,923/s | 0.36 ms | 0.91 ms | 1.30 ms |
| Mixed 1:10 write:read (gaussian) | 76,092/s | 0.36 ms | 1.68 ms | 3.63 ms |
| Persistent write ingest (pipeline 16) | 51,191/s for 32 min | 9.9 ms* | 35.3 ms* | 38.1 ms* |
* Pipelined ingest latency is queue depth (512 requests in flight), not per-op cost — every one of those 98 million writes was fsync-bounded before its ack. Honesty notes: the read mixes included 40–50% misses (the loader's key coverage; misses resolve via bloom filters), so these are mixed hit/miss distributions — a full-coverage re-run publishes hit-only rows next. Before the run, a laptop on the public internet completed hostname-verified TLS SET/GET against the stack with the fleet CA — the encrypted front door is the measured path, not a lab shortcut.
Every write lands in the on-NVMe write-ahead log before it is acknowledged, fsynced on a bounded half-second cadence — a restart never costs you the cache. Hot keys serve from the managed memory tier at RAM speed; the long tail lives on NVMe at a fraction of the cost.
There is no maxmemory and no LRU: nothing is ever
evicted because the box ran low on RAM, so a key you wrote is a key
you can read. Sizing stops being a guess about which fraction of
your data deserves to stay resident. And if a node does run out of
room, it refuses new writes rather than quietly discarding what you
already stored — the opposite of what a memory cache does under
pressure.
Replication runs under an enforced lag bound, promotion is epoch-fenced so split-brain is structurally impossible, and a failed node's data is still there when it returns. A master that ends up with no replica at all — the one state a lag bound cannot measure — stops accepting writes after a bounded grace rather than pile up work nothing is copying.
Slot-sharded behind a stateless proxy. Your client never sees cluster topology, migrations, or failovers — any Redis or Valkey client, no SDK, no cluster mode. Growth is horizontal: add node pairs and slots migrate to them live, under a copy-rate throttle, while the endpoint stays exactly where it was. There is no configured size ceiling to hit — 200 TB+ in one cluster, and federation adds clusters behind the same endpoint after that.
A RAM cache that restarts is an empty cache, and an empty cache is an origin stampede. A Flint node restarts with its working set already on disk and serves it immediately; failovers hand traffic to a replica that has the data; new replicas seed themselves from a checkpoint. Cold start is not an event you plan around.
Per-key heat is tracked at the proxy. Hot reads are absorbed by a bounded, short-TTL near-cache at the edge instead of hammering one shard; write-heavy tenants can opt into an async write queue that absorbs bursts on the hot path while every write still lands in the WAL. The classic hot-key incident is handled in the architecture, not in your on-call runbook.
TLS on every client connection and mutual TLS on every internal hop by default. Tokens hashed at rest; credentials and certificates rotate automatically with zero downtime.
The operations agent above is not a bolt-on: metering, replica healing, credential retirement and capacity planning are agent actions with journaled evidence, designed in from the first commit.
Every command is conformance-tested against a reference implementation, and every failure claim has a runnable drill — including randomized chaos with a ledger oracle.
$ valkey-cli -h cache.yourco.flint.dev --tls -a $FLINT_TOKEN
> SET session:42 "..." OK # in the WAL before the ack
> GET session:42 "..." # RAM-speed on the hot tier
> LPUSH jobs task-1 (integer) 1
> ZADD leaderboard 100 alice (integer) 1
> JSON.SET user:42 $ '{"plan":"pro","tags":["a"]}' OK
Strings, hashes, sets, lists, sorted sets, TTLs, JSON documents, and cursor-based SCAN — the working Redis surface, minus the foot-guns (no cross-slot surprises, no data-losing restarts).
Both wire protocols, negotiated per connection. Clients that open
with HELLO 3 — the default in current redis-py and
node-redis, credentials passed inside the handshake — get RESP3 and
receive their own native types back: HGETALL as a dict,
SMEMBERS as a set, ZSCORE as a float. Older
clients stay on RESP2 unchanged. Nothing to configure either way, and
the whole conformance corpus runs over both.
import redis # no options, no shims
r = redis.Redis(host="cache.yourco.flint.dev", password=TOKEN, ssl=True)
r.hgetall("user:42") # {'plan': 'pro'} ← a dict
r.zscore("leaderboard", "alice") # 100.0 ← a float
r.json().get("user:42", "$.plan") # ['pro']
Try it against the real thing. The managed service runs today at
try.crestwayai.com:7379 — TLS-terminated, per-tenant auth,
the same stack the numbers above were measured on. Point any Redis or
Valkey client at it and the snippet above is the whole integration.
Ask for a tenant and we'll send a namespace and token — we issue them by
hand while the service is in early access, so tell us roughly what you
want to throw at it.
| objective | commitment | how it's held |
|---|---|---|
| Availability | designed for 99.99% monthly | per-tenant error-minute accounting from the proxy's own metrics |
| Failover recovery (RTO) | under 10 seconds | measured p50 506 ms, worst 586 ms kill→writable, over 7 promotions in a 12-kill run across 5 hosts on a real network (v0.1.0-rc.28). Through the proxy a client sees no outage at all — just one slower write |
| Loss window on failover (RPO) | at most 10 seconds' worth of acknowledged writes | enforced at 1 s by default — past the lag cap the master sheds writes rather than let the at-risk set grow, and a master that has lost its replica entirely stops accepting after a bounded grace |
| Restart persistence | zero acknowledged-write loss on restart; host loss bounded at half a second | write-ahead log before every ack, fsynced on a 500 ms cadence; a restarted node comes back warm with its data |
Read the loss window as a volume, not a stopwatch. What the cap enforces is how much can ever be at risk: once replication falls behind by more than the cap, the master stops accepting new writes rather than let the at-risk set grow. A second bound covers the case the cap cannot see — with no replica left, there is no lag to measure, so a master that finds itself alone keeps serving only for a bounded grace and then sheds. We publish “ten seconds' worth of writes” instead of “nothing older than ten seconds” because the first is what the code actually enforces, and a promise that outruns its mechanism is not a promise.
For reference: AWS commits ElastiCache Serverless and Multi-AZ to 99.99% monthly, documents failover promotion as “typically just a few seconds”, and notes that with asynchronous replication “a small amount of data might be lost due to replication lag” — without a stated bound (its newest durability mode bounds asynchronous loss at 10 seconds). Flint's commitments match that class; the differences are the enforced one-second cap — so observed loss windows sit near milliseconds, not near the commitment — and an endpoint that never moves by DNS. (As published July 2026.)
These are design objectives backed by measured drills — the formal SLA with service credits ships with general availability, once the numbers have months of fleet history behind them. The proofs are runnable today: failover, lease-fenced split-brain, and randomized chaos drills in the open repo. The two that back the loss window are the strictest, because a backpressure path that never fires looks identical to one that works: one drill tightens the lag cap until the master genuinely sheds and checks that nothing shed is ever miscounted as lost, and the other freezes a replica outright to confirm a master left alone stops accepting on schedule and resumes by itself the moment its replica returns.
Every command below ships with a conformance test
validated against a reference Redis-protocol implementation and both
Flint engines — if it is listed, it behaves the way your client
already expects. Grey chips are supported option forms. One honest
exception: stock Redis and Valkey have no JSON type, so the JSON
family has no reference in that run — those cases were checked
reply-for-reply against the RedisJSON module itself, built from
source, and the handful of places we deliberately differ are written
down in docs/command-support.md.
Excluded by design: cross-slot multi-key commands, MULTI/EXEC/WATCH, pub/sub, streams, blocking commands, KEYS/RANDOMKEY, and EVAL/EVALSHA — these conflict with sharded multi-tenancy or reintroduce the single-threaded bottlenecks Flint exists to avoid. Need one of them? Tell us the workload — patterns with broad demand get first-class commands.
Tell us what you want to throw at it and we'll send a namespace and
token for try.crestwayai.com:7379. Tenants are issued by
hand during early access, so this reaches a person, not a queue —
usually same day.
We use this to set up your tenant and reply — nothing else, no list, no third-party marketing. Prefer mail? info@crestwayai.com reaches the same person.
The entire Flint stack — storage engine, server, proxy, control plane, and the tooling that proves it — is source-available under the Elastic License 2.0: free to run yourself, at any scale, for any purpose except reselling it as a service. Crestway operates the managed fleet — the autonomy, metering, and consoles — so you don't have to.
The repository opens on August 10, 2026 at github.com/Crestway-AI-LLC/flint-cache. Every drill, benchmark harness and conformance case behind the numbers on this page ships in it — the point of publishing the source is that the claims become checkable instead of quotable. It is private until that date, so the link will not resolve before then.