DEV Community: yusuf yonturk

I Added a Cache and the System Got Slower: The Hidden Cost of Caching

yusuf yonturk — Sun, 11 Jan 2026 20:09:13 +0000

Caching is often marketed as a free performance boost: drop in Redis, flip a flag, and enjoy instant speed. In reality, a cache is another network hop, another moving part, and another place where a request can get stuck or time out under load.

The “easy win” that wasn’t

We had a hot endpoint running close to its limits, so we put a cache in front of it. The expectation was simple: fewer database hits and dramatically lower latency.

What actually showed up in the graphs:

p95 latency went up instead of down.
“Fast locally, slow in prod” became something we said almost every day.
Incidents became harder to reason about, because every request now had two potential bottlenecks: the cache or the origin.

The code looked clean, the cache dashboards were green, but the user experience was clearly worse.

Where the slowdown really came from

Cache hits still cost something

Even on a hit, you pay for:

A network round trip to the cache (if it’s remote).
Serialization and deserialization.
Connection pooling, TLS, retries, and all the overhead around them.

On a well‑indexed, already‑warm database, this extra hop can actually be more expensive than just running the original query.

Misses can be double work

On a miss, the “simple” read path often turns into:

GET from cache → miss
Fetch from origin
SET into cache

If the data changes frequently or isn’t reused much, you’ve just added extra work to almost every request. The hit‑rate chart might not look terrible, but most of the real cost is hiding on the miss path.

Stampede and churn

When a popular key expires, a lot of requests can pile onto the origin at once. That thundering herd effect can send p95 through the roof exactly when the system is under its heaviest load.

Short TTLs plus high‑cardinality keys are another kind of tax. If entries are constantly being evicted, the cache stops behaving like a cache and turns into an expensive pass‑through layer you touch on every request.

When the cache becomes the bottleneck

When the remote cache service slows down or runs out of resources, the application is dragged down with it. In those moments:

App logs may not show a clear error.
But APM starts showing “external call” time dominating the whole request.
You’ve basically traded “the DB is slow” days for “the cache is slow” days.

How to tell if your cache is really helping

First, measure the cache as if it were its own service:

cache_hit_rate (per endpoint or key group)
cache_get_ms and cache_set_ms (p50 / p95 / p99)
origin_ms
request_total_ms
cache_timeouts and cache_errors

Then run a small experiment:

Bypass the cache for 5–10% of traffic and compare p95/p99.
Look at end‑to‑end latency for both the hit path and the miss path.

If the hit path is not clearly cheaper than calling the origin, your cache is just an expensive layer of complexity.

The changes that actually helped

Without throwing the cache away completely, these changes made a real difference:

Cache less, but smarter: Only cache reads that are both expensive and reusable.
Store smaller objects: Cache a minimal DTO instead of a huge, fully hydrated object graph.
Use request coalescing / single‑flight: For the same key, collapse concurrent requests so only one goes to the origin.
Add TTL jitter: Keep things from expiring all at once and reduce the risk of a stampede.
Use stale‑while‑revalidate: Serve slightly stale but fast data while refreshing the cache in the background.
Set tight timeouts and intentional fallbacks: Don’t let cache timeouts dictate your entire API’s latency.

Once these were in place, the cache finally started acting like a performance layer instead of “just another production problem.”

Which part of this story feels most familiar to you? The thundering herd, the disappointing hit rate, or the “we did everything right, so why is p95 still bad?” question? Drop your own cache war stories in the comments—they’re basically tiny post‑mortems that help the next person avoid the same mess.

Bug of the week: what was the root cause?

yusuf yonturk — Sat, 10 Jan 2026 08:15:35 +0000

Not a highlight reel — just one thing that went a bit better than last week.

Quick poll (pick one)

[ ] Shipped something
[x] Fixed a bug
[ ] Learned something
[ ] Career progress (interview/CV/networking)
[ ] Rested / avoided burnout

