DEV Community: Sreekar Reddy

🧶 Dependency Hell Explained Like You're 5

Sreekar Reddy — Thu, 03 Sep 2026 23:52:03 +0000

When your packages disagree about versions

Day 155 of 155

The Recipe Chain Analogy

You install one package. It quietly brings its own shopping list, and every item on that list brings another.

you            -> chart-library ^2.0.0
you            -> form-library  ^3.0.0
chart-library  -> color-utils   ^1.0.0
form-library   -> color-utils   ^2.0.0

Two of your packages want color-utils. They disagree about which one.

That is dependency hell.

Direct vs Transitive

Direct: what you typed into package.json
Transitive: what your dependencies dragged in behind them

A short direct list usually expands into a much bigger installed tree.

A few dozen direct packages routinely resolve into many hundreds of entries in the lockfile.

Most of the code you ship was chosen by somebody else.

Ranges Are a Promise

^1.4.0 means "any 1.x from 1.4.0 upward". You are trusting each maintainer to judge correctly what counts as a breaking change.

Usually that works.

Sometimes a small release changes a default, and an install that resolves fresh today picks up a version that breaks you with nothing changed on your side.

A committed lockfile is exactly what stops that.

Lockfiles Freeze One Answer

A range describes a set of acceptable versions. A lockfile records which one you actually got, for every package in the tree.

npm install   # reconciles package.json with the lockfile
npm ci        # installs exactly what the lockfile says

Continuous integration should install with npm ci, so every build starts from the tree the lockfile describes.

In One Sentence

Dependency hell is what happens when packages you did not pick disagree about versions of packages you have not heard of.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

♻️ Build Caching Explained Like You're 5

Sreekar Reddy — Wed, 02 Sep 2026 23:54:09 +0000

Skip the work you already did

Day 154 of 155

👉 Full deep-dive with code examples

The Freezer Batch Analogy

You cook the same stock every Sunday. It takes hours.

So you freeze a batch and write the recipe on the label: ingredients, quantities, cooking time.

Next Sunday, check the label:

Label matches tonight's recipe → reheat it 🎉
Recipe changed → cook fresh, freeze it under a new label

The label is the cache key. The frozen batch is the cached output.

Why Builds Are Slow Without It

A fresh CI runner starts with an empty disk:

checkout → quick
install  → download every dependency again
build    → recompile every file again

Your dependencies did not change since yesterday. Most of your source files did not either.

The runner has no memory, so it repeats all of it 😫

The Cache Key

Hash the inputs, then look up the result.

key = hash(lockfile + toolchain version + OS + flags)

hit  → restore the output, skip the step
miss → do the work, save it under the new key

The rule: the key should cover every input that can change the output.

A Real Workflow

A typical Node CI workflow sets up every job the same way:

- uses: actions/setup-node@v7
  with:
    node-version: '22'
    cache: 'npm'

That restores npm's download cache, keyed on a hash of package-lock.json. The job still runs npm ci, but packages come off local disk instead of the network.

Change the lockfile and the key changes, so the next run installs fresh.

The Catch

A key that leaves out a real input hands you a stale result that looks correct. A slow pipeline is annoying; a wrong one costs you an afternoon.

In One Sentence

Build caching hashes the inputs of a step so a later run with matching inputs restores the stored output instead of redoing the work.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

🧵 Thread Safety Explained Like You're 5

Sreekar Reddy — Tue, 01 Sep 2026 23:51:26 +0000

Code that survives being run at once

Day 153 of 155

👉 Full deep-dive with code examples

The Shared Whiteboard Analogy

Two people keep a tally on one whiteboard. Each does three things: read the number, add one, write it back.

Alice reads 5
Bob   reads 5      <- Alice has not written yet
Alice writes 6
Bob   writes 6     <- the tally should say 7

An increment vanished. Nobody was careless. The steps just interleaved.

One Line, Three Steps

counter = counter + 1

One move? No, three: read counter, add 1, write it back.

A thread can be paused between any two, and that gap is where a race condition lives.

Here it costs you an increment, which is why this shape is called a lost update.

