DEV Community: Yukesh Dhakal

Circuit Breaker Pattern

Yukesh Dhakal — Fri, 14 Aug 2026 04:34:25 +0000

Picture a service that depends on something external like another microservice, a database, or a third-party API. Most of the time, it works fine. But what happens when that dependency starts failing or, worse, starts hanging?

If every request takes 30 seconds to timeout, those requests start piling up. Threads and connections get tied up, latency increases, and eventually even unrelated requests can start slowing down. One small failure can then spread across the system and cause much bigger problems. This is called a cascading failure, and it's one of the problems the Circuit Breaker pattern is designed to help prevent.

The pattern gets its name from electrical circuit breakers. When too much current flows through a circuit, the breaker trips and cuts the connection to prevent further damage. It doesn't keep pushing power through a fault but it stops. The software version works in a similar way. A circuit breaker sits in front of a risky call and monitors its failures. If too many requests fail, it stops sending new requests to that dependency.

Instead of waiting 30 seconds for a timeout, the request fails immediately. This prevents wasted resources and helps stop the failure from spreading. After some time, it allows a few requests through to check if the dependency has recovered. If they succeed, everything goes back to normal. If they fail, the circuit opens again and waits before trying later.

States

The whole pattern comes down to three states:

Closed The normal state. Requests flow through as usual while failures are monitored. As long as they stay below the threshold, nothing changes.
Open Too many failures have occurred, so the breaker trips. New requests are stopped immediately instead of calling the failing dependency. The system can return an error or fallback instead.
Half-Open After a cooldown, the breaker cautiously allows a few requests through to check if the dependency has recovered. If they succeed, it goes back to Closed. If they fail, it returns to Open.

The Half-Open state is probably the most interesting part to me. It's not simply on or off but there's a small testing phase before the system fully trusts the dependency again.

Checking a single request

What stood out to me most is that a circuit breaker doesn't fix the underlying problem. If the dependency is down, it's still down. What it changes is how the rest of the system responds. Instead of every request waiting for the failing call to timeout, the failure stays contained to the part that's actually having trouble. It also gives room for a proper fallback. We could return cached data, a simpler response, or a clear message that the service is temporarily unavailable. And it helps the failing dependency recover too. If a database is already overloaded, constantly sending more retries to it is only going to make things worse. A circuit breaker gives the dependency some breathing room while protecting the rest of the system.

Before looking into it, I thought the Circuit Breaker pattern was one of those system design terms that gets thrown around without much explanation. Now it makes a lot more sense. The idea is pretty simple which is to stop calling something that's already struggling, fail fast, and carefully check again before trusting it.

How I Would Learn to Code in 2026 - For Newbie

Yukesh Dhakal — Fri, 18 Apr 2025 03:44:35 +0000

Nowadays, there’s a lot of noise about how AI will replace developers. But here’s the thing, it’s not going to replace every developer. It will replace those who stop learning, those who rely only on what they know, and those who just "vibe code" without knowing anything.

If I were to start my developer journey in 2025 aiming for growth in 2026, I would approach it with intention and structure. Coding has definitely become more accessible, thanks to better tools and resources. But that doesn’t mean you can skip the fundamentals. If anything, they matter even more now.

"Mastering the basics isn’t just a phase — it’s a forever skill."

When you truly understand the core principles, you can adapt to change, evolve with tools, and even stand out in the future.

So How Do I Start?

If I were starting today, I’d go all in on javascript first. Not just copy-pasting from StackOverflow or ChatGPT but really learning how variables, loops, functions, and objects work. Why? Because once you understand how code flows and how logic works, every other tool or framework becomes easier.

A great way to internalize these ideas is by making games. It might sound silly at first, but building something like Snake, Tetris, or a simple quiz app forces you to think logically, solve problems, and understand the DOM (which is essential in web development).

My Suggested Roadmap

Here’s a visual breakdown of how I’d learn the fundamentals of web development if I were beginning now:

You can follow this in chunks over weeks/months depending on your pace. Don’t rush it. Learn, revisit, and build.

Lastly,

Don't fear AI. Use it, but don’t depend on it.

Learn how code works, not just what to write.

Build small things. Games, tools, clones — anything that makes you solve problems.

JavaScript is still the king of the browser — don’t skip it.

Fundamentals over frameworks, always.

Stay consistent. Even 30 mins a day is better than none.

I’ll be sharing more tips, insights, and stories from my journey soon.
If you’re just getting started or even just thinking about getting into tech, feel free to drop your thoughts below. I’d love to connect and chat!

Until then, keep learning. Keep building!

Why I Decided to Start Blogging...

Yukesh Dhakal — Mon, 14 Apr 2025 03:29:18 +0000

I’m currently in a phase of my life where I want to explore new things. I’m trying to upskill, not just for better opportunities, but to genuinely become better at something I care about.

When I started my journey with IT and everything related to it, I honestly had no idea what I was getting into. It felt overwhelming at first. I remember the early days when I joined college and I barely knew anything. It’s kind of funny looking back now, but my only association was with Java back then, which was through the game Minecraft. That was literally all I knew about programming.

And yet, here I am today, writing my first blog post on a tech platform, hoping to share a bit of my experience so far.

“It’s okay to not know everything when you start. What matters is that you start anyway.”

The main reason I’m starting this blog is actually for myself. I’m curious and excited about trying something new. If along the way I can also share something helpful, something that resonates with someone else then that’s a big win.

And if you’re reading this, I hope a part of my journey feels familiar to you too.