A jonnify course
Redis Patterns,
Applied.
The judgement layer above the command reference — thirty Redis design patterns, each shown working in a real system. Taught as problem → solution → trade-off → when-to-use, then shown where the BCS architecture applies it.
The running system: EchoMQ backed by Valkey, Valkey under the hood, EchoStore in front. The worked examples are real keys, commands, and atomic Lua scripts — quoted verbatim from committed records, not plausible ones.
How to read this
the running system: the BCS buildEach chapter teaches a family of Redis patterns. A pattern is a single unit: the problem it solves, the Valkey structures and commands that solve it, the trade-off it accepts, and the workload it fits. The claim of the course is that knowing the commands is not enough — the same engineer reaches for a single-node “distributed lock” a failover silently breaks, or a fixed-window rate limiter with a boundary burst. The fix is grounding: every pattern is shown applied in a real system, so the worked example is verifiable.
The running system is the BCS build. EchoMQ is the bus between
systems, and it owns its protocol: the braced emq:{q}: keyspace, every Lua key declared or
root-derived, the wire version echomq:3.0.0 behind a two-way typed boot fence —
backed by Valkey, the current stable line, an enforced conformance gate. The atomic Lua
scripts are the protocol: a corpus of Redis patterns made owned, declared code.
EchoStore
is the near-cache in front of it — branded keys, an L1 of ETS tables over the shared L2 Valkey,
coherence by mint time. The worked consumer of both is the codemojex — the
trading system these patterns are applied inside (echo/apps/codemojex); where a chapter’s
deeper implementation belongs to the protocol itself, it doors forward to the dedicated EchoMQ course.
A scope note. The engine is Valkey — the current stable line, the substrate the EchoMQ connector is gated against. Where a pattern depends on a specific command, the lesson names it.
No pattern is taught in the abstract. Each one points at a committed artifact — the
braced emq:{q}: keyspace, the claim script, the four sorted sets, or an EchoStore figure
— quoted verbatim from the record.
The evidence ethic
committed outputs, quoted verbatimEvery claim in the course is backed by a committed record — a frozen transcript
quoted verbatim. A number that is not in a committed output does not appear on a page. The EchoMQ connector
— the production Valkey client at echo/apps/echo_wire — pipelines as its primitive:
fence claimed echomq:3.0.0 ← typed, fatal on mismatch sequential INCR 29456 ops/s pipelined SET 454483 ops/s ← fifteen times the sequential figure, same socket pipelined EVALSHA 161192 ops/s ← declared-keys law at speed script_loads 1 ← exactly one NOSCRIPT load 10000-command pipeline returned 1..10000 in order
The map
R1–R8 · sequenced along the EchoMQ buildThe full course, chapter by chapter. The patterns are sequenced along the EchoMQ build — coordination, then queues, then time, streams, flow, and operations — so the catalog doubles as a guided build of the BCS Redis tier. The module that closes each chapter is its workshop.
Caching
Open chapter →The read path: serving reads fast and keeping the cache consistent on writes. → EchoStore
Cache-aside (lazy loading)
On miss, fetch and populate; on write, invalidate.
Write-through
Write to cache and database synchronously so reads are fresh.
Write-behind (write-back)
Write to Valkey and sync to the database asynchronously.
Server-assisted client-side caching
Cache in app memory; the server pushes invalidations.
Cache stampede prevention
Stop a thundering herd regenerating one expired key.
Session management
Store sessions with TTL expiry.
Workshop
Cache the catalog tier end to end.
Coordination & Consistency
Open chapter →Atomicity first — the foundation every later chapter builds on. → EchoMQ
Atomic updates
Read-modify-write without a race; every state move is one inline Lua script.
Distributed locking
The claim lease and its attempts fencing token admit one holder.
The Redlock algorithm
A majority-of-N multi-master lock — a contrast with the single-Valkey lease.
Cross-shard consistency
Keep a multi-key change on one slot so it cannot tear.
Hash-tag co-location
Force related keys to one cluster slot — the hashtag is the queue name.
Workshop
Make an codemojex guess submission atomic across runtimes.
Reliable Queues
Open chapter →Wait, active, done, recover — the heart of EchoMQ, the densest grounding in the course. → EchoMQ
The processing list
Move a job out of pending into an in-flight roster, so a crash is recoverable.
At-least-once & idempotency
Delivery guarantees and why consumers must be idempotent.
Stalled-job recovery
Reclaim jobs whose worker died — one zset scan on the server’s clock.
The atomic state machine
The whole lifecycle as one Lua transition.
Blocking vs polling
Park, don’t poll — a waiting consumer costs zero commands.
Workshop
A reliable enrollment-job queue.
Time, Delay & Priority
Open chapter →The sorted set as a clock — a timer wheel and a priority ladder. → EchoMQ
The delayed queue
Score a job by its fire-time on the schedule set, sweep by score.
Schedulers & repeatable jobs
Recurring jobs via cron or interval, upserted without duplicates.
Priority with composite scores
Pack priority and arrival into one sorted-set score.
Backoff & retry
Exponential backoff with jitter on the schedule set.
Leaderboards
Real-time rankings with the same ZSET machinery.
Workshop
Schedule the notification and digest jobs.
Streams & Events
Open chapter →The durable log — observability and event-driven coordination. → EchoMQ
Event sourcing on Streams
The append-only log is the source of truth; state is its replay.
Stream consumer patterns
Block, batch, trim, resume; consumer groups.
Pub/Sub vs Streams
Fire-and-forget vs durable, and how to choose.
Custom events & projections
Domain events and windowed projections on one stream.
Workshop
A live activity feed.
Flow Control & Scale
Open chapter →Staying stable under load — limiting, fairness, batching, concurrency. → EchoMQ
Rate limiting
Fixed/sliding window and token/leaky bucket, enforced globally.
Fairness under load
Prevent starvation — the rota serves every lane in turn, weights tilt the share.
Groups & multi-tenant fairness
Round-robin fairness with a per-group semaphore.
Batches & pipelining
Bulk enqueue in one wire flush, with a per-item verdict for each job.
Worker concurrency
The per-claim fetch ceiling and how to plan capacity.
Workshop
Rate-limit and fairly schedule codemojex's API and jobs.
Data Modeling & Memory
Open chapter →How data lives in RAM — the modeling family and the BCS read-models.
Redis as a primary database
The store as the system of record, not a cache.
Memory optimization
Compact encodings and short fields.
Probabilistic data structures
Trade accuracy for memory — a contrast with exact dedup.
Bitmaps
Millions of boolean flags in minimal memory.
Vectors & similarity search
Redis 8 HNSW vector sets for semantic search.
Geospatial
Locations and radius queries on a geohash sorted set.
Workshop
The dashboard read-models.
Production & Operations
Open chapter →Running the tier at scale — case studies and operational discipline; the capstone. → EchoMQ
Linux kernel tuning
Kernel settings that prevent latency spikes and persistence failures.
Persistence, pooling & failover
Operating the store as a system of record in production.
Pinterest: task queues & partitioning
Functional partitioning and list-based reliable queues at scale.
Twitter/X: internals & custom structures
Customizations that became core.
Uber: resilience & staggered sharding
Staggered sharding, circuit breakers, graceful degradation.
Operating EchoMQ
Pooling, cluster co-location, metrics and tracing in production.
Capstone — the door to EchoMQ
What the dedicated EchoMQ course teaches next.
A module card becomes a link when its pages ship. R1–R4 are built; R5, R6, and R8 are opening; R7 is specified. The chapters are sequenced as the EchoMQ build, so the catalog doubles as a guided tour of the BCS Redis tier.
The doors
the sibling coursesEchoMQ — the protocol, in depth
The bus, taught rung by rung: the emq:{q}: keyspace, the Lua inventory, conformance on Valkey.
The Branded Component System
The architecture EchoMQ and EchoStore are built inside: systems, identities, the contract.
/elixirFunctional Programming in Elixir
The functional-Elixir and OTP craft behind the echo umbrella — where EchoMQ, EchoStore, and codemojex are built.
References
sources · relatedSources
- Redis — Documentationthe command reference and data-type guides the patterns draw on
- Valkey — Topicsthe engine the EchoMQ connector is gated against
- Valkey — ProgrammabilityEVALSHA, atomic scripts, the declared-keys discipline the bus rides
- llmstxt.org — the llms.txt conventionthe machine-readable map format the course follows
Related
- R0 — Overviewwhere Valkey sits in the BCS build, and the reading protocol
- R1 — Cachingthe read path, the first chapter
- EchoMQ — the coursethe protocol in depth, the far side of the door
- The Branded Component Systemthe architecture these patterns run inside