I Built an OTP System with Redis… Then Realized TTL Wasn’t Enough 😭

Deval Ujeniya — Wed, 20 May 2026 07:16:59 +0000

I thought this would be a simple backend task.

Generate OTP → Store in Redis → Add expiration → Verify user.

Done.

My first implementation looked like this:

await redis.set(
  otpKey(phone),
  otp,
  "EX",
  60
);

OTP expires after 60 seconds.

Looks perfect.

Until I asked myself:

What actually stops someone from guessing forever?

Nothing 😭

Someone could still keep trying:

The OTP expires.

Brute force attempts do not.

That was the moment I realized:

TTL solves expiration.
TTL does NOT solve security.

Version 1: Store Only OTP

Initially Redis stored only:

"123456"

Simple.

But there was no information about:

Failed attempts
Blocking state
Verification behavior
Security tracking

So I changed the design.

Instead of storing only the OTP:

{
  "otp": "123456",
  "attempts": 0,
  "maxAttempts": 3,
  "blockedUntil": null
}

Redis stopped feeling like cache.

It started acting like a lightweight state engine.

Adding Brute Force Protection

Wrong OTP?

Increase attempts:

otpData.attempts++;

After 3 failures:

otpData.blockedUntil =
Date.now() + 60000;

Users are blocked for 60 seconds.

Problem solved.

Or at least…

That’s what I thought 😭

The Redis Bug I Didn’t Expect

When verification failed I updated Redis:

await redis.set(
   otpKey(phone),
   JSON.stringify(
      otpData
   ),
   "EX",
   60
);

Looks harmless.

But there was a hidden problem.

Imagine this:

OTP created
TTL = 60 sec
User fails at second 55
Redis updates state
TTL becomes 60 again

The OTP suddenly lives longer.

I accidentally extended authentication lifetime after every failed attempt.

Not ideal.

The Fix

Before updating Redis:

const ttl =
await redis.ttl(
   otpKey(phone)
);

Reuse remaining TTL:

await redis.set(
   otpKey(phone),
   JSON.stringify(
      otpData
   ),
   "EX",
   ttl
);

Now:

OTP created → 60 sec
User fails at second 55
Remaining TTL = 5
Redis update keeps TTL = 5

Expiration stays correct ✅

Biggest Lesson From This Project

I started with:

Redis = Cache

I finished with:

Redis = State Engine

TTL → Expiration

Attempts → Security

Blocking → Authentication logic

Redis became part of application behavior.

That was the biggest lesson.

Things I Want To Improve Next

1. Rate limiting per IP

Prevent OTP spam.

2. Redis Hashes

Avoid rewriting entire JSON objects.

3. Atomic updates

Current flow:

GET
↓
Modify
↓
SET

Possible improvements:

Transactions
WATCH / MULTI
Lua scripts

4. Handle race conditions

Two verification requests arriving together could create inconsistent state.

5. Add resend cooldown

Send OTP
↓
Wait 30 sec
↓
Allow resend

Final Thought

I started building:

OTP + Redis + TTL

I ended up learning:

Authentication design
State management
Expiration handling
Brute-force protection
Backend security

Small project.

Big Redis lesson.

Day 2 of learning Redis 🚀

If you’ve built OTP systems before:

Would you keep state in Redis?

Or move some logic elsewhere?

DEV Community: Deval Ujeniya