Mine

Win: Fixed a bug that was wasting my time, and I wrote down the root cause + the exact fix so I won’t repeat it.
Next week: I’ll ship one small improvement end-to-end and add a couple of basic tests for the part that broke.

Your turn 👇

Win + next week. Two lines max.

If you were a junior in 2026, what would you build first to get hired?

yusuf yonturk — Thu, 01 Jan 2026 10:30:48 +0000

Quick discussion post.

If you were starting from scratch in 2026 and could build only one thing to help you get hired, what would you build first?

I’m not asking for “the perfect project”. I’m curious what signals matter most right now.

Quick poll (pick one)

[ ] A clone (Netflix/Twitter/Spotify style)
[ ] A small real product (one problem, solved well)
[ ] A technical demo (one skill, shown deeply)
[ ] Open-source contributions (PRs + collaboration)

Why that choice?

When someone says “build a project”, it can mean different goals:

“Can you ship something end-to-end?”
“Do you have depth in one area?”
“Can you collaborate with others?”

Which one matters most to you in 2026?

What matters more than the idea?

If you review junior portfolios (or you’ve been hired recently), what’s the #1 thing you pay attention to?

A live demo (deployed)
A clear README (setup + decisions)
UI/UX polish
Tests
Performance details
Security basics
Code quality

Your turn

1) What would you build first to get hired? (1–2 sentences)

2) What’s the #1 thing you look for in a junior portfolio?

I Tried a 7-Day Dopamine Detox: The Hardest Part Wasn’t What I Expected

yusuf yonturk — Mon, 29 Dec 2025 17:51:33 +0000

I thought the hardest part would be not touching my phone.

It wasn’t.

The real challenge started after I removed the obvious distractions, because my brain immediately tried to replace them with “reasonable” ones: small tasks, quick checks, tiny errands, and endless context switching that felt productive in the moment.

This post is a honest breakdown of my 7-day reset, what actually hurt, what helped, and what I’m keeping long term.

What I mean by “dopamine detox”

I’m not claiming you can “remove dopamine” or that dopamine is the enemy.

For me, “dopamine detox” means reducing high-stimulation, variable-reward inputs during the hours I want focus, so deep work doesn’t feel unbearable.

Dopamine Detox

In practice that meant:

No infinite feeds during my focus window.
No “just one quick check” loops.
Less novelty on demand.

The setup (so this was realistic)

I didn’t do monk mode. I didn’t disappear for a week.

I set one daily focus window: 90 minutes. That was the only non-negotiable.
Outside of that window, I lived normally.

My rules during the focus window:

Phone out of reach.
Notifications off.
No social feeds.
No random browsing unless it truly blocked the task.

Day 1–2: The first surprise

Day 1 felt easy because it was new.

Day 2 is where the bargaining started.

Without the phone, I expected “focus.” Instead I got friction:

Starting felt heavier.
Boredom felt louder.
My brain tried to escape without calling it escape.

That’s when I realized I wasn’t addicted to my phone.
I was addicted to relief.

The hardest part (what I didn’t expect)

The hardest part was staying with discomfort long enough for it to pass.

Not the big discomfort. The tiny one:

“This is unclear.”
“I might do this wrong.”
“This is boring.”
“I don’t know the next step.”

That tiny discomfort is where I used to context switch.
And context switching was the real “dopamine hit” for me: a new tab, a new idea, a new micro-task, a new reset.

What actually worked (my simple system)

I used a very small system that doesn’t require motivation.

1) Define the next action before you start

Before the 90-minute window, I wrote one sentence:

“In this session I will…”

Examples:

“Fix the failing test and push the patch.”
“Write the outline and the intro paragraph.”
“Implement the endpoint and cover the happy path.”

If the next step isn’t clear, the brain will find a distraction to avoid that uncertainty.

2) Use an “urge list” instead of willpower

