Then I started thinking about promo codes.

Specifically, I started thinking about what happens when a promo code has only one use left and two users hit the checkout button at the exact same time.

That question sent me down a rabbit hole that every backend engineer needs to understand: race conditions in concurrent systems, and how to choose between optimistic locking and pessimistic locking.

What Is a Race Condition?

A race condition happens when two or more processes access shared data at the same time, and the final result depends on the order in which they execute — producing incorrect behavior.

In our promo code scenario:

promo_codes table:
  code = "EMRAS20"
  usage_limit = 1
  used_count  = 0

Without any protection, this can happen:

Time  |  User A                          |  User B
------|----------------------------------|----------------------------------
T1    |  SELECT * FROM promo_codes       |
      |  WHERE code = 'EMRAS20'          |
      |  → used_count = 0, limit = 1 ✅  |
T2    |                                  |  SELECT * FROM promo_codes
      |                                  |  WHERE code = 'EMRAS20'
      |                                  |  → used_count = 0, limit = 1 ✅
T3    |  Places order, increments count  |
      |  UPDATE SET used_count = 1       |
T4    |                                  |  Places order, increments count
      |                                  |  UPDATE SET used_count = 2 ❌

Both users successfully applied a promo code that was supposed to be used only once. The business loses money. No exception was thrown. No error appeared in the logs.

This is the scariest kind of bug — silent data corruption.

Why This Is a Real Problem

You might think: "Who would have two users hit checkout at the exact same millisecond?"

More people than you think.

• Flash sales where hundreds of users rush checkout simultaneously

• Bots scanning for valid promo codes

• Users double-clicking the checkout button

• Mobile app retries on slow network

At scale, even a 0.01% collision rate on a platform with 10,000 daily orders means 1 corrupted promo code per day. Over a month that's real money — and real trust — lost.

The Two Solutions: Optimistic vs Pessimistic Locking

When I hit this problem, I had two choices. Let me explain both properly.

Option 1 — Optimistic Locking

Optimistic locking assumes conflicts are rare. It doesn't lock the row upfront. Instead, it tracks a version number on every row. When you update a row, you check that the version hasn't changed since you read it. If it has, someone else updated it first — your transaction fails and you retry.

Database level:

ALTER TABLE promo_codes ADD COLUMN version BIGINT DEFAULT 0;

JPA entity:

@Entity
@Table(name = "promo_codes")
public class PromoCode {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Version  // ← This is all it takes
    private Long version;

    private int usedCount;
    private Integer usageLimit;

    // ... other fields
}

How it works at runtime:

User A reads:  { id: 1, used_count: 0, version: 0 }
User B reads:  { id: 1, used_count: 0, version: 0 }

User A updates:
  UPDATE promo_codes
  SET used_count = 1, version = 1
  WHERE id = 1 AND version = 0  ← checks version matches
  → 1 row affected ✅

User B updates:
  UPDATE promo_codes
  SET used_count = 1, version = 1
  WHERE id = 1 AND version = 0  ← version is now 1, not 0!
  → 0 rows affected ❌
  → JPA throws OptimisticLockException

In Spring Boot:

@Service
public class OrderServiceImpl {

    @Transactional
    public OrderResponse placeOrder(Long userId, PlaceOrderRequest request) {
        try {
            PromoCode promo = promoCodeRepository
                .findByCodeIgnoreCase(request.getPromoCode())
                .orElseThrow(() -> new BusinessException("Invalid promo code"));

            if (!promo.isApplicable(subtotal)) {
                throw new BusinessException("Promo code not applicable");
            }

            promo.incrementUsage();
            promoCodeRepository.save(promo); // throws OptimisticLockException if version mismatch

            // ... rest of order placement

        } catch (OptimisticLockException | ObjectOptimisticLockingFailureException e) {
            throw new BusinessException(
                "This promo code was just used by someone else. Please try again.",
                "PROMO_CONFLICT",
                HttpStatus.CONFLICT
            );
        }
    }
}

Pros:

• No database locks held — very high throughput

• Scales well with many concurrent users

• Works well when conflicts are genuinely rare

Cons:

• User gets an error and must retry

• Requires retry logic or clear user messaging

• Can fail repeatedly under very high contention

Option 2 — Pessimistic Locking