Races need two ingredients at once: state that is shared (several threads reach it) and mutable (someone writes it).

Remove either and the race usually goes away.

Ways Out, Cheapest First

Approach	Idea
Immutability	Produce new values, don't mutate
Confinement	Give each thread its own copy
Atomics	Read-modify-write in one go
Locks	Admit one thread at a time

A lock marks a critical section: the stretch where the invariant is temporarily false and nobody else should look.

with lock:
    counter = counter + 1

A Lock Is Not a Proof

The lock has to cover the whole invariant, not each line.

with lock:
    missing = key not in cache   # check
if missing:
    value = build(key)           # expensive, so keep it out of the lock
    with lock:
        cache[key] = value       # act

Every touch of cache is locked, and the bug survives: two threads can both see missing and both build.

A decision made under one lock is stale the moment that lock is released.

In One Sentence

Thread-safe code keeps its invariants true no matter how the scheduler interleaves the threads running it.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

🗝️ Distributed Locks Explained Like You're 5

Sreekar Reddy — Tue, 01 Sep 2026 01:02:25 +0000

One worker at a time across many machines

Day 152 of 155

👉 Full deep-dive with code examples

The Coffee Shop Key

One restroom, one key, tied to a wooden spoon so nobody pockets it. Whoever holds the spoon has the room; everyone else waits.

Now the awkward part: someone walks out still holding it, and the restroom stays shut all afternoon.

Distributed locks solve that with an expiry date.

Three Copies, One Job

Your nightly billing job runs on three instances for availability. At midnight all three wake up and start billing the same customers.

A language-level mutex will not help. Each process has its own memory. The lock has to live somewhere all three can see.

Taking the Key

One atomic operation that checks and claims together:

SET lock:billing worker-7 NX PX 45000

NX means "only if the key is absent" - the race is settled in one step.
The value worker-7 is your owner identity.
PX sets a lease, so a crashed holder does not block the job forever.

Release by comparing first, usually in a small Lua script so check and delete are one operation:

if redis.call("GET", KEYS[1]) == ARGV[1] then
  return redis.call("DEL", KEYS[1])
end

A plain DEL would wipe out someone else's lock once your lease had expired.

The Honest Limit

Your process can freeze - garbage collection, a network hiccup - after the lease expires and before your write lands.

The lock service took no part in that pause, so it cannot rescue you.

That is why careful systems add a fencing token: a number that increases on each acquisition, checked by the storage layer so a late writer is turned away.

Idempotence is a separate defence, not a stronger one. It stops a repeated operation from doing damage.

It does nothing about a stale one: if your delayed write sets qty = 6 while newer work already set qty = 4, replaying it safely still leaves the row wrong.

In One Sentence

A distributed lock is a shared, expiring claim that lets one worker act at a time, and it is only as safe as the resource behind it.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

🔒 Pessimistic Locking Explained Like You're 5

Sreekar Reddy — Mon, 31 Aug 2026 00:15:26 +0000

Lock the row before you touch it

Day 151 of 155

👉 Full deep-dive with code examples

The Fitting Room Analogy

A shop has one fitting room.

You take the garment in and the attendant hangs the "occupied" sign, so the next customer waits at the door rather than walking in on you.

Nobody has to sort out an awkward collision afterwards, because the collision was ruled out up front.

The cost is the queue: while you are deciding, everyone else stands still.

That is pessimistic locking. You claim the row before you touch it, and you pay for that certainty in waiting.

Lock At Read Time, Not Write Time

Two transactions want the same row. Two ways to keep them honest:

Optimistic: let both read, then catch the clash when the second writes.
Pessimistic: lock the row as you read it, so the second reader waits.

It assumes a collision is likely, so it prevents the fight instead of refereeing it afterwards.

SELECT ... FOR UPDATE

BEGIN;

SELECT stock FROM products
WHERE id = 42
FOR UPDATE;          -- row locked from here

UPDATE products SET stock = stock - 1
WHERE id = 42 AND stock > 0;   -- guard, or you sell stock you do not have

COMMIT;              -- lock released

At the common read-committed level, another transaction running that same query blocks until the COMMIT, then reads the decremented stock rather than the stale value.