When I felt the urge to switch tasks, I wrote it down on a note:

“Check X”
“Look up Y”
“Reply to Z”
“Refactor A”

Then I told myself: not now. After the block.

Most urges didn’t survive 20 minutes.
They just wanted attention.

3) One tab rule for research

Research is a legit need for developers, but it’s also a trap.

If I truly needed info:

Open one tab.
Get the answer.
Close it.
Return to the task.

No branching into 10 tabs. No “while I’m here…”

4) End the session with a clean landing

At the end of the 90 minutes I wrote:

What I finished.
What the next step is tomorrow.

This reduced the “starting pain” the next day, which reduced my need to escape.

What changed by Day 6–7

By the end of the week:

Starting became easier.
I could stay on one task longer.
I felt less mentally scattered at the end of the day.

The most important change wasn’t “more work done.”
It was feeling like I was driving again, not just reacting.

What I’m keeping long term

I’m not keeping a strict detox forever.

I’m keeping:

One daily focus window.
Phone out of reach during it.
The urge list.
Clear next action before starting.

Simple, repeatable, boring. That’s the point.

My biggest trap was “just one quick tab.” What’s yours?

How Dopamine Detox Made Me a Better Developer

yusuf yonturk — Fri, 26 Dec 2025 15:05:32 +0000

A lot of “dopamine detox” advice sounds like it was written for someone who doesn’t ship code, doesn’t have deadlines, and can disappear for a week.

That’s not most of us.

I’m a software engineer, but I’m writing this for developers who feel stuck in the loop: you open your laptop to build, and somehow you end up scrolling, context-switching, or “just checking one thing” until the day is gone.

This isn’t a purity challenge. It’s a reset you can do while still working.

First: what I mean by “dopamine detox”

I’m not claiming you can (or should) “remove dopamine.” Dopamine is part of how motivation and learning work.

What I mean is simpler: you reduce the constant high-stimulation inputs that train your brain to expect instant reward, so deep work stops feeling painfully boring.

For developers, the biggest culprits usually aren’t parties and sugar. It’s this combo:

Infinite feeds (short video, social timelines, news)
Fast novelty (tabs, Slack, notifications, “quick research”)
Micro-rewards (checking analytics, GitHub, email, DMs)

The rule that makes this workable

You don’t need to remove fun. You need to remove random fun during the hours you want focus.

So we use one rule for 7 days:
During your chosen “focus window,” no variable-reward apps.

That means: no social feeds, no short videos, no news, no doom-scrolling. Outside the window, you can still live your life.

The 7-day plan

Pick a daily focus window you can actually keep. Start with 60 to 120 minutes depending on your schedule. If your day is chaotic, stick to 60.

Day 1: Baseline + one focus window

Today is measurement, not discipline theater.

Choose a focus window (same time tomorrow, if possible).
Turn off non-essential notifications on phone and desktop.
Write down your “default escape apps” (be honest).
At the end of the day, answer one question: “When I avoided work today, what was I avoiding?”

Day 2: Replace the trigger, not just the app

Most scrolling starts from a trigger: friction, confusion, or boredom.
Before your focus window, prepare a tiny “next action” so you don’t open a tab to figure out what to do.

Examples:

“Open repo → run tests → fix failing test”
“Write function signature + TODO list”
“Draft 5 bullet points for the article intro”

If you sit down and the first step is unclear, your brain will negotiate its way to YouTube.

Day 3: Make distraction harder (2-minute setup)

Use friction like a tool.

Log out of social apps on desktop.
Remove the apps from your phone’s home screen.
Put your phone in another room during the focus window.

This isn’t about willpower. It’s about reducing the “oops, I’m here again” moments.

Day 4: Introduce “boring on purpose” breaks

When you remove high-stim inputs, your brain will demand a replacement. Give it a boring one.
During breaks, choose one:

A short walk
Stretching
Tea/coffee without a screen
Staring out the window (seriously)

