Redis & Caching for Java Services
Two hands-on days making a slow service fast for the right reasons — what to cache, where to put it, how to invalidate it, and how to prove the improvement. You leave with a cached service, a measured before and after, and a cache you can reason about under failure.
- Fee
- ₹2,700
- Duration
- 2 days · 16 hours
- Each day
- 09:00 - 17:00
- Mode
- Offline / Online
Designed for
- Backend developers whose endpoints are slow and who are guessing why
- Engineers who added a cache and then had to debug stale data
- Teams about to put Redis in front of a database for the first time
What to bring
- A laptop with Java, Docker and an IDE installed
- Experience building a REST API in any framework
- Basic SQL
What you walk away with
A service with a measured hot path, a cache that halves its response time, an invalidation strategy you can defend in review, and a demonstration that the service still works when Redis is switched off.
Outcomes
What you will be able to do
- 01Find the hot path with a measurement rather than an opinion
- 02Explain what should never be cached, and why
- 03Choose between cache-aside, read-through and write-through for a given case
- 04Set a time to live that reflects how stale the data may safely be
View all 9 outcomes
- Invalidate on write without leaving a window where readers see the old value
- Recognise and prevent a cache stampede
- Use Redis data structures beyond a string key, and know when each fits
- Keep the service working when the cache is unavailable
- Prove an improvement with a before-and-after measurement
The two days
8 hands-on sessions
2 days · 16 hours
- Foundation
- Intermediate
- Advanced
FoundationDay 1 - 09:00 - 10:30
Measure first
- where time actually goes in a request
- timing at the boundary and inside
- reading a SQL log
- p50 against p95 and why the average lies
- load generating a hot path
- deciding what is worth caching
- what must never be cached
What you will build
A slow endpoint profiled, with the responsible query named and its share of the response time measured.
Module 1
FoundationDay 1 - 09:00 - 10:30
Measure first
- where time actually goes in a request
- timing at the boundary and inside
- reading a SQL log
- p50 against p95 and why the average lies
- load generating a hot path
- deciding what is worth caching
- what must never be cached
What you will build
A slow endpoint profiled, with the responsible query named and its share of the response time measured.
Module 1
Book this workshop
This workshop runs on request, for individuals and for teams. Tell us the dates that would suit you.
Running this for a team?