Pessimistic locking assumes conflicts are likely. It locks the row at the database level the moment you read it. Every other transaction that tries to read that row must wait until the lock is released.

public interface PromoCodeRepository extends JpaRepository<PromoCode, Long> {

    // Normal read — no lock
    Optional<PromoCode> findByCodeIgnoreCase(String code);

    // Locked read — for use during actual order placement
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT p FROM PromoCode p WHERE LOWER(p.code) = LOWER(:code)")
    Optional<PromoCode> findByCodeForUpdate(@Param("code") String code);
}

How it works at runtime:

User A calls findByCodeForUpdate("EMRAS20")
  → PostgreSQL executes: SELECT ... FOR UPDATE
  → Row is LOCKED

User B calls findByCodeForUpdate("EMRAS20")
  → PostgreSQL: row is locked, B must WAIT

User A validates → increments usedCount → commits
  → LOCK RELEASED

User B continues (lock released)
  → reads updated row: used_count = 1, limit = 1
  → isUsageLimitReached() = true
  → throws BusinessException: "This promo code has reached its usage limit"
  → User B gets a proper error message ✅

In Spring Boot — full implementation:

@Service
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService {

    private final PromoCodeRepository promoCodeRepository;

    @Transactional  // ← IMPORTANT: lock is held for the entire transaction
    public OrderResponse placeOrder(Long userId, PlaceOrderRequest request) {

        // ... validate cart, address, payment method ...

        BigDecimal subtotal = cart.getSubtotal();
        BigDecimal discountAmount = BigDecimal.ZERO;
        PromoCode promoCode = null;

        if (request.getPromoCode() != null && !request.getPromoCode().isBlank()) {

            // Use the LOCKED version — not the regular findByCodeIgnoreCase
            promoCode = promoCodeRepository
                .findByCodeForUpdate(request.getPromoCode())  // ← SELECT ... FOR UPDATE
                .orElseThrow(() -> new BusinessException(
                    "Invalid promo code",
                    "PROMO_INVALID",
                    HttpStatus.BAD_REQUEST
                ));

            // At this point, the row is locked.
            // Any concurrent request trying to use this promo code WAITS here.

            if (promoCode.isExpired()) {
                throw new BusinessException(
                    "This promo code has expired",
                    "PROMO_EXPIRED",
                    HttpStatus.BAD_REQUEST
                );
            }

            if (promoCode.isUsageLimitReached()) {
                // This is what User B sees after User A commits
                throw new BusinessException(
                    "This promo code has reached its usage limit",
                    "PROMO_LIMIT_REACHED",
                    HttpStatus.BAD_REQUEST
                );
            }

            if (subtotal.compareTo(promoCode.getMinOrderAmount()) < 0) {
                throw new BusinessException(
                    "Minimum order amount not met for this promo code",
                    "PROMO_MIN_NOT_MET",
                    HttpStatus.BAD_REQUEST
                );
            }

            discountAmount = promoCode.calculateDiscount(subtotal);
        }

        // ... build order, deduct stock, save order ...

        // Increment usage BEFORE committing
        // Lock is released when @Transactional commits at method end
        if (promoCode != null) {
            promoCode.incrementUsage();
            promoCodeRepository.save(promoCode);
        }

        cartFacade.clearCart(userId);
        return toResponse(order);

        // Transaction commits here → lock on promo_codes row is released
    }
}

Key insight: The @Transactional boundary is everything. The lock is held from findByCodeForUpdate until the method returns and the transaction commits. During that entire window, no other transaction can read or modify that row.

Pros:

• Guarantees exactly one winner — no retry needed

• Simple to reason about — the second user always gets a clear error

• No version column needed in the schema

Cons:

• Locks are held longer — lower throughput under high load

• Risk of deadlocks if multiple resources are locked in wrong order

• Not ideal for very high traffic (thousands of concurrent checkouts)

How I Chose: Why Pessimistic Locking Was Right for Emras

This is the question I sat with for a while. Both are valid — the choice depends on your system's characteristics.

Here's the decision framework I used:

1. How frequent are conflicts?

Promo codes with low usage limits (1, 5, 10 uses) will have frequent conflicts during promotions. Optimistic locking would cause many users to get retry errors during a flash sale — bad UX.

→ Pessimistic locking wins for low-limit promo codes.

