DEV Community: Arman Phaugat

712 Problems Later: What 500+ Days of DSA Really Taught Me

Arman Phaugat — Wed, 04 Feb 2026 06:28:17 +0000

When I started solving DSA problems, I didn’t plan to reach 700+.

I just wanted to get better.

One problem a day.

That was the goal.

Today, my stats look like this:

712 problems solved

1,030 submissions in the past year

325 active days

124 days max streak

500 Days Badge

455 Medium problems

29 Hard problems

But the numbers aren’t the story.

The journey is.

The First 100 Problems – Excitement Phase

The beginning is fun.

You solve Easy array problems.
You feel smart.
You think interviews will be easy.

Then Medium problems hit.

Sliding window?
Binary search on answer?
Monotonic stack?

That’s when confidence drops.

But that’s also where real growth starts.

200–400 Problems – Pattern Recognition Begins

Somewhere after 200 problems, something changes.

You stop seeing random questions.

You start seeing:

“This is just two pointers.”

“This is a variation of prefix sum.”

“This smells like a monotonic stack.”

You don’t panic anymore.

You analyze.

That shift is powerful.

400–600 Problems – Discipline > Motivation

This is where most people quit.

Not because problems are hard.

But because consistency is hard.

325 active days means I showed up almost every day.

Not always 5 problems.
Sometimes just 1.

But I showed up.

Even when:

College assignments were heavy

Projects were pending

I didn’t feel like solving anything

Streaks build discipline.
Discipline builds skill.

The 124-Day Streak

124 days in a row.

That wasn’t about ego.

It was about identity.

I stopped asking:
“Should I solve today?”

It became:
“I solve daily.”

Small difference.
Massive impact.

The Reality About Hard Problems

Only 29 Hard problems solved.

And that’s okay.

Because:

Medium builds foundation

Hard tests depth

Hard problems forced me to:

Think longer

Break problems into parts

Analyze time complexity carefully

They humbled me.

And I needed that.

What 1,030 Submissions Actually Means

It means:

I failed.

I debugged.

I optimized.

I resubmitted.

A lot.

DSA isn’t about getting AC in first try.

It’s about thinking until something clicks.

How This Changed My Backend Thinking

When I optimized my /leaderboard API from 200ms to 20ms,
that mindset came from DSA.

Because DSA trains you to ask:

What’s the time complexity?

Can I reduce this from O(n²) to O(n)?

Can I remove unnecessary operations?

Am I making N+1 calls?

That optimization mindset didn’t come from tutorials.

It came from solving hundreds of problems.

The Biggest Lesson

Consistency beats intensity.

712 problems didn’t happen in one summer.

They happened because I showed up 325 days.

Some days:
1 problem.

Some days:
5 problems.

But never zero for too long.

Where I Am Now

I’m not perfect.

I still get stuck.
I still struggle with DP.
I still spend 30 minutes staring at problems.

But now I don’t doubt myself.

Because I’ve built proof.

712 pieces of proof.

Final Thought

If you’re starting DSA:

Don’t aim for 1000 problems.

Aim for tomorrow.

Solve one.

Then repeat.

The streak builds.
The patterns form.
The confidence follows.

**And one day, you’ll look back and realize—

You didn’t just learn DSA.

You trained your brain to think differently.**

Using Redis to Optimize Backend Queries

Arman Phaugat — Wed, 04 Feb 2026 06:12:59 +0000

How I Optimized My /leaderboard API from 200ms to 20ms Using Redis

Performance issues don’t usually scream at you.

They whisper.

My /leaderboard endpoint was one of those whispers.

It worked.
It returned the top 10 players correctly.
But under load… it felt slow.

Around ~200ms per request.

Not terrible.

But not great either.

And as someone building backend systems, I knew this would eventually become a bottleneck.

So I decided to fix it.

The Original Approach (The Comfortable One)

The endpoint logic was simple:

Query database

Sort users by score

Return top 10

Classic.

SELECT * FROM users ORDER BY score DESC LIMIT 10;

With proper indexing, it worked fine at small scale.

But leaderboards are:

Frequently accessed

Frequently updated

Competitive, real-time data

And hitting the database every single time didn’t feel right.

I needed something faster.

First Attempt: Let’s Use Redis

Redis felt like the perfect fit.

In-memory.
Fast.
Built for ranking.

But here’s the twist.

Redis wasn’t even working.

When I tried starting it locally, I got:

Error: Address already in use

Port 6379 was already occupied.

I tried restarting services.
Killing processes.
Nothing clean worked.

Instead of wasting more time debugging system-level conflicts, I decided to isolate it properly.

The Fix: Dockerizing Redis

I ran:

docker run -d -p 6379:6379 --name redis-server redis

And that solved everything instantly.

Now Redis was:

Isolated

Portable

Cleanly running

Easy to restart

Sometimes the real optimization is fixing your environment first.

Now I could finally move forward.

Enter Sorted Sets (ZSET)

Redis has a powerful data structure called Sorted Sets (ZSET).

Each entry has:

A member (user ID)

A score (points)

Redis automatically keeps them sorted by score.

That meant I no longer needed:

SQL sorting

ORDER BY queries

Heavy DB reads

When a user’s score updates:

await redis.zadd("leaderboard", score, userId);

To fetch top 10:

await redis.zrevrange("leaderboard", 0, 9, "WITHSCORES");

Now the ranking logic lived entirely in memory.

Latency improved immediately.

But something still felt off.

The Hidden Bottleneck I Didn’t See Coming

After fetching the top 10 user IDs, I needed user details:

username

avatar

level

metadata

So I wrote:

for (let userId of topUsers) {
await redis.hgetall(user:${userId});
}

It worked.

But performance wasn’t where I expected it to be.

Then it hit me.

I had recreated the N+1 problem.

Not in the database.

In Redis.

Here’s what was happening:

**1 request → fetch leaderboard

10 requests → fetch each user

That’s 11 network round trips.**

Even if Redis responds in microseconds, network latency doesn’t.

That’s where my missing 100ms was hiding.

The Real Fix: Redis Pipelining

Redis supports pipelining.

Instead of:

request → response
request → response
request → response

You send all commands together and receive all responses together.

So I rewrote it:

_**const pipeline = redis.pipeline();

for (let userId of topUsers) {
pipeline.hgetall(user:${userId});
}

const users = await pipeline.exec();**_

Now:

Only 1 network round trip

All commands executed in batch

No more N+1 latency

This was the real breakthrough.

The Results

Here’s how it evolved:

Stage Latency
DB sorting ~200ms
Redis (no pipeline) ~120ms
Redis + pipeline ~20ms

A full 10x improvement.

And interestingly, the biggest win wasn’t just using Redis.

It was reducing network round trips.

What This Taught Me

Infrastructure problems come first

If Redis isn’t running cleanly, nothing else matters.

Data structures matter

ZSET eliminated repeated sorting completely.

N+1 problems aren’t just database issues

They can happen in any remote system.

Network latency is invisible — but expensive

Even “fast” systems become slow when you talk to them too many times.

Docker simplifies backend life

Instead of fighting your OS, containerize dependencies.

Final Architecture

Now the /leaderboard flow looks like this:

Score update → ZADD

Fetch top 10 → ZREVRANGE

Batch fetch user data → pipeline + exec

Return response

No DB hit.
Fully in-memory.
Minimal network calls.
~20ms response time.

Clean.

Closing Thought

Optimization isn’t about throwing tools at a problem.

It’s about identifying where time is actually being spent.

For me, it wasn’t just the database.

It was:

The environment

The data structure

And the network

And fixing those made all the difference.