A payments platform has a few hundred milliseconds to decide whether an authorisation is fraud, and most of that budget belongs to the network, the card scheme and the rules engine. The in-memory store that holds per-card velocity windows, merchant risk rankings and device cardinality gets perhaps two milliseconds, at tens of thousands of events per second, with no tolerance for stale data. That is the job Valkey real-time analytics does well, and Valkey 9.1 makes it easier than any previous release. This post walks through a FinTech design end to end, with the keyspace, the commands, the configuration and the scaling path.
Everything here is pinned to Valkey 9.1.2, the current stable release (1 September 2026), and to the 9.0 features it builds on. Where we quote throughput figures they come from the Valkey project’s own announcements; our own numbers are marked as illustrative.
What Valkey 9.1 changed for Valkey real-time analytics
Valkey 9.0 (October 2025) delivered the structural changes: hash field expiration, atomic slot migration, numbered databases in cluster mode, and a set of engine optimisations the project reports as up to 40% more throughput from pipeline memory prefetch and up to 20% from zero-copy responses. Valkey 9.1 (May 2026) added a redesigned I/O threading model that the project measured at 2.1 million requests per second on a single server with nine I/O threads, 512-byte payloads and a pipeline depth of ten, plus up to 30% faster stream range reads and up to 30% higher GET throughput.
For a FinTech workload, three smaller 9.1 items matter as much as the headline numbers: strings under 128 bytes use up to 20% less memory, ACL SETUSER can now confine a user to specific databases with db=, and MSETEX sets several keys with one shared expiry. Valkey 9.1.1 (July 2026) was a security release; 9.1.2 followed in September. If you are on 9.1.0, upgrade.
The Valkey FinTech application: fraud scoring on a payments stream
Our Valkey FinTech reference design is a card-authorisation pipeline. Every authorisation becomes a stream entry, a scoring worker folds it into windows for that card, the worker calls a Valkey function that returns an explainable score, and the decision service combines that score with the rules engine. Valkey holds the last hour of state; PostgreSQL remains the ledger and the system of record.
The volumes are modest by Valkey standards and brutal by latency standards: 20,000 to 60,000 events per second at peak (illustrative), each triggering four to six commands, with a p99 budget under two milliseconds for the scoring read. The design decisions below all follow from that shape.
Valkey real-time analytics keyspace design: let the hash tag do the work
In a cluster, keys that share a hash tag, the part of the name inside braces, hash to the same slot and therefore to the same node. We use the card identifier as the tag for everything that must be updated atomically for one card, and separate tags for data that is global by nature, such as the merchant ranking.
Two decisions deserve a note. The merchant ranking is a single hot key, so we shard it by hour (risk:merchant:1h becomes a key per hour, merged by the dashboard) rather than let one slot carry every write. And card streams are trimmed with MAXLEN ~, the approximate form, which trims whole internal nodes and keeps XADD at O(1) instead of forcing exact trimming on every write.
Ingestion with streams and consumer groups
# Valkey real-time analytics ingestion. One stream per card, trimmed to the last ~1000 events, so a hot card never grows without bound.
# The {card} hash tag keeps every key for that card in the same slot.
XADD txn:{4111...1111}:events MAXLEN ~ 1000 * amount 184.50 currency EUR mid m_3391 \
country FR channel ecom device d_7f21 ts 1759824000123
# A consumer group per scoring service; MKSTREAM creates the stream if the card is new.
XGROUP CREATE txn:{4111...1111}:events scorers $ MKSTREAM
# Each scoring worker reads only undelivered entries, blocking for at most 50 ms.
XREADGROUP GROUP scorers worker-07 COUNT 100 BLOCK 50 STREAMS txn:{4111...1111}:events >
# Acknowledge after the velocity update below has succeeded, never before.
XACK txn:{4111...1111}:events scorers 1759824000123-0
# Reclaim entries a crashed worker left pending for more than 5 seconds.
XAUTOCLAIM txn:{4111...1111}:events scorers worker-07 5000 0-0 COUNT 100
# Health: how far behind each consumer group is.
XINFO GROUPS txn:{4111...1111}:events
Acknowledge after the downstream write succeeds, not after the read. If a worker dies between the two, XAUTOCLAIM hands the entry to a healthy worker after the idle threshold, and the velocity update is applied once because the function below is idempotent per stream entry if you key it on the entry ID (not shown, to keep the example short).
Valkey FinTech velocity windows with hash field expiration
Before Valkey 9.0, a sliding window per card meant either one key per window with its own TTL, multiplying key count by the number of windows, or a sorted set of timestamps that needed trimming on every read. Hash field expiration collapses that into one hash per card whose fields expire independently. The 5-minute, 1-hour and 24-hour spend totals are three fields of one key, and each field disappears exactly when its window ends.
# Valkey FinTech velocity windows with hash field expiration (Valkey 9.0+): one hash per card,
# one field per window, each field dies exactly when its window ends.
# Spend in the last 5 minutes, 1 hour and 24 hours, as three fields of one key.
HINCRBYFLOAT vel:{4111...1111} spend_5m 184.50
HINCRBYFLOAT vel:{4111...1111} spend_1h 184.50
HINCRBYFLOAT vel:{4111...1111} spend_24h 184.50
# Set the field TTLs only when the field is new (NX), so a window keeps its original end.
HEXPIRE vel:{4111...1111} 300 NX FIELDS 1 spend_5m
HEXPIRE vel:{4111...1111} 3600 NX FIELDS 1 spend_1h
HEXPIRE vel:{4111...1111} 86400 NX FIELDS 1 spend_24h
# Countries seen in the last hour: one field per country, written with its TTL in one command.
HSETEX vel:{4111...1111} FNX EX 3600 FIELDS 1 country:FR 1
# What the scorer reads: all live windows in one round trip. Expired fields are simply absent.
HGETALL vel:{4111...1111}
HTTL vel:{4111...1111} FIELDS 3 spend_5m spend_1h spend_24h
The NX option on HEXPIRE is the detail that makes this a tumbling window: the TTL is set only when the field is created, so later increments extend the total but not the window. HSETEX ... FNX does the same for countries seen in the last hour in a single command. The scorer reads everything with one HGETALL; expired fields are simply not there.
An atomic, explainable score as a Valkey function
Scripting in Valkey 9.1 is a loadable engine that can be disabled entirely, which auditors like; where it is enabled, Valkey functions are the right vehicle for a short atomic decision. The function below runs on the node that owns the card’s slot, touches only keys sharing that tag, and returns the components of the score so the decision is explainable to a dispute team.
#!lua name=fraudlib
-- Valkey real-time analytics: atomic risk decision for one card. All keys share the {card} tag, so this runs on one node
-- and no other command interleaves. Loaded with: FUNCTION LOAD REPLACE "<this file>"
local function score_card(keys, args)
local vel_key, dev_key, risk_key = keys[1], keys[2], keys[3]
local amount, device, mid, now = tonumber(args[1]), args[2], args[3], tonumber(args[4])
-- 1. Fold this authorisation into the 5-minute window (field expires on its own).
local spend_5m = tonumber(server.call('HINCRBYFLOAT', vel_key, 'spend_5m', amount))
server.call('HEXPIRE', vel_key, 300, 'NX', 'FIELDS', 1, 'spend_5m')
local count_5m = tonumber(server.call('HINCRBY', vel_key, 'count_5m', 1))
server.call('HEXPIRE', vel_key, 300, 'NX', 'FIELDS', 1, 'count_5m')
-- 2. Is this a device we have seen for this card?
local new_device = server.call('SADD', dev_key, device)
-- 3. Simple, explainable score; the real model lives in the scoring service.
local score = 0
if spend_5m > 2000 then score = score + 40 end
if count_5m >= 6 then score = score + 30 end
if new_device == 1 then score = score + 20 end
-- 4. Feed the merchant ranking (its own slot, so done by the caller, not here).
return { score, spend_5m, count_5m, new_device }
end
-- No 'no-writes' flag: this function writes. Keep it that way so replicas and AOF see the effects.
server.register_function('score_card', score_card)# Valkey FinTech scoring worker: Valkey GLIDE (the official client) against the cluster. Python 3.11+.
# Secrets come from the environment; nothing is hard-coded.
import asyncio, os, time
from glide import GlideClusterClient, GlideClusterClientConfiguration, NodeAddress, ServerCredentials
async def main() -> None:
cfg = GlideClusterClientConfiguration(
[NodeAddress(os.environ["VALKEY_HOST"], 6379)],
credentials=ServerCredentials(os.environ["VALKEY_PASSWORD"], "scorer"),
request_timeout=250, # ms: fail fast, the gateway has its own budget
)
client = await GlideClusterClient.create(cfg)
try:
card, mid, device, amount = "4111...1111", "m_3391", "d_7f21", "184.50"
tag = "{" + card + "}"
# 1. One atomic call for everything that shares the card's slot.
score, spend_5m, count_5m, new_device = await client.fcall(
"score_card",
keys=[f"vel:{tag}", f"dev:{tag}", f"risk:{tag}"],
arguments=[amount, device, mid, str(int(time.time() * 1000))],
)
# 2. Merchant ranking and device cardinality live in other slots: separate commands,
# issued concurrently; GLIDE routes each to the right node.
await asyncio.gather(
client.zincrby("risk:merchant:1h", float(score), mid),
client.pfadd(f"uniq:devices:{{{mid}}}", [device]),
)
# 3. Decide. Thresholds are policy, owned by the risk team, versioned in db 1.
decision = "review" if int(score) >= 60 else "approve"
print(decision, score, spend_5m, count_5m, new_device)
finally:
await client.close()
asyncio.run(main())
Keep Valkey real-time analytics functions short. Anything on the main thread blocks every other command on that node, so a function that loops over a large set is a latency incident waiting to happen. The merchant ranking and the device HyperLogLog are updated outside the function because they live in other slots; GLIDE routes those commands to the right nodes and runs them concurrently.
Configuration for a Valkey FinTech analytics node
The configuration decisions that matter most for this workload are threading, memory policy and what happens on the main thread. Each line below states the 9.1 default, the reason for the change and whether it needs a restart.
# valkey.conf for a Valkey real-time analytics node (Valkey 9.1.2, 16 vCPU, 64 GB; illustrative) # Format: directive value # default -> why ; restart or CONFIG SET io-threads 12 # 1 -> parallel read/parse/write; leave cores for the main thread and the fork ; restart maxmemory 48gb # 0 -> leave room for the fork's copy-on-write pages and client buffers ; CONFIG SET maxmemory-policy noeviction # keep: analytics windows must expire by design, never by eviction ; CONFIG SET lazyfree-lazy-user-del yes # yes in 9.x -> big DEL/UNLINK off the main thread ; CONFIG SET lazyfree-lazy-expire yes # yes -> expired windows freed in the background ; CONFIG SET active-expire-effort 3 # 1 -> hash-field and key TTLs reclaimed faster at a small CPU cost ; CONFIG SET cluster-enabled yes # restart cluster-databases 4 # 1 -> isolate rule configs (db 1) from analytics data (db 0) ; restart cluster-slot-stats-enabled yes # no -> cpu-usec and network bytes per slot for hot-slot analysis ; CONFIG SET cluster-allow-reads-when-down no # keep: a fraud decision on stale data is worse than a fast fail ; CONFIG SET repl-diskless-sync yes # keep: new replicas sync without a disk round trip ; CONFIG SET appendonly no # the ledger lives in PostgreSQL; RDB every 15 min is enough for a 1 h window ; CONFIG SET save 900 1 # one snapshot per 15 minutes if anything changed ; CONFIG SET log-format json # legacy -> machine-readable logs for the SIEM ; CONFIG SET enable-debug-command no # keep closed in production ; restart
Two of these Valkey FinTech settings are deliberately conservative. We keep maxmemory-policy noeviction because an evicted velocity window silently under-counts spend, which is exactly the failure a fraud system must not have; windows expire by design through field TTLs instead. And we keep cluster-allow-reads-when-down no, because a scoring read against a partitioned node is worse than a fast error the decision service can handle.
Proving Valkey real-time analytics numbers with valkey-benchmark
The Valkey 9.1 benchmark tool reports a distribution of requests per second, not just an average, and gained --warmup and --duration so a run can settle before it counts. We shape the command mix to the application rather than accept the default SET/GET run.
# Valkey real-time analytics load test, run before the launch: valkey-benchmark 9.1 with a shaped workload.
# --warmup and --duration are new in 9.1; -P is pipeline depth; --threads drives the client side.
valkey-benchmark -h ${VALKEY_HOST} -a ${VALKEY_PASSWORD} --cluster --tls \
--threads 8 -c 200 -P 16 -d 256 -r 2000000 \
--warmup 30 --duration 180 \
-t hincrbyfloat,hgetall,zincrby,xadd,pfadd
# Read the report for: requests per second, p50/p99/p99.9 latency and the RPS distribution.
# Then watch the server side during the run (replace with your node addresses):
valkey-cli -h ${VALKEY_HOST} -a ${VALKEY_PASSWORD} --tls INFO threads
valkey-cli -h ${VALKEY_HOST} -a ${VALKEY_PASSWORD} --tls LATENCY HISTOGRAM hincrbyfloat hgetall
valkey-cli -h ${VALKEY_HOST} -a ${VALKEY_PASSWORD} --tls CLUSTER SLOT-STATS ORDERBY cpu-usec LIMIT 10 DESC
Read three things from the server during a Valkey real-time analytics run: INFO threads to confirm the I/O threads are busy and the main thread is not pinned, LATENCY HISTOGRAM for the per-command tail, and CLUSTER SLOT-STATS ORDERBY cpu-usec to see whether a few slots dominate. The last one is the input to the scaling decision.
Scaling Valkey real-time analytics out with atomic slot migration
Resharding, the task that generates the most Valkey support tickets, used to mean moving keys one at a time, with large keys causing latency spikes and clients chasing ASK redirects. Valkey 9.0’s atomic slot migration moves whole slots: the source snapshots the slot in a forked child, streams the changes that arrived meanwhile, pauses writes to that slot briefly for the final delta, then transfers ownership. Clients see one MOVED redirect at the end, and no partial state in between.
# Valkey consulting runbook: scale out when two primaries carry the hottest merchant slots (Valkey 9.0+).
# 1. Verification before: which slots burn the most CPU, and who owns them?
CLUSTER SLOT-STATS ORDERBY cpu-usec LIMIT 10 DESC
CLUSTER SHARDS
# 2. Add the new primary to the cluster (run from any existing node).
valkey-cli --cluster add-node ${NEW_NODE}:6379 ${SEED_NODE}:6379
# 3. Move a contiguous range of hot slots atomically. Run on the SOURCE primary that owns them.
# Gate: confirm the target node ID with CLUSTER SHARDS before you run this.
CLUSTER MIGRATESLOTS SLOTSRANGE 5461 5800 NODE ${TARGET_NODE_ID}
# 4. Poll until the migration reports success; cancel if it does not converge in the window.
CLUSTER GETSLOTMIGRATIONS
# CLUSTER CANCELSLOTMIGRATIONS -- only if step 4 shows a stuck migration
# 5. Validation after: slot ownership moved, key counts match, no slot left unassigned.
CLUSTER SLOT-STATS SLOTSRANGE 5461 5800
CLUSTER INFO
Valkey consulting capacity planning for this workload is about CPU on the main thread and memory for the fork, not about disk. Our rule of thumb (illustrative, and measured per client) is to add a primary when the hottest node’s main thread exceeds 60% at peak or when used_memory passes 60% of maxmemory, whichever comes first, so there is headroom for the next snapshot and the next migration.
Valkey FinTech security and isolation in a regulated estate
A Valkey FinTech platform runs under PCI DSS, and auditors ask who can read card-linked keys. Valkey 9.1 lets an ACL user be confined to specific databases, which combined with key patterns and command categories gives a clean separation between scoring workers, dashboards and the risk team that publishes rules.
# Valkey FinTech least privilege (Valkey 9.1: db= restricts users to databases).
# Scoring workers: read/write analytics keys in db 0 only, no admin, no scripting.
ACL SETUSER scorer on >${SCORER_PASSWORD} ~txn:* ~vel:* ~dev:* ~risk:* ~uniq:* \
+@read +@write +@stream +@hash +@set +@sortedset +@hyperloglog +fcall db=0 -@dangerous
# Dashboards: read only, analytics keys, db 0, allowed to use replicas.
ACL SETUSER dashboard on >${DASHBOARD_PASSWORD} ~risk:* ~uniq:* ~vel:* +@read +readonly db=0
# Risk team: owns the rule set in db 1 and nothing else.
ACL SETUSER riskops on >${RISKOPS_PASSWORD} ~cfg:* +@read +@write +@string db=1
# Rules are published with a shared TTL so stale versions vanish together (MSETEX is new in 9.1).
SELECT 1
MSETEX 2 cfg:rules:v42 '{"spend_5m":2000,"count_5m":6}' cfg:rules:current v42 EX 86400
# Audit: who can do what, and when certificates expire (INFO shows TLS expiry in 9.1).
ACL LIST
INFO server
In any Valkey FinTech deployment, card identifiers in keys should be tokenised before they reach Valkey; the examples use a placeholder PAN for readability only. TLS is on for every client connection, and 9.1’s automatic certificate reloading plus the expiry field in INFO remove the two most common causes of a self-inflicted outage in a TLS-everywhere estate.
Valkey support observability: the five numbers that predict an incident
# The five numbers our Valkey support engineers watch for Valkey real-time analytics, all from built-in commands. # 1. Are the I/O threads carrying the load, or is the main thread saturated? INFO threads # 2. Memory: used, peak, fragmentation; above 1.5 fragmentation, schedule active defrag. INFO memory # 3. Command latency distribution per command, not an average that hides the tail. LATENCY HISTOGRAM xadd hincrbyfloat hgetall zincrby # 4. Replication: a replica more than a few hundred KB behind should not serve dashboards. INFO replication # 5. Keyspace hygiene across the whole cluster in one cursor (CLUSTERSCAN, Valkey 9.1): # streams that grew past their trim, or keys of a type that should not exist. CLUSTERSCAN 0 MATCH txn:* TYPE stream COUNT 1000
Valkey support alerting works on trends, not thresholds alone: fragmentation climbing after each daily peak, a consumer group’s pending count growing for more than a minute, or replica lag that no longer returns to zero. These show up well before p99 does.
Valkey FinTech persistence and high availability for a one-hour window
| Decision | Our choice for this workload | Why |
|---|---|---|
| Durability | RDB every 15 minutes, no AOF | The ledger is in PostgreSQL; a window can be rebuilt from the stream in minutes |
| Replication | one replica per primary, in another zone | failover without data rebuild; dashboards read replicas with READONLY |
| Failover | cluster-managed, cluster-node-timeout tuned to the network | no external coordinator to operate |
| Disaster recovery | second cluster in another region, rebuilt from the event stream | cross-region replication adds latency the scoring path cannot afford |
| Fork hygiene | snapshots staggered across primaries | one fork at a time per host keeps copy-on-write memory predictable |
The point is that persistence policy follows the data’s role. A Valkey that holds the system of record needs AOF with appendfsync everysec and tested restores; a Valkey that holds the last hour of analytics needs fast rebuilds and fast failover instead.
Valkey consulting and Valkey support: where we come in
Most of the incidents our Valkey consulting and Valkey support team sees in Valkey FinTech estates are design problems that surface as performance problems: a hot key nobody sharded, a function that loops, a trim that was exact instead of approximate, or an eviction policy that quietly dropped the data a decision depended on. The design above avoids each of them, but the right thresholds, window sizes and node counts come from your workload, measured.
- Architecture and keyspace reviews: data structure choice, hash tags, trim and TTL strategy, cluster sizing from measured slot statistics.
- Performance engineering: I/O thread and memory tuning, benchmark design, latency-tail analysis, migration from Redis to Valkey with measured before-and-after.
- 24×7 Valkey support for Valkey FinTech platforms: Severity 1 answered in 15 minutes by a named engineer, 24×7×365; Severity 2 in 12 hours, Severity 3 in 24, Severity 4 in 48.
- Managed operations: upgrades across the 9.x line, security releases applied on a cadence, failover drills, capacity reviews.
We are vendor-neutral: we support Valkey, Redis and the managed services built on them, and we will say so when a workload belongs in PostgreSQL or ClickHouse instead. See our Redis and Valkey support page, our earlier Valkey 9.1.2 tuning guide and our Valkey cluster design notes for FinTech. Primary sources: the Valkey 9.1 release announcement, the Valkey 9.0 announcement, the atomic slot migration documentation and the HEXPIRE command reference.
Frequently asked questions
Is Valkey real-time analytics suitable for FinTech?
Yes. Valkey real-time analytics fits the hot path: per-entity windows, rankings, cardinality and recent-event streams that must be read in under a few milliseconds. It is not the system of record; pair it with a durable database for the ledger and rebuild Valkey state from the event stream when needed.
What does Valkey 9.1 add over Valkey 8?
Building on 9.0’s hash field expiration, atomic slot migration and numbered databases in cluster mode, Valkey 9.1 adds a redesigned I/O threading model, faster stream and string operations, lower memory use for small strings and sorted sets, database-level ACL restrictions, the MSETEX and HGETDEL commands, CLUSTERSCAN, JSON logging and automatic TLS certificate reloading.
How do hash field expirations help a fraud system?
They turn a sliding window into one hash per card with one field per window, each field expiring exactly when its window ends. That removes per-window keys and trim logic, and lets a scorer read every live window with one HGETALL.
How does Valkey support scale a cluster without downtime?
Add primaries and move whole slots; our Valkey support engineers use CLUSTER MIGRATESLOTS, available since Valkey 9.0. The migration snapshots and syncs the slot, pauses writes to it briefly for the final delta, then transfers ownership, so clients see a single redirect rather than key-by-key churn.
Should we use AOF for an analytics cache?
Usually not. If the durable ledger lives elsewhere and the Valkey state covers a short window, periodic RDB snapshots plus replicas and a rebuild path from the event stream give faster recovery with less main-thread cost than AOF.
What does MinervaDB Valkey consulting cover?
Valkey consulting covers architecture and keyspace design, performance engineering, Redis-to-Valkey migrations, 24×7 incident response with a 15-minute Severity 1 target, managed upgrades across the 9.x line, security patching and capacity planning, for self-managed clusters and managed cloud services.
All configuration, commands, Lua and Python in this post are illustrative and pinned to Valkey 9.1.2; thresholds, sizes and event rates are examples, not recommendations for your workload. Test every change in a non-production environment first, rehearse failover and slot migration before relying on them, and maintain a robust disaster-recovery posture, including a tested rebuild path for in-memory state, before applying anything to production.
Designing or stabilising Valkey real-time analytics for payments? Book a working session with a MinervaDB Valkey principal engineer, or email contact@minervadb.com.
Running this in production?
MinervaDB provides Redis Support and NoSQL Database Support with 24x7 coverage and a 15-minute S1 response. Talk to an engineer.