2. How long is the critical section?

In placeOrder, we lock the promo code row but the method also deducts stock, saves the order, and clears the cart. The lock is held for maybe 50-100ms in total. That's acceptable — we're not doing any slow external API calls inside the transaction.

→ Pessimistic locking is safe when the transaction is short.

3. What's the user experience on failure?

With optimistic locking, User B gets: "Conflict — please retry." With pessimistic locking, User B gets: "This promo code has reached its usage limit."

The second message is clearer and more honest.

→ Pessimistic locking wins on UX.

4. What's the expected scale?

Emras is a clothing store for Bangladesh — not Amazon. Thousands of concurrent checkouts at the exact same millisecond is not a realistic scenario. If we ever scale to that level, we'd introduce a distributed job queue (like Redis + Kafka) for promo code redemption anyway.

→ Pessimistic locking is appropriate at this scale.

The Rule of Thumb

Low conflict probability + High throughput needed  →  Optimistic Locking
High conflict probability + Correctness is critical →  Pessimistic Locking

For financial data, inventory, and promo codes — correctness always beats throughput. Use pessimistic locking.

The Other Race Condition I Found: Stock Deduction

Once I started thinking about promo codes, I checked our stock deduction logic too.

Our ProductVariantRepository had this query:

@Modifying
@Query("""
    UPDATE ProductVariant pv
    SET pv.stockQuantity = pv.stockQuantity - :qty
    WHERE pv.id = :id
    AND pv.stockQuantity >= :qty
    """)
int deductStock(@Param("id") Long id, @Param("qty") int qty);

This is actually safe by design — it's an atomic SQL operation. The AND pv.stockQuantity >= :qty check and the decrement happen in the same statement at the database level. PostgreSQL handles this atomically.

If stock is 1 and two users both try to buy 1 unit:

User A: UPDATE ... WHERE stockQuantity >= 1 → stockQuantity = 0 → 1 row affected ✅
User B: UPDATE ... WHERE stockQuantity >= 1 → stockQuantity = 0, fails condition → 0 rows affected

We check the return value (0 rows = conflict) and throw an exception:

@Override
@Transactional
public void deductStock(Long variantId, int quantity) {
    int rowsUpdated = variantRepository.deductStock(variantId, quantity);
    if (rowsUpdated == 0) {
        throw new BusinessException(
            "Insufficient stock for the requested quantity",
            "CART_INSUFFICIENT_STOCK",
            HttpStatus.CONFLICT
        );
    }
}

This is the correct way to handle stock deduction — single atomic SQL statement, no separate read-then-write, no locking needed.

What I Learned

Building Emras taught me that race conditions are invisible until they cost you. Here's what I took away:

1. Always ask: "What if two requests hit this at the same time?" For any write operation involving shared data (promo codes, stock, wallet balance, seat reservations), this question is mandatory.

2. Prefer atomic SQL operations where possible UPDATE ... WHERE quantity >= required is safer than SELECT → check → UPDATE because it reduces the window for race conditions.

3. For resource reservation, pessimistic locking is your friend When the business impact of a conflict is high (double-spending promo codes, overselling inventory), pay the small throughput cost for correctness.

4. Keep transactions short when holding locks Don't make external API calls inside a transaction that holds a database lock. Send emails after commit, not during.

5. Optimistic locking shines for profile updates, settings, non-critical data If two users update their profile bio at the same time, an optimistic lock conflict is fine — one just retries. The stakes are low.

Final Architecture

Here's how the complete promo code flow looks in our final implementation:

POST /api/v1/orders
        ↓
OrderController.placeOrder()
        ↓
@Transactional OrderServiceImpl.placeOrder()
        │
        ├── cartFacade.isCartEmpty()        → CartServiceImpl
        ├── cartFacade.getCartSummary()     → CartServiceImpl
        │
        ├── promoCodeRepository             ← SELECT FOR UPDATE (row locked)
        │     .findByCodeForUpdate()           No other transaction can touch this row
        │
        ├── promo.isApplicable() checks     ← if any fail, exception thrown, lock released
        │
        ├── productFacade.deductStock()     ← atomic UPDATE WHERE qty >= required
        │
        ├── orderRepository.save()          ← INSERT order + items
        │
        ├── promoCode.incrementUsage()      ← UPDATE promo, version++
        │     promoCodeRepository.save()
        │
        ├── cartFacade.clearCart()          ← cart emptied
        │
        └── COMMIT                          ← lock released here