The point is to let your attention settle instead of re-spiking it.

Day 5: Build a focus ritual you can repeat

Make the start of deep work automatic. My minimal ritual:

Clear desk (takes 30 seconds).
Put headphones on.
Open only the tools I need (IDE + one doc).
Set a timer for 45 minutes.
Then I write a one-line intention in a note: “In this session I will…”

You’re teaching your brain: “This is what focus feels like.”

Day 6: Add a “no context switching” rule

This is the day most developers notice a difference.
During your focus window:

No Slack/Teams.
No email.
No “quick look” at GitHub/Twitter/Reddit.
No browsing “just to confirm something” unless it blocks you.

If you truly need to research, do it intentionally: open one tab, get the answer, close it.

Day 7: Keep the gains (without becoming extreme)

You’re not trying to live like this forever. You’re trying to reclaim choice.
Pick your long-term settings:

Keep one daily focus window as a non-negotiable.
Keep notifications off by default.
Schedule “scroll time” like dessert, not like breathing.

What changes you should expect (and what’s normal)

Day 2–3: Focus feels harder, boredom feels louder. That’s normal.
Day 4–5: You start noticing you can “stay with the problem” longer.
Day 6–7: You get a weird moment of clarity: you realize how often you were escaping the smallest discomfort.

Also normal: you’ll fail a day. Don’t restart. Continue. The goal is trend, not perfection.

A practical “developer” metric

If you like measurable stuff, track one number for 7 days:
How many times did I context switch during my focus window?

A context switch is any of these:

Opening a feed
Checking messages
Switching tasks without finishing the current step

Try to reduce that number, not eliminate it.

I’m curious about your version of this problem

What’s your #1 distraction when you sit down to code? Or if you’ve tried anything like a dopamine detox before: what actually worked, and what was nonsense?

Let’s discuss in the comments 👇

Why I Cache External API Data Instead of Calling It Every Time

yusuf yonturk — Thu, 25 Dec 2025 02:53:19 +0000

Calling external APIs directly feels clean... until your system hits real traffic.
When I first started integrating external APIs into my projects, my approach was simple:

Need data?
Call the API.

It felt clean, logical, and completely fine.
Until real usage hit.

The naive approach (what I did first)

The initial setup looked like this:

Client
↓
API Gateway
↓
External API

Every request triggered:

a fresh API call
a network round-trip
dependency on someone else’s uptime

For low traffic, this felt clean and straightforward.

But real usage exposed the cracks very quickly.

What went wrong

1. Cost scales faster than traffic

Many APIs charge per request.

What looks cheap at first becomes expensive once background jobs, retries, and traffic spikes enter the picture.

2. Rate limits become architecture limits

Once you hit rate limits:

features fail
errors propagate
defensive code spreads everywhere

Your system starts being shaped by someone else’s rules.

3. Latency adds up

Even fast external APIs are:

network-bound
unpredictable
outside your control

The shift: treat APIs as data sources, not live dependencies

Instead of calling the external API on demand, I switched to this model:

Worker / Cron
↓
External API
↓
Database

Client
↓
API Gateway
↓
Backend Service
↓
Database

External APIs are called periodically.

The application reads from the database.("not the API")

What I gained

1. Predictable costs

No surprise bills. No hidden usage spikes. Just controlled API consumption.

2. Faster responses

Database reads are faster and easier to optimize.

3. Isolation from external failures

If the API goes down, my system keeps working with the last known good data.

But doesn’t data get stale?

Yes... and that’s the point.

The real question is not “Is the data fresh?”

It’s “How fresh does it need to be?”

Freshness is a business decision, not a reflex.

When direct API calls actually make sense

Real-time financial transactions
Authentication & authorization
User-triggered actions where freshness is critical

Since then, I’ve been much more intentional about when an external API is part of the request path and when it shouldn’t be.

That single change has simplified more architectural decisions than any framework ever did.