Jan Mikoláš
Cache-aside
Fast reads with a safe fallback
- Read a key with TTL
- Cache miss → source of truth
- Store a derived value
- Invalidate after a change
Back to skills
Experience
Redis
I use Redis for fast operational state and coordination. More important than the tool itself is a clear decision about what is cache and what remains the source of truth.
Fast data must not obscure system correctness.
In integration and backend services, I treat Redis as a complement to a relational database: for cache, short-lived data, counters, or process coordination. I do not put the only copy of business-critical data there without a deliberate design.
I account for TTL, invalidation, memory limits, and failure handling. For locks and scheduled jobs, I distinguish limiting concurrency from protecting the result against duplicate processing.
Not familiar with a term? Read a concise explanation in the glossary.
How I approach Redis
From a concrete problem to operationally safe use.
-
Cache
A copy of data, not a second database
I use cache only where data remain available from the source of truth. Changes need invalidation or refresh, and an outage needs a fallback without bringing down the application. -
TTL and limits
Predictable key lifetime
I name keys by responsibility, set an appropriate expiry, and monitor memory, evictions, and errors. TTL is a trade-off between freshness and load. -
Coordination
A short lock is not proof of a result
For coordinated jobs, I work with lock ownership and its lease. A synchronisation result still needs idempotent design and database rules outside Redis.
Responsibility split
Redis serves the fast layer, not business truth.
I choose a mechanism according to data and the cost of an error. Cache, rate limiting, and coordination have different requirements for expiry, recovery, and monitoring.
A Redis lock can limit concurrency. It does not guarantee exactly-once processing or replace database constraints and transactions.
Job coordination
Limit concurrency and protect the result
- Atomic acquire with TTL
- Unique owner token
- Short critical section
- Idempotent database result
Public example
Job scheduling and concurrency
Tools I use around Redis
Data, operations, and integrations
- Redis
- RedisInsight
- PostgreSQL
- Symfony
- Docker
- Monitoring
- PHPUnit
Do you need to speed up or coordinate a backend service?
I can help determine whether Redis is appropriate for a particular cache, limit, scheduled job, or integration flow — and what must remain in authoritative storage.