The lock lives and dies with the transaction: commit or roll back, and it is gone.

What It Costs You

Waiting. And deadlocks: A holds row 1 and wants row 2 while B holds row 2 and wants row 1.

Databases usually detect that and abort one, so your code retries.

Keep them short. A lock held while a user decides, or while a slow API answers, turns that row into a queue for everybody.

In One Sentence

Pessimistic locking takes a lock on the row as you read it, so other transactions wait their turn instead of racing you to the write.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

🤞 Optimistic Locking Explained Like You're 5

Sreekar Reddy — Sat, 29 Aug 2026 23:56:13 +0000

Assume no conflict, check before saving

Day 150 of 155

👉 Full deep-dive with code examples

Two Waiters, One Ticket

Two waiters grab the same order ticket off the rail.

Waiter A writes "no onions"
Waiter B writes "extra cheese"
Waiter B pins his copy back last

Waiter A's note is gone, and nobody noticed 😱

That is the lost update problem.

The Same Thing in a Database

Alice reads row 42: note="", version=7
Bob   reads row 42: note="", version=7

Alice saves note="no onions"    -> row says "no onions"
Bob   saves note="extra cheese" -> row says "extra cheese"

Alice's edit vanished. The database did nothing wrong: it applied both writes in arrival order.

Attach a Version Marker

Optimistic locking assumes collisions are rare, so it locks nothing up front and checks at save time instead.

Keep a version column on the row, and send back the version you read:

UPDATE orders
SET note = 'extra cheese', version = version + 1
WHERE id = 42 AND version = 7;

If Alice saved first, the row is on version 8, the WHERE matches nothing, and zero rows are affected.

That zero tells Bob he lost the race.

On stricter isolation levels some engines raise a serialization error instead, so production code handles both.

The check and the write are one statement, so nothing can slip in between them.

What You Do On Conflict

Zero rows is information, not a crash. Pick a response:

Retry: refetch, reapply your change, save again
Merge: combine edits that touch different fields
Ask: tell the user "this record changed while you were editing"

Web APIs use the same trick with the HTTP ETag and If-Match headers.

In One Sentence

Optimistic locking lets everyone edit freely, then rejects any save whose version marker no longer matches the row.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

🔒 SSL/TLS Explained Like You're 5

Sreekar Reddy — Sat, 23 May 2026 22:55:02 +0000

Encrypting data between you and websites

Day 149 of 149

👉 Full deep-dive with code examples

The Sealed Envelope Analogy

Sending a postcard:

Everyone can read it (mail carriers, neighbors)
No privacy!

Sending a sealed, locked box:

Only the recipient has the key
Contents are private

SSL/TLS is the sealed box for your internet data!

It encrypts the data sent over the connection between your browser (client) and a website (server), protecting it while it travels across the network.

Why It Matters

Without SSL/TLS:

Passwords can be sent in plain text
Credit card numbers can be exposed
Someone who can observe the network may be able to read or change what you send
On public WiFi, attackers can potentially intercept traffic

With SSL/TLS:

Data sent over the connection is encrypted (and integrity-protected)
It helps prevent eavesdropping and tampering while data is in transit
Reduces risk on public WiFi (but it doesn’t stop a compromised device or server)

How You Know It's Working

Look for:

https:// (not http://)
Your browser indicating an encrypted connection
Certificate details in the site info/security UI

Note: a lock icon means the connection is encrypted and the certificate checks out — it doesn’t automatically mean the site itself is trustworthy.

How It Works (Simplified)

Handshake: Browser and server agree on encryption method
Certificates: Server proves its identity
Key exchange: They create a shared secret key
Encrypted connection: All data encrypted with that key

Think of it like:

Meeting someone, showing ID, agreeing on a secret code, then speaking in code!

SSL vs TLS

SSL: Old protocol family (legacy; SSL 2.0/3.0 are no longer recommended)
TLS: Modern protocol family (what we actually use today)
People still say "SSL" but mean TLS

TLS 1.3 is the newest widely deployed version, and TLS 1.2 is still commonly used.

In One Sentence