Clean, safe, and correct.

Conclusion

The Emras promo code race condition was a reminder that correctness in concurrent systems requires deliberate design. It doesn't fix itself, and it doesn't always fail loudly.

If you're building any system where:

• Multiple users can claim a limited resource simultaneously

• Financial data is involved

• Inventory can be oversold

Stop and ask yourself: "What happens if two requests arrive at the same millisecond?"

Then pick your locking strategy accordingly.

If you've ever watched your API response times crawl under load and thought "there must be a better way" — Redis is that better way. In this post, I'll walk you through a production-ready Spring Boot project I built to explore everything Redis can do: declarative caching, raw data structures, Pub/Sub messaging, rate limiting, and session management.

By the end, you'll understand not just how to wire Redis into Spring Boot, but why each piece works — and what traps to avoid along the way.

🔗 Full source code: github.com/Rifat-Tipu/Redis_Implementation

What Are We Building?

A Spring Boot app backed by PostgreSQL (source of truth) and Redis (cache layer), with a live benchmark endpoint that shows you the speed difference in real time:

A Quick Redis Primer

Redis (Remote Dictionary Server) is an open-source, in-memory data store that doubles as a cache, message broker, and streaming engine. Its key strengths:

• ⚡ Blazing fast — data lives in RAM, sub-millisecond latency

• 🧩 Rich data types — Strings, Hashes, Lists, Sets, Sorted Sets

• ⏰ TTL support — keys auto-expire (perfect for caches and sessions)

• 📡 Pub/Sub — native publish/subscribe messaging

• 🔒 Atomic operations — thread-safe commands enable safe concurrency

Architecture Overview

The request flow is straightforward: every read hits Redis first. Only on a cache miss does the app fall through to PostgreSQL.

CLIENT (Browser / curl)
    │
    ▼
┌─────────────────────────────────────────────────────────────┐
│                      Spring Boot App                         │
│                                                             │
│  ┌──────────────────┐     ┌─────────────────────────────┐  │
│  │    Controller    │────▶│     Redis (Cache Layer)      │  │
│  │    Service       │◀────│  @Cacheable / CacheManager   │  │
│  │  @Cacheable etc. │     └─────────────────────────────┘  │
│  └────────┬─────────┘       ↑ HIT: return instantly        │
│           │                  ↓ MISS: continue to DB below   │
│  ┌────────▼─────────┐                                       │
│  │   Repository     │  ← Spring Data JPA                    │
│  └────────┬─────────┘                                       │
└───────────┼─────────────────────────────────────────────────┘
            ▼
   ┌─────────────────┐
   │   PostgreSQL    │  ← Source of truth
   └─────────────────┘

Project Structure

spring-boot-redis/
├── src/main/java/com/example/redis/
│   ├── config/
│   │   ├── RedisConfig.java           # RedisTemplate + CacheManager beans
│   │   └── PubSubConfig.java          # Channel topics + listener container
│   ├── model/
│   │   └── Product.java               # JPA @Entity
│   ├── repository/
│   │   └── ProductRepository.java     # Spring Data JPA
│   ├── service/
│   │   ├── ProductService.java        # @Cacheable / @CachePut / @CacheEvict
│   │   ├── RedisDataStructureService.java
│   │   ├── RateLimitService.java
│   │   ├── RedisMessagePublisher.java
│   │   └── RedisMessageSubscriber.java
│   └── controller/
│       ├── ProductController.java
│       ├── BenchmarkController.java   # ⏱️ The star of the show
│       ├── RedisController.java
│       └── PubSubController.java
├── docker-compose.yml
└── pom.xml

Quick Start

Prerequisites

• Java 17+, Maven 3.8+, Docker

1. Clone and spin up infrastructure

git clone https://github.com/Rifat-Tipu/Redis_Implementation.git
cd Redis_Implementation
docker-compose up -d

This brings up:

• PostgreSQL on localhost:5432

• Redis on localhost:6379

• Redis Commander (web UI) on http://localhost:8081

2. Run the app

mvn spring-boot:run

3. See the speed difference live