SSL/TLS encrypts data between your browser and websites, turning readable information into scrambled text that only you and the website can understand.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

⚡ Redis Explained Like You're 5

Sreekar Reddy — Fri, 22 May 2026 23:01:49 +0000

Super fast in-memory data store

Day 148 of 149

👉 Full deep-dive with code examples

The Sticky Note Analogy

Your desk has a drawer full of files (database) and sticky notes on your monitor (Redis):

Drawer: Organized, permanent, but slow to find things
Sticky notes: Right in front of you, instant access!

Redis is like sticky notes for your applications!

Super fast because data lives in memory, not on disk.

Why Redis Is Fast

Traditional databases:

Store data on disk (SSD/HDD)
Disk access is slow (milliseconds)

Redis:

Stores data in RAM (memory)
RAM access is fast (microseconds)
100x faster than disk!

What Redis Stores

Not just simple values:

Strings: Simple key-value pairs
Lists: Ordered collections
Sets: Unique items
Hashes: Objects with multiple fields
Sorted sets: Ranked data (leaderboards!)

Common Uses

Caching:

Store frequently accessed data
Avoid hitting slow database

Sessions:

User login sessions
Shopping carts

Real-time features:

Chat messages
Live notifications
Leaderboards

Rate limiting:

Track request counts
Block abusive users

The Trade-Off

Fast: In-memory is blazingly fast
Volatile: RAM can lose data on restart (though Redis can persist)
Limited size: RAM is more expensive than disk

In One Sentence

Redis is a super-fast in-memory data store used for caching, sessions, and real-time features where speed matters most.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

🚦 Rate Limiting Explained Like You're 5

Sreekar Reddy — Thu, 21 May 2026 23:04:31 +0000

Controlling how fast requests can be made

Day 147 of 149

👉 Full deep-dive with code examples

The Highway On-Ramp Analogy

Highway on-ramps have traffic lights:

Let one car through every few seconds
Prevents too many cars entering at once
Keeps highway traffic flowing smoothly

Rate Limiting is the traffic light for your API!

It controls how many requests can be made in a time period.

Why Rate Limit?

Without limits:

One user can make 1,000,000 requests/second
Server gets overwhelmed
Everyone suffers (slow or no service)
Attackers can crash your system

With limits:

Each user gets 100 requests/minute
Server stays healthy
Fair access for everyone
Protection from attacks

How It Works

Track requests per user/IP:

User Alice:
- Made 95 requests this minute
- Limit: 100/minute
- 5 remaining ✓

User Bob (attacker):
- Made 100 requests this minute
- Limit: 100/minute
- BLOCKED until next minute ✗

Common Strategies

Fixed window:

Reset counter every minute
Simple but can have edge-case bursts

Sliding window:

Rolling time window
Smoother limiting

Token bucket:

Tokens refill over time
Spend tokens to make requests
Allows short bursts

What Happens When Limited

Server returns HTTP 429 Too Many Requests:

"Slow down!"
Often includes "Retry-After" header
Tells you when to try again

In One Sentence

Rate Limiting controls how many requests users can make in a time period, protecting servers from overload and ensuring fair access for everyone.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

🤑 Greedy Algorithms Explained Like You're 5

Sreekar Reddy — Wed, 20 May 2026 23:15:25 +0000

Always pick the best option right now

Day 146 of 149

👉 Full deep-dive with code examples

The Coin Change Analogy

You owe someone $0.63 and want to use the fewest coins:

Greedy approach:

With common US coins (25¢, 10¢, 5¢, 1¢): 25¢ → 25¢ → 10¢ → 1¢ → 1¢ → 1¢ = 6 coins
Pick the largest coin that fits, then repeat

That's greedy!

At each step, pick what looks best RIGHT NOW without thinking ahead.

The Problem It Solves

Optimization problems have many choices:

"What's the shortest route?"
"How to fit most items in a bag?"
"Minimum number of steps?"

Checking all combinations can be too slow. Greedy gives a fast answer by repeatedly picking a locally optimal choice.

How It Works

Make a choice → Pick the best available option
Reduce the problem → New smaller problem remains
Repeat → Until problem is solved

No looking back, no reconsidering. Just greedy choices.