# First call — cache MISS, hits PostgreSQL
curl http://localhost:8080/api/benchmark/product/1
# { "source": "PostgreSQL (cache MISS)", "timeMs": 504 }

# Second call — cache HIT, served from Redis
curl http://localhost:8080/api/benchmark/product/1
# { "source": "Redis (cache HIT)", "timeMs": 2 }

That 250x speed difference isn't a trick. It's just what happens when RAM replaces disk I/O.

Core Concept 1: Declarative Caching with @Cacheable

Spring's caching abstraction makes caching declarative — just annotate your service method:

@Cacheable(value = "products", key = "#id")
public Optional<Product> findById(Long id) {
    // This method body only executes on cache MISS
    // On HIT, Spring returns the cached value and skips this entirely
    return productRepository.findById(id);
}

The Cache Miss → Hit Lifecycle

First call (MISS):

1. Spring checks Redis for key products::1 → not found

2. Method executes, hits PostgreSQL

3. Result stored in Redis with a 10-minute TTL

4. Response returned to client

Second call (HIT):

1. Spring checks Redis for key products::1 → found!

2. PostgreSQL is never called. The method body never runs.

3. Cached result returned in ~1ms

The Three Caching Annotations

// Update: refresh cache after saving
@CachePut(value = "products", key = "#id")
public Optional<Product> update(Long id, Product p) { ... }

// Delete: remove from cache after deleting from DB
@CacheEvict(value = "products", key = "#id")
public boolean delete(Long id) { ... }

// Nuclear option: clear everything
@CacheEvict(value = "products", allEntries = true)
public void clearCache() { ... }

Cache Key Strategies

💡 The hardest part of caching isn't getting data in — it's knowing when to evict. A stale list cache is a subtle bug that's easy to miss. Use @CacheEvict on every write path.

Core Concept 2: RedisTemplate & Data Structures

When you need direct control beyond @Cacheable, RedisTemplate<String, Object> gives you the full Redis API:

redisTemplate.opsForValue()   // Strings
redisTemplate.opsForHash()    // Hashes
redisTemplate.opsForList()    // Lists
redisTemplate.opsForSet()     // Sets
redisTemplate.opsForZSet()    // Sorted Sets

Strings — counters, tokens, simple values

// Store with TTL
redisTemplate.opsForValue().set("session:abc", userObject, Duration.ofMinutes(30));

// Atomic counter — thread-safe, no locking needed
Long views = redisTemplate.opsForValue().increment("page:views");

Best for: page counters, feature flags, session tokens, cached primitives

Hashes — field/value maps

redisTemplate.opsForHash().putAll("user:42", Map.of(
    "name",  "Alice",
    "email", "alice@example.com",
    "role",  "ADMIN"
));

// Read a single field without fetching the whole object
String email = (String) redisTemplate.opsForHash().get("user:42", "email");

Best for: user profiles, configuration objects, anything with partial updates

Lists — ordered sequences

// Queue (FIFO): push right, pop left
redisTemplate.opsForList().rightPush("task:queue", task);
Object next = redisTemplate.opsForList().leftPop("task:queue");

// Stack (LIFO): push right, pop right
Object latest = redisTemplate.opsForList().rightPop("events");

Best for: job queues, activity feeds, recent items

Sets — unique, unordered

redisTemplate.opsForSet().add("online:users", "alice", "bob", "carol");
boolean isOnline = redisTemplate.opsForSet().isMember("online:users", "alice");

Best for: unique visitor tracking, tag systems, membership checks

Sorted Sets — scored rankings

redisTemplate.opsForZSet().add("leaderboard", "Alice", 9500);
redisTemplate.opsForZSet().add("leaderboard", "Bob",   12000);

// Top 3, highest score first
Set<Object> top3 = redisTemplate.opsForZSet().reverseRange("leaderboard", 0, 2);

// Atomically increment score
redisTemplate.opsForZSet().incrementScore("leaderboard", "Alice", 500);

Best for: leaderboards, priority queues, time-series data

Core Concept 3: Publish / Subscribe

Redis Pub/Sub lets services broadcast messages to each other without direct coupling. The publisher fires and forgets; all active subscribers receive it.

Publisher ──convertAndSend()──▶ Redis Channel ──▶ Subscriber.receiveMessage()

Publisher:

redisTemplate.convertAndSend("notifications", "Order #1234 placed!");

Subscriber (Spring wires this up automatically):

public void receiveMessage(String message) {
    log.info("Received: {}", message);
    // forward, persist, or trigger downstream logic
}

Configuration:

container.addMessageListener(listenerAdapter, new ChannelTopic("notifications"));

⚠️ Important gotcha: Redis Pub/Sub is fire-and-forget. If no subscriber is online when you publish, the message is gone. For guaranteed delivery, use Redis Streams or move to RabbitMQ/Kafka.

Real-world uses: stock price updates, live notifications, cache invalidation signals, microservice event broadcasting.

Core Concept 4: Rate Limiting

The Redis-idiomatic rate limiter uses an atomic counter with a sliding TTL window:

Request arrives
     │
     ▼
INCR rate_limit:{clientId}   ← atomic, thread-safe
     │
     ├── If count == 1 → EXPIRE rate_limit:{clientId} 60  (start the window)
     │
     └── If count ≤ 10 → ✅ Allow
         If count >  10 → ❌ 429 Too Many Requests

public boolean isAllowed(String clientId) {
    String key   = "rate_limit:" + clientId;
    Long   count = redisTemplate.opsForValue().increment(key);

    if (count == 1) {
        redisTemplate.expire(key, 60, TimeUnit.SECONDS);
    }
    return count <= 10;
}

Why not GET → check → SET? Because that has a race condition — two concurrent requests can both read 9, both think they're allowed, and both increment to 10. INCR is atomic at the Redis level: each call returns the post-increment value, exactly once, even under concurrent load.

Configuration Reference

# PostgreSQL
spring.datasource.url=jdbc:postgresql://localhost:5432/redis_demo
spring.datasource.username=postgres
spring.datasource.password=postgres
spring.jpa.show-sql=true          # On cache HIT, you'll see zero SQL here

# Redis
spring.data.redis.host=localhost
spring.data.redis.port=6379

# Connection pool (Lettuce)
spring.data.redis.lettuce.pool.max-active=10
spring.data.redis.lettuce.pool.min-idle=1

# Cache TTL (10 minutes)
spring.cache.redis.time-to-live=600000

# Spring Session
spring.session.store-type=redis
spring.session.timeout=30m

💡 Enable spring.jpa.show-sql=true during development — on a cache hit, you'll see no SQL queries at all. That's the most visceral way to confirm Redis is doing its job.

Key Learnings from Building This

1. Cache invalidation is the hard part. Getting data into Redis is trivial. The real skill is deciding when to evict — especially for list caches, where a single item change makes the whole list stale.

2. Serialization matters more than you think. Java's default serialization makes keys unreadable in Redis Commander and breaks silently if you rename a class. Switch to Jackson2JsonRedisSerializer from day one.

3. INCR + EXPIRE is the elegant rate limiter pattern. My first attempt with GET → check → SET had a race condition under load. The INCR-first pattern is inherently atomic.

4. Pub/Sub is fire-and-forget by design. Don't use it where message durability matters. Use Redis Streams or a proper message broker instead.

5. Connection pooling matters in production. Lettuce's defaults aren't tuned for high concurrency. Set max-active and max-wait before you go live, or you'll hit connection exhaustion at the worst moment.

REST API Summary

Benchmark

Products (CRUD with caching)

Redis Data Structures

Pub/Sub & Rate Limiting

Tech Stack

• Spring Boot 3.2 — application framework

• PostgreSQL 15 — relational database (source of truth)

• Spring Data Redis + Lettuce — non-blocking Redis client

• Spring Cache — declarative caching (@Cacheable etc.)

• Spring Session — Redis-backed distributed sessions

• Jackson — JSON serialization for Redis values

• Docker Compose — PostgreSQL + Redis + Redis Commander

Wrapping Up

Redis isn't just a cache — it's a toolkit. Once you understand the data structures and their semantics, you start seeing use cases everywhere: rate limiting, leaderboards, session stores, real-time messaging, job queues.

The benchmark endpoint is the most satisfying part of this project. Watching a request drop from 504ms to 2ms on the second call makes the theory click in a way that docs never quite do.

If you found this useful, the full source is at github.com/Rifat-Tipu/Redis_Implementation. Feel free to clone it, break things, and experiment.

Tags: redis spring-boot java caching backend tutorial