When Greedy Works

Classic cases where greedy is optimal (with proof):

Coin change (for some coin systems, like common US coins)
Activity scheduling (most non-overlapping events)
Huffman coding (compression)

Doesn't work for every problem:

Some problems need to look ahead
Greedy might miss the globally optimal solution

Greedy vs Dynamic Programming

Greedy	Dynamic Programming
Fast, simple	Slower, more complex
Local choices	Considers all options
May not be optimal	Can be optimal
Use when it provably works	Use when greedy fails

Note: Dynamic programming can produce an optimal answer when the problem has the right structure (like optimal substructure) and you model it correctly.

In One Sentence

Greedy Algorithms solve problems by picking the best available option at each step, which is fast but only works when local choices lead to a global solution.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

📇 Database Indexing Explained Like You're 5

Sreekar Reddy — Tue, 19 May 2026 23:03:40 +0000

Speed up queries with organized data pointers

Day 145 of 149

👉 Full deep-dive with code examples

The Library Card Catalog Analogy

Imagine finding a book in a library with no organization:

Walk through every aisle
Check every shelf
Look at every book until you find it

Now imagine the card catalog:

Look up the book by title or author
Get the exact shelf location
Go directly there!

Database indexing is like the library card catalog!

It creates a shortcut to find your data without scanning everything.

The Problem It Solves

Without indexing:

Database scans every row to find matches
1 million rows = 1 million checks
Slow queries that get slower as data grows

With indexing:

Database looks up the index first
Knows exactly where the data is
Fast queries even with millions of rows

How It Works

An index is a sorted structure pointing to data:

Index (sorted by name):          Actual Table:
Alice → Row 47        ──────→    Row 47: Alice, 30, Sydney
Bob → Row 12          ──────→    Row 12: Bob, 25, Melbourne
Carol → Row 89        ──────→    Row 89: Carol, 35, Perth

Finding "Carol"? Index points straight to row 89!

When To Use Indexes

Add indexes when:

Columns are used in WHERE clauses
Columns are used for sorting (ORDER BY)
Columns are used for joining tables

Don't over-index:

Indexes slow down writes (inserts, updates)
Each index takes storage space
Too many indexes = diminishing returns

In One Sentence

Database Indexing creates organized shortcuts to your data, turning slow full-table scans into fast direct lookups.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.

📱 Two-Factor Authentication Explained Like You're 5

Sreekar Reddy — Mon, 18 May 2026 23:04:35 +0000

Password plus your phone

Day 144 of 149

👉 Full deep-dive with code examples

The Bank Vault Analogy

To access a bank vault, you need:

A key (something you have)
A PIN code (something you know)

Having just one isn't enough. Someone who steals your key can't get in without the PIN.

Two-Factor Authentication (2FA) works the same way!

You need two different types of proof to log in.

Why Passwords Aren't Enough

Passwords can be:

Stolen → Attackers may get them from data breaches
Guessed → People use weak passwords
Phished → Fake websites trick you

With only a password, if someone gets it, they can often log in as you.

How 2FA Helps

Even if someone has your password, they still need the second factor:

Types of second factors:

Something you have:

Your phone (SMS code, authenticator app)
A security key (like YubiKey)

Something you are:

Fingerprint
Face recognition

Some systems also use extra signals (like location or device) to reduce risk, but the classic factor categories are: know / have / are.

How It Works

Enter username and password (first factor)
System asks for second factor
You provide a code from your phone or scan fingerprint
Both verified? You're in!

Password ✓ (something you know)
+
Phone code ✓ (something you have)
=
Access granted!

Why It's Important

Attacker gets your password → They may still be blocked
You lose your phone → They still need your password
Harder for attackers to have BOTH factors

Note: some 2FA methods (like SMS or one-time codes) can still be phished in real time. Phishing-resistant options include hardware security keys and passkeys (WebAuthn).

In One Sentence

Two-Factor Authentication requires two different types of proof to verify your identity, making accounts harder to compromise than password-only login.

🔗 Enjoying these? Follow for daily ELI5 explanations!

Making complex tech concepts simple, one day at a time.