DEV Community: Archit Agarwal

Reddit's Karma Score Is a Lie. Here's the Math Behind It.

Archit Agarwal — Mon, 11 May 2026 03:00:00 +0000

Two comments. Same subreddit. Same topic. Posted minutes apart.

One has +847 karma. It sits at the top, gets gilded, spawns a thread of 200 replies. The person who wrote it gets DMs. Their next post gets upvoted reflexively because people remember the name.

The other has +1. It exists somewhere below the fold, unseen by 99% of readers. Same words, different fate.

That number — Reddit karma — is one of the most consequential invisible forces on the internet. It shapes what millions of people read, what opinions gain traction, whose voices carry weight in a community. And most Reddit users have a vague sense of how it works: upvotes good, downvotes bad, net score determines visibility.

What almost nobody knows is what's actually happening inside Reddit's infrastructure every time someone clicks that arrow.

The score you see? It's a lie. Not a malicious one. A mathematically necessary, deliberately constructed approximation — and the algorithm behind it is one of the most elegant ideas in distributed systems.

This is that story.

What Reddit Karma Actually Is

Let's start simple, because the simple version matters.

Every post and comment on Reddit has a score. That score is calculated as:

Score = Upvotes − Downvotes

A post with 1,200 upvotes and 200 downvotes shows a score of +1,000. A comment with 50 upvotes and 80 downvotes shows -30. Reddit uses this score to rank content — higher scores float up, lower scores sink. In highly active subreddits, the first few minutes of score accumulation can determine whether a post reaches the front page or disappears forever.

The score also feeds into account-level karma, which affects posting privileges, community credibility, and how other users perceive you before they've read a single word you've written.

Simple math. Massive consequences.

Now let's build the system that computes it.

The Simple Version (That Works Fine Until It Doesn't)

Imagine Reddit in its early days. A few thousand users. One web server. One database.

The schema for tracking votes is straightforward:

CREATE TABLE post_scores (
    post_id   BIGINT PRIMARY KEY,
    score     INT DEFAULT 0
);

When someone upvotes:

UPDATE post_scores SET score = score + 1 WHERE post_id = ?;

When someone downvotes:

UPDATE post_scores SET score = score - 1 WHERE post_id = ?;

User loads the page, you return score. Done.

This works beautifully for a small community. Your database handles concurrent updates with row-level locking. Reads are fast. Writes are fast. The score is always accurate.

And then the site grows.

The Moment Everything Gets Complicated

Reddit today serves over 50 million daily active users. Popular posts on r/worldnews or r/AskReddit can accumulate thousands of votes in minutes. During major news events, that number spikes even higher.

One database server cannot handle that write throughput. So you do what every scaling team eventually does — you distribute.

You spin up multiple database replicas. You deploy servers in the US, Europe, and Asia so votes from each region get handled locally. Latency drops. Throughput goes up. Everything seems fine.

Until two servers try to update the same post's score at the same time.

Here's the problem in its simplest form. The US server reads the score: 142. The EU server reads the score: 142. A user in the US clicks upvote — the US server wants to write 143. Simultaneously, a user in Europe clicks downvote — the EU server wants to write 141.

Both writes land. One of them overwrites the other. A real vote disappears.

At small scale this is a rounding error. At Reddit scale, with thousands of concurrent votes per second on a single viral post, you're losing a meaningful number of real votes from real users. Users who clicked an arrow and expected their opinion to count.

Let's be honest — this is not a hypothetical. This is the exact class of problem that has caused production incidents at companies you use every day.

The Approaches That Don't Work

The instinct is to reach for coordination. Make the servers talk to each other before writing.

Distributed locks: before updating the score, acquire a lock on that post's row across all replicas. Only one server writes at a time. Others wait.

This works. It's also slow. Lock acquisition across data centres separated by hundreds of milliseconds of network latency adds that latency to every single vote. During peak traffic, lock contention turns your vote system into a queue. Users notice.

Two-phase commit (2PC): a coordinator server proposes the write, all participants acknowledge, then the coordinator commits. Guarantees consistency across all nodes.

Also works. Also slow. 2PC requires multiple round trips between servers. It assumes all participants are available — if any node is down or unreachable during the commit phase, the transaction blocks. In a system operating across multiple continents, "all participants available" is never guaranteed.

Both approaches trade availability for consistency. That's a valid trade-off in some systems. For a vote counter on a social platform — where a few hundred milliseconds of delay on every click would be immediately noticeable and wildly unacceptable — it's not.

There had to be a better way.

A Different Question

The distributed systems community eventually asked a different question.

Instead of "how do we make all servers agree before writing?" — what if we asked: "what constraints can we place on the data so that disagreements become impossible?"

This line of thinking led to CRDTs — Conflict-free Replicated Data Types. Data structures specifically designed so that concurrent updates on multiple replicas can always be merged correctly, without coordination, without locks, without consensus rounds.

The key insight: if you design your data structure such that the merge operation is always unambiguous — no matter what order updates arrive, no matter how long replicas were disconnected — you get eventual consistency for free.

I covered the simplest CRDT — the G-Counter — in Episode 1 of this series. The short version: each replica keeps its own local count, only ever increments it, and merge means "take the maximum per replica." YouTube's view counter works this way. There's no conflict possible because a count that can only grow is always unambiguous — the higher number is always more up to date.

But G-Counters have an obvious limitation.

They only go up.

Why Upvotes Alone Aren't Enough

Reddit's score isn't a count of upvotes. It's upvotes minus downvotes. You need both directions.

A G-Counter can track upvotes fine. But downvotes require decrement. And decrement is where things get complicated — because "subtract one" from a shared counter across distributed replicas brings back exactly the ambiguity we were trying to avoid.

Two servers both see the score as 50. Both receive a downvote simultaneously. Both want to write 49. Same lost vote problem as before, just through a different door.

So: we need increment and decrement, without coordination, with correct merging across replicas.

Here's where things get interesting.

The Insight: You Never Actually Decrement

This is the moment the whole thing clicks.

What if you never decremented anything? What if every downvote was secretly an increment — just to a different counter?

Go back to the lemonade stand mental model. You and your friends are tracking the cash register. Money comes in from customers. Money goes out for supplies. You need to track both.

You already know the G-Counter trick: give everyone a notebook where they can only add tally marks. Works for money coming in.

For money going out, the solution is almost embarrassingly simple: give everyone two notebooks.

A green notebook for every dollar that came in
A red notebook for every dollar that went out

Neither notebook ever loses a mark. Both only ever grow. At the end of the day, you sync the green notebooks (take max per person), sync the red notebooks (take max per person), and do one subtraction:

Green total − Red total = what's in the register

That's a PN-Counter. Positive-Negative Counter.

Two G-Counters. One subtraction at read time. No coordination. No locks.

The "decrement" you thought you needed was never a real operation. It was always just an increment to a second counter that you subtract when you read the value. The counter doesn't go down — your accounting does.

The Code

gotype PNCounter struct {
    inc GCounter
    dec GCounter
}

func NewPNCounter() PNCounter {
    return PNCounter{
        inc: Zero(),
        dec: Zero(),
    }
}

Two G-Counters. That's the entire data structure.
Reading the score:

func (p PNCounter) Value() int64 {
    return p.inc.Value() - p.dec.Value()
}

The subtraction only happens here — at read time, when someone loads the page. Never during updates. Never during merges.

Upvoting:

func (p PNCounter) Inc(r ReplicaId) PNCounter {
    return PNCounter{
        inc: p.inc.Inc(r),
        dec: p.dec,
    }
}

Downvoting:

func (p PNCounter) Dec(r ReplicaId) PNCounter {
    return PNCounter{
        inc: p.inc,
        dec: p.dec.Inc(r),
    }
}

Look at Dec. It doesn't subtract anything. It calls .Inc() on the decrement counter.

A downvote is an upvote to the wrong notebook.

If you showed this to someone without context they'd think it was a bug. It's the entire algorithm.

Merging two replicas:

func MergePN(a, b PNCounter) PNCounter {
    return PNCounter{
        inc: Merge(a.inc, b.inc),
        dec: Merge(a.dec, b.dec),
    }
}

Run the G-Counter merge twice — once on the increment counters, once on the decrement counters. Same "take the maximum per replica" logic. Nothing new to prove. Everything PN-Counter needs, it inherits from G-Counter.

What This Looks Like on Reddit's Servers

Let's trace a viral comment across three servers: US, EU, Asia.
T=0: Comment just posted. All counters at zero.

US:   inc={US:0}, dec={US:0}  →  score: 0
EU:   inc={EU:0}, dec={EU:0}  →  score: 0
Asia: inc={As:0}, dec={As:0}  →  score: 0

T=1: Activity floods in. US gets 8 upvotes. EU gets 3 upvotes and 5 downvotes. Asia gets 2 downvotes. All happening simultaneously, all independent.

US:   inc={US:8}, dec={US:0}   →  local score: 8
EU:   inc={EU:3}, dec={EU:5}   →  local score: -2
Asia: inc={As:0}, dec={As:2}   →  local score: -2

T=2: US and EU sync.

inc = Merge({US:8}, {EU:3}) = {US:8, EU:3}
dec = Merge({US:0}, {EU:5}) = {US:0, EU:5}
Score = (8+3) - (0+5) = 6

US and EU now agree: score is +6.

T=3: Asia reconnects after a brief network partition and syncs.

inc = {US:8, EU:3, As:0}  →  total: 11
dec = {US:0, EU:5, As:2}  →  total: 7
Score = 11 - 7 = 4

Final score: +4. Every upvote counted. Every downvote counted. No vote lost during the partition. No coordination during any of the voting itself.

This is the lie in the title: the +4 you see wasn't computed from one authoritative source. It was assembled from fragments of state scattered across three continents and merged after the fact.

It's an approximation. A consistent, mathematically guaranteed approximation — but an approximation nonetheless.

The Trade-Off Worth Naming

PN-Counter inherits G-Counter's main cost: every sync ships full state. Two maps, N entries each, across every gossip round. For tens of replicas this is fine. For thousands of edge nodes, the bandwidth adds up.

The more important trade-off is eventual consistency. When you're actively voting on a hot post, the score you see is the best approximation your nearest server has right now. Somewhere in Europe, a server might briefly disagree. They'll converge — they always do — but there's a window where different users see slightly different scores.

For Reddit, this is entirely acceptable. Nobody's life depends on whether the karma score reads 1,042 or 1,047 for 200 milliseconds. The system is highly available, survives network partitions cleanly, and handles write throughput that would collapse a coordinated system.

The trade-off is: exact consistency in exchange for scale and availability. Reddit made that trade. Most social platforms do.

The Problem PN-Counter Doesn't Solve

Here's where it gets interesting again — and where the next problem is quietly waiting.

PN-Counter has no floor. No ceiling. Nothing prevents the score from going to -50,000 if enough downvotes arrive. And nothing stops it from going to +10,000,000 either.

For Reddit karma, that's fine. But consider:

A distributed rate limiter that needs to cap requests at 1,000 per minute. The counter must not go above 1,000, enforced across all replicas.
An inventory system where stock can't go below zero. You can't sell items you don't have.
A per-user karma floor — some subreddits prevent karma from dropping below a certain value to protect new users from pile-ons.

These are bounded operations. And PN-Counter, with its two unbounded G-Counters, cannot enforce bounds without coordination.

You'd think: just check the current value before decrementing, and reject the operation if you'd go below the floor.

Try that across distributed replicas and you immediately reintroduce the problem we just spent this entire article solving. Two replicas both see the counter at 1 (the floor). Both receive a decrement. Both check locally — "1 is above 0, I can proceed." Both decrement. Counter is now -1 across the board. The floor was violated.

This is the problem the Bounded Counter CRDT was designed for. It's the next piece in this series — and it's the most complex CRDT we'll cover, because enforcing limits without coordination requires a genuinely different approach.

The short version: you can't do it with just max and subtraction. You need to distribute the permission to decrement itself.

But that's next time.

The Thread Running Through All of This

Two episodes in, the pattern is clear.

Every CRDT solves a hard distributed problem by finding a constraint that eliminates ambiguity. G-Counter said: make it grow-only, and max is always correct. PN-Counter said: never decrement — maintain two grow-only counters and subtract at read time.

The constraint is never a workaround. It's the design.

When you next open Reddit and see a karma score, you're looking at the output of two grow-only counters being summed and subtracted on a server near you — a server that may not have talked to its peers in the last few hundred milliseconds and doesn't need to.

The number is an approximation. But it's a principled one, built on math that guarantees eventual correctness without sacrificing the availability and performance that make Reddit usable at scale.

That's not a lie. That's engineering.

What's Next

This is Episode 2 of a series on CRDTs — the data structures powering Google Docs, Redis, Riak, and distributed infrastructure at scale.

Episode 1: G-Counter — why YouTube's view count is always approximate
Episode 2: PN-Counter — Reddit karma and the two-notebook trick (you're here)
Episode 3: G-Set — grow-only sets, and where they appear in the wild
Episode 4: LWW Registry — when "latest timestamp wins" is good enough
Episode 5: OR-Set — the elegant fix for the "deleted but still there" problem
Episode 6: Map CRDT — composing CRDTs into richer structures
Episode 7: The full picture — when to reach for CRDTs and when to walk away

Subscribe to the newsletter to get each episode as it drops.

If you're building distributed systems and want to think through architecture decisions with someone who has spent years deep in Go and distributed infrastructure — I do 1:1 sessions on Topmate.

YouTube Doesn't Actually Know How Many Views Your Video Has

Archit Agarwal — Tue, 05 May 2026 11:26:39 +0000

And that's not a bug. It's one of the most elegant algorithms in distributed systems.

Every time you refresh a viral YouTube video and watch the counter tick up, you're looking at a lie.

Not a malicious one. A mathematically precise, deliberately constructed one — built by some of the smartest distributed systems engineers on the planet, for a very good reason.

The actual view count? Nobody knows it exactly. Not YouTube's servers. Not their databases. Not the team that built the counter.
Here's what's actually going on, and why the algorithm behind it — called a G-Counter — is one of the most satisfying ideas in computer science.

The Problem With Counting at Scale

Let's be honest about what YouTube is dealing with.

A viral video gets 50 million plays in its first 24 hours. That's roughly 578 plays every second. These plays are happening from Los Angeles, London, Mumbai, São Paulo — simultaneously, all the time.
YouTube doesn't run one server. It runs thousands, distributed across data centres on multiple continents. Every server is independently accepting "play" events.

The naive solution: have one authoritative counter. Every time someone hits play, that event travels to the central counter, which increments and returns the new value.

The problem: that central counter immediately becomes the bottleneck. At 578 writes per second, you'd need a heavily optimised database just for the counter. And when it goes down — because everything goes down eventually — your entire view counting system goes with it.

The slightly less naive solution: use a distributed lock. Servers coordinate before writing. They take turns.

The problem with locks at scale: latency multiplies, throughput collapses, and network partitions turn the whole thing into a mess. In distributed systems, the CAP theorem tells you this is a fundamental tradeoff — you can't have consistency, availability, and partition tolerance all at once. When you choose strong consistency (everyone agrees on the exact count), you sacrifice availability and performance.

So YouTube made a different choice: stop trying to coordinate at all.

The Insight That Changes Everything

Here's the mental shift that makes G-Counters work.

What does it mean for a view count to be "correct"?

If the US server has recorded 1.2 million views, and the EU server has recorded 800 thousand views, and the Asia server has recorded 600 thousand views — and none of these servers have talked to each other recently — the total isn't ambiguous. It's 2.6 million.

You just add them up.

The reason this is safe is the key constraint: view counts can only go up. Nobody un-watches a video. Nobody subtracts views. The counter is monotonically increasing.

This constraint completely eliminates the problem of conflicting state. If the US server thinks it has 1.2M views and later discovers the EU server also thought the US had 1.1M views (because the EU server's information was slightly stale), there's no conflict to resolve — 1.2M is clearly more up-to-date, because the counter can only increase. You just take the higher number.

That insight — that the maximum value is always the correct value for a grow-only counter — is the foundation of the G-Counter algorithm.

A Simpler Way to See It

Before we look at the code, here's the mental model I find most useful.

Imagine three friends — call them US, EU, and Asia — who are each counting birds in different sections of a massive park. The park is too big to shout across, so they can't coordinate in real time.

Each person has their own notebook. The rule is simple: you can add tally marks, but you can never erase them (because you can't un-see a bird).

At the end of the day, they meet up. US has 3 marks. EU has 5 marks. Asia has 2 marks.

Total birds seen: 10.

Here's what makes this work without any drama: even if they ran into each other in the middle of the day and shared their notebooks, there's no conflict possible. If EU had shared their notebook earlier and it showed 4 marks at the time, and now it shows 5 — 5 is just the more current number. Take the maximum. Move on.

When you replace "friends" with "servers" and "notebook" with "replica state", you have a G-Counter.

The Data Structure

A G-Counter is, at its core, just a map:

type ReplicaId string
type GCounter map[ReplicaId]int64

func Zero() GCounter {
    return make(GCounter)
}

Each replica (each server) owns exactly one key in the map. A replica only ever writes to its own key. This invariant is everything — it's what makes the merge operation safe.
Reading the total is simple addition:

func (c GCounter) Value() int64 {
    var total int64
    for _, v := range c {
        total += v
    }
    return total
}

Incrementing means bumping your own key by 1:

func (c GCounter) Inc(r ReplicaId) GCounter {
    newC := make(GCounter, len(c))
    for k, v := range c {
        newC[k] = v
    }
    newC[r] = newC[r] + 1
    return newC
}

We copy the map to keep things immutable — each increment returns a new GCounter rather than mutating in place. This is a conscious design choice that makes reasoning about state considerably easier.

The Merge Function — Where the Magic Lives

This is the core of the whole algorithm:

func Merge(a, b GCounter) GCounter {
    result := make(GCounter)

    for k, v := range b {
        result[k] = v
    }

    for k, v := range a {
        if val, ok := result[k]; ok {
            if v > val {
                result[k] = v
            }
        } else {
            result[k] = v
        }
    }
    return result
}

For each replica ID, we take the maximum value seen across both maps.
That's it. No locks. No consensus rounds. No leader election. 15 lines of Go.

Why "Take the Maximum" Is Mathematically Safe

Here's where things get interesting — because this works for a deeper reason than it might seem.

For a merge function to be safe in a system where replicas can sync asynchronously, in any order, any number of times — it needs to satisfy three mathematical properties:

Commutativity: Merge(A, B) must equal Merge(B, A). It shouldn't matter which server initiates the sync.
Associativity: Merge(Merge(A, B), C) must equal Merge(A, Merge(B, C)). It shouldn't matter how you group the merges.
Idempotency: Merge(A, A) must equal A. If a server accidentally receives the same state twice — because of a network retry, for example — nothing should break.

The maximum function satisfies all three. Maximum(3, 5) equals Maximum(5, 3). Maximum(Maximum(3, 5), 7) equals Maximum(3, Maximum(5, 7)). Maximum(5, 5) equals 5.

A data structure whose merge function has these three properties is called a Convergent Replicated Data Type (CvRDT), or a state-based CRDT. The "convergent" part is the guarantee: no matter what order messages arrive in, no matter how long servers are disconnected, they will always end up agreeing on the same state when they finally sync.

This guarantee — eventual consistency without coordination — is the entire value proposition of CRDTs.

A Concrete Walk-Through

Let's trace through exactly what happens with three servers.
T=0: All servers start at zero.

US:   {US: 0}
EU:   {EU: 0}
Asia: {Asia: 0}

T=1: US receives 3 plays, EU receives 5, Asia receives 2. All independently.

US:   {US: 3}
EU:   {EU: 5}
Asia: {Asia: 2}

T=2: US and EU sync. Merge({US:3}, {EU:5}) → {US:3, EU:5}.

US:   {US: 3, EU: 5}  →  Value() = 8
EU:   {US: 3, EU: 5}  →  Value() = 8
Asia: {Asia: 2}        →  Value() = 2  (still hasn't synced)

T=3: Asia comes back online after a brief network partition. It merges with US.
Merge({US:3, EU:5}, {Asia:2}) → {US:3, EU:5, Asia:2}

All servers: {US:3, EU:5, Asia:2}  →  Value() = 10

Every play counted. No coordination required during the counting itself. The merge handles everything.

Where This Shows Up in the Real World

G-Counters (or something very close to them) are embedded in more infrastructure than most engineers realise:

YouTube and Twitch view counts — the exact use case we opened with. Regional servers count locally, merge periodically. The displayed count is always approximate, always eventually consistent.

Redis in distributed mode — Redis Enterprise uses CRDT-based counters when data is replicated across data centres. The INCR command on a distributed counter works precisely because of this algorithm.

Analytics pipelines — tools like Segment and Amplitude track event counts at edge nodes before rolling up. The edge nodes are essentially running G-Counters before flushing to a central store.

Riak — the distributed database that helped popularise CRDTs in production, built native G-Counter support into its data model specifically for use cases like these.

Gaming leaderboards — any system tracking "total kills" or "total distance" across game sessions that can happen offline is solving the same problem.

The Trade-Off You Should Know

G-Counters are simple and powerful, but they come with a cost worth understanding.

Because this is a state-based CRDT (also called CvRDT), every time two replicas sync, they exchange their entire state. With 3 replicas, that's a tiny map — 3 key-value pairs. With 1,000 replicas, every gossip round ships 1,000 entries over the wire, even if only one entry changed.

This is the fundamental tension in state-based CRDTs: simplicity of reasoning versus efficiency of replication.

The solution to this is Delta-state CRDTs, where replicas only send the delta — what changed since the last sync — rather than the whole state. Same mathematical guarantees, much lower bandwidth. That's a topic for a future article.

The Constraint Is the Solution

Here's the thing I find most elegant about G-Counters.

The constraint that initially seems limiting — you can only ever increment, never decrement — is exactly what makes the algorithm so clean. It eliminates an entire class of conflict. It makes the merge function trivially provable. It turns a hard distributed systems problem into a single line: take the max.

This pattern shows up everywhere in good system design. When you can't have everything, the question becomes: what do I give up, and what do I get in return? YouTube gave up exact real-time accuracy on view counts. In return, they got a counter that scales to any number of servers, works through network partitions, needs no coordination, and never loses a view.

That's a trade-off most engineering teams would take without hesitation.

What's Next

This is Episode 1 of a series I'm writing on CRDTs — the data structures that power Google Docs, distributed databases, offline-first applications, and collaborative tools.

Episode 2 covers PN-Counters — what happens when you need to both increment and decrement, without conflicts. Spoiler: you just use two G-Counters and subtract. The simplicity is almost frustrating.
The full series:

Episode 1: G-Counter (you're here)
Episode 2: PN-Counter — increment and decrement
Episode 3: G-Set — grow-only sets
Episode 4: LWW Registry — last-write-wins
Episode 5: OR-Set — observed-remove sets
Episode 6: Map CRDT — composing CRDTs into richer structures
Episode 7: The full picture — when to use CRDTs and when not to

Follow along on [your newsletter/Substack URL] to get each episode as it drops.

If you're building distributed systems and want to think through architecture decisions with someone who has been in the weeds on this — I do 1:1 sessions on Topmate.

How to Build Heartbeats in Go: Let Your Goroutines Say 'Still Breathing!'

Archit Agarwal — Wed, 21 May 2025 10:45:00 +0000

Ever wonder how to make your Go services show signs of life… even when they’re bored out of their mind?

You’re not alone.

Imagine this: You’ve got a bunch of goroutines quietly waiting for work to show up. All seems peaceful. Until… boom — you discover one of them died hours ago, and no one told you. No logs, no panics, no error traces — just pure ghosting.

Wanna avoid that silent death? Let’s teach our goroutines to breathe — or more specifically, send heartbeats.

🫀 Why Bother with Heartbeats?

Ever had a background task silently die while your main process happily spins along? Or had to debug why a job queue worker went unresponsive in the middle of the night?

Heartbeats help answer:

“Hey, is that goroutine still alive… or did it take an early retirement?”

If you’re building anything slightly concurrent, heartbeat signals become your tiny, periodic signs of life from those goroutines. You can monitor them, restart them, or just breathe a little easier knowing things are ticking.

🛠️ Let’s Build It!

Let’s say you’ve got a worker goroutine that waits for signals to do some work. While it’s waiting, you also want it to occasionally let the outside world know:

“Still alive, boss. Just waiting for the next gig.”

Here’s how we make that happen:

func dowork(done <-chan interface{}, pulseInterval time.Duration) (<-chan interface{}, <-chan struct{}) {
 heartbeater := make(chan interface{})
 result := make(chan struct{})
 go func() {
  defer close(result)
  defer close(heartbeater)

  pulse := time.NewTicker(pulseInterval)
  workGen := time.NewTicker(3 * pulseInterval)

  defer pulse.Stop()
  defer workGen.Stop()

  sendPulse := func() {
   select {
   case heartbeater <- struct{}{}:
   default:
    // drop if nobody's listening
   }
  }

  sendResult := func(res struct{}) {
   for {
    select {
    case <-done:
     return
    case <-pulse.C:
     sendPulse()
    case result <- res:
     return
    }
   }
  }

  for {
   select {
   case <-done:
    return
   case <-pulse.C:
    sendPulse()
   case <-workGen.C:
    sendResult(struct{}{})
   }
  }
 }()
 return heartbeater, result
}

This function returns two channels:

heartbeater: a non-blocking signal that says, "I'm alive!"
result: a channel that emits actual work when done.

In the main function, we simulate a 10-second lifetime for our job using time.AfterFunc. We read from both the heartbeat and result channels.

📡 The Main Function: Listening for Life

Here's what that looks like:

func main() {
 done := make(chan interface{})
 time.AfterFunc(10*time.Second, func() { close(done) })

 pulseInterval := 1 * time.Second
 heartbreater, result := dowork(done, pulseInterval)

 go func() {
  for {
   select {
   case _, ok := <-heartbreater:
    if !ok {
     fmt.Println("worker heartbeat stopped")
     return
    }
    fmt.Println("worker heartbeat")
   case _, ok := <-result:
    if !ok {
     return
    }
    fmt.Println("worker completed work")
   }
  }
 }()

 time.Sleep(20 * time.Second)
}

You'll see heartbeats printed every second, and actual work output every 3 seconds. After 10 seconds, the goroutine closes done, and everything wraps up gracefully.

🧠 A Few Takeaways

Heartbeats let your monitoring tools or orchestration layer know things are alive, even when no work is happening.
Non-blocking sends (select { case ch <- val: default: }) are perfect for "if you're listening, here's a signal-otherwise, no big deal."
Keep your goroutines polite: if they die, let them clean up after themselves.

👀 Final Thoughts
Implementing heartbeats in Go isn't just a cool concurrency trick - it's a must-have tool when you're building resilient systems. You don't want to wait until 3 AM to find out that your queue worker ghosted you. Be proactive. Make your goroutines send a little "I'm alive" wave now and then.
Because of silent failures?
They're not just frustrating - they're expensive.

🔗 Full source code available on GitHub:

👉 architagr/The-Weekly-Golang-Journal - heart beat

Stay Connected!

💡 Follow me on LinkedIn: Archit Agarwal
🎥 Subscribe to my YouTube: The Exception Handler
📬 Sign up for my newsletter: The Weekly Golang Journal
✍️ Follow me on Medium: @architagr
👨‍💻 Join my subreddit: r/GolangJournal
👨‍💻 Follow me on twitter: @architagr

The Silent Killers in Your Go App: Unhandled Errors

Archit Agarwal — Wed, 14 May 2025 10:45:00 +0000

Do you know what's scarier than a panic in a Golang application? 🤔
An error that doesn't panic, doesn't log, doesn't show up - but silently fails in production.
These are like landmines scattered across your codebase, patiently waiting to blow up at the worst possible time - like when you're sipping on a cold beer 🍺, celebrating a successful release.
And then…

📞 "Hey, the feature isn't working. Logs look clean. What's going on?"

Oh no. That's your PM. On a weekend. With no error trace.
I've been there. And yes, I left my beer mid-sip. 😞

When I first started with Go, I didn't fully grasp that errors in Go are first-class citizens - passed around just like any other value. If you don't handle them, they don't scream. They whisper. And that whisper can turn into a production outage.

So this article is not just a rant. It's a survival guide - to help you prevent these ghost errors from ruining your weekend or your system's reputation. 🧯

Let's walk through:

How to structure your error objects for better debugging
How to distinguish between expected and unexpected errors
And how to turn unhandled errors into actionable alerts for your team

Why Error Handling in Go Needs Your Full Attention

Not all errors are created equal. Some are edge cases you anticipate. Some are wild cards. But all of them need structure and context if you want to trace them later.

✅ Expected (or edge-case) errors:

User requests a resource that doesn't exist
Invalid query parameter
Authorization failure
Timeout or network delay

These are normal. They happen. You handle them, maybe return a 400 or 403, and move on.

❌ Unexpected errors (the real troublemakers):

DB connection fails
Memory exhaustion
Filesystem full
Internal services misbehaving
Panic due to nil pointer dereference

These should never happen - but if they do, you want to know immediately.

What Should Your Error Object Include?

Think of your error like a black box recorder. When things go wrong, it should tell you exactly what happened and how to reproduce it. Here's what it must include:

🧩 What happened?

A clear description: e.g. "invalid DB credentials", "failed to marshal JSON", or "timeout while calling payment gateway".

📍 Where did it happen?

Add stack traces or function names - Go makes this easy with tools like runtime.Caller() or libraries like pkg/errorsor xerrors.

⏱️ When did it happen?

Include request context: user ID, request ID, trace ID, timestamp - all of these help recreate the scenario and debug faster.

💬 What should the user see?

Don't leak internals! Instead, return friendly, actionable messages:

"Something went wrong. Please get in touch with support with Reference ID: xyz123."

🔍 How can the devs debug it further?

Include traceable metadata in logs or bug tracking systems so your team has breadcrumbs to follow. Reference IDS go a long way.

In the next section, we'll build a real REST API example and demonstrate how to put this into practice, gracefully handling, categorising, and propagating errors up to monitoring and alerting systems.

But before that, just remember this:
Handling errors isn't just about avoiding panics - it's about staying in control of your system even when it misbehaves.

Building a REST API in Go (Without Losing Your Mind Over Errors)

So, imagine we're building a REST API server - nothing fancy, just your good old layered Go backend:

Router Layer: Parses the HTTP request and routes it appropriately.
Service Layer: Decides whether to hit the DB, cache, or file system.
Persistence Layer: Deals directly with the database.

Let's zoom into the persistence layer, where two common issues can ruin your day:

The database isn't reachable (classic).
The data just… doesn't exist (also classic).

For the second case, we create a custom error structure to wrap all the "not found" drama:

type ObjectNotFoundError struct {
 ObjectType        string         `json:"objectType"`
 ObjectIdentifiers map[string]any `json:"objectIdentifier"`
 StackTrace        string         `json:"stackTrace"`
}

func (e *ObjectNotFoundError) Error() string {
 return fmt.Sprintf("%s not found, filter properties: [%v]", e.ObjectType, e.ObjectIdentifiers)
}
func (e *ObjectNotFoundError) LogMessage() string {
 b, _ := json.Marshal(e)
 return string(b)
}

🧠 What's Cool About This?

Error() gives a user-friendly summary.
LogMessage() gives devs all the gritty details.
ObjectType tells us what was missing.
ObjectIdentifiers explains how we looked for it.
StackTrace points us right to where the problem happened.

Now, let's see this in action in the persistence layer:

func (usrPer *UserPersistence) Get(ctx context.Context, id int) (*entities.User, error) {
 sqlQuery := fmt.Sprintf("select * from users where id = %d", id)
 data, err := usrPer.baseDb.Query(ctx, sqlQuery)
 if err != nil {
  return nil, err   // --- 1️⃣
 }
 if id <= 0 {
  return nil, &ObjectNotFoundError{.  // --- 2️⃣
   ObjectType:        "User",
   ObjectIdentifiers: map[string]any{"id": id},
   StackTrace:        string(debug.Stack()),
  }
 }
 fmt.Println(data)
 // else we will extract data from the data, for this we will hard code this return data
 return &entities.User{
  Id:          id,
  Name:        fmt.Sprintf("user-%d", id),
  CreatedDate: time.Now().Add(-10 * time.Hour),
 }, nil
}

Breakdown

1️⃣ We forward the DB error if it happens.
2️⃣ We simulate an invalid user ID scenario (I know validation doesn't belong here, but bear with me - this is just for the demo).

A small disclaimer: I know this is not the right place for this validation, but I have only done this to explain how to gracefully propagate the error from the innermost layer.

Now Let's Head Over to the Service Layer 🚪

Here's where we catch and convert those deep, scary errors into something the client can actually digest.

type ServiceError struct {
 InnerError     error
 HttpStatusCode int
 HttpResponse   *dto.ErrorResponse
}

func (e *ServiceError) Error() string {
 return e.InnerError.Error()
}

func (e *ServiceError) GetHttpStatusCode() int {
 return e.HttpStatusCode
}

func (e *ServiceError) GetErrorResponse() *dto.ErrorResponse {
 return e.HttpResponse
}

We also define a handy interface:

type ILogMessageError interface {
 error
 LogMessage() string
}

Now, here's the service logic in action:

func (svc UserService) Get(ctx context.Context, id int) (*dto.User, error) {
 fmt.Println("get in the svc")
 userInfo, err := svc.userPersistenceObj.Get(ctx, id)
 if err != nil {
  if e, ok := err.(ILogMessageError); ok {
   return nil, svc.WrapError(e)
  }
  logBug(err)
  return nil, fmt.Errorf("can not retrive user: %d", id)
 }
 return (&dto.User{}).Init(userInfo), nil
}

🧪 What's Happening Here?

Interface Check: We see if the error implements ILogMessageError - if yes, it's a known error.
WrapError: Transforms the error into a format with HTTP status and message.
logBug(): If it's an unexpected error, alert the engineering team. PagerDuty bells ring. People panic. You know the drill.

// handle all types of errors that we expect the persistence to return
// or we can have a builder to build the ServiceError, and also follow
// The open and closed principle, and single responsibility principal
func (svc UserService) WrapError(err ILogMessageError) *ServiceError {
 var objNotFound *persistence.ObjectNotFoundError
 var result *ServiceError
 if errors.As(err, &objNotFound) {
  result = &ServiceError{
   InnerError:     err,
   HttpStatusCode: http.StatusNotFound,
   HttpResponse: &dto.ErrorResponse{
    ErrorCode:        "usr-404",
    ErrorDescription: err.Error(),
   },
  }
 }
 return result
}
func logBug(err error) {
 // log a bug and page enginnering team about the error
 log.Println("logged a bug for error", err, string(debug.Stack()))
}

Finally, The Router - The Gatekeeper to the Client 🌐

Here, we check whether the service-level error can be converted to an HTTP response.

type IHttpResponseError interface {
 GetHttpStatusCode() int
 GetErrorResponse() *dto.ErrorResponse
}

func (r UserRouter) Get(c *gin.Context) {
 var userReq dto.User
 if err := c.ShouldBindUri(&userReq); err != nil {
  c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
  return
 }
 userInfo, err := r.userServiceObj.Get(c.Request.Context(), userReq.Id)
 if err != nil {
  if e, ok := err.(IHttpResponseError); ok {
   c.JSON(e.GetHttpStatusCode(), e.GetErrorResponse())
   return
  }
  c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
  return
 }
 c.JSON(http.StatusOK, userInfo)
}

🧩 Why This Works

Handled errors bubble up in a predictable format with HTTP codes.
Unhandled errors raise the flag to devs and get returned as generic 500s.
Clients stay informed. Devs stay sane. Production stays alive. 😅

🎯 Final Thoughts

And there you have it - an end-to-end error handling strategy that:

Keeps your layers clean and decoupled
Makes debugging a breeze with structured error logs
Ensures your users never see a dreaded "500 Internal Server Error" without context

🔗 Full source code available on GitHub:

👉 architagr/The-Weekly-Golang-Journal - error-propagation

Stay Connected!

Stop Spawning Infinite Goroutines: Use Tee-Channels in Go for Scalable Event Handling

Archit Agarwal — Wed, 23 Apr 2025 10:44:00 +0000

Imagine you're working on an app that allows users to sign up for free. But you also want to make sure that someone from the sales team follows up to nudge the user to subscribe. So you have two tasks after the user is successfully signed up:

Send a welcome email to the user.
Notify the sales team on Slack.

Naturally, your first version looks something like this:

User signs up
You send a welcome email
Once that's successful, you notify the sales team

Sounds clean.
But here's the thing - you've now tied the success of the sales notification to the welcome email, which is not just a coupling nightmare, it's also a recipe for "Oops, we never told the sales team."

⚠️ The Goroutine Trap: Scaling Gone Wild

So you think, "Let's parallelise it! Fire two goroutines!"
Great. Until…
You host a workshop, and suddenly, a hundred thousand users are signing up.
Now your server is firing two goroutines per user and context switching like it's in a dance battle. CPU usage spikes, latency increases, and your devops team starts slacking you 😅.

💡 Observing the Pattern: The Tasks are Independent!

Take a closer look. The welcome email and the Slack notification are independent. They don't need to wait on each other. They don't even need to happen in real-time.
Which begs the question - why not broadcast the event and let each downstream process consume it at its own pace?
Enter: Tee-Channels in Go.

🧵 What is a Tee-Channel in Go?

A tee-channel is like a broadcast system for Go channels. One input channel, multiple output channels. Each downstream consumer listens to their dedicated output and does their thing.
You don't spawn two goroutines per user anymore. You pipe the user once, and split it out - cleanly.

👨‍💻 Let's Build It: A Tee-Channel Implementation in Go

Here's a simple, scalable version that processes signups, and then concurrently (but safely) fans out to:

Send welcome emails
Notify the marketing team

Step 1: Define a simple DTO

type userDTO struct {
 id    int
 name  string
 email string
}

Step 2: Create a helper to respect done context

We'll use orDone so that everything shuts down gracefully if the context is cancelled.

func orDone(done <-chan struct{}, c <-chan userDTO) <-chan userDTO {
 valStream := make(chan userDTO)
 go func() {
  defer close(valStream)
  for {
   select {
   case <-done:
    return
   case v, ok := <-c:
    if !ok {
     return
    }
    select {
    case valStream <- v:
    case <-done:
    }
   }
  }
 }()
 return valStream
}

Step 3: Implement the Tee-Channel logic

func tee(
 done <-chan struct{},
 in <-chan userDTO,
) (<-chan userDTO, <-chan userDTO) {
 out1 := make(chan userDTO, 1_000)
 out2 := make(chan userDTO, 1_000)

 go func() {
  defer close(out1)
  defer close(out2)
  for val := range orDone(done, in) {
   var o1, o2 = out1, out2
   for i := 0; i < 2; i++ {
    select {
    case <-done:
    case o1 <- val:
     o1 = nil
    case o2 <- val:
     o2 = nil
    }
   }
  }
 }()
 return out1, out2
}

Here's what's happening:

We listen to the input stream (in)
Each input value is sent to both output channels exactly once.
It's concurrency-safe and honours context cancellation.

Step 4: Handlers for Email and Slack

func sendWelcomeEmail(done <-chan struct{}, ch <-chan userDTO) {
 for u := range orDone(done, ch) {
  fmt.Println("📧 Sending welcome email to", u.email)
 }
 fmt.Println("✅ Email handler done")
}

func sendNotification(done <-chan struct{}, ch <-chan userDTO, slackChannel string) {
 for u := range orDone(done, ch) {
  fmt.Println("📣 Notifying", slackChannel, "team for user", u.name)
 }
 fmt.Println("✅ Slack handler done")
}

Step 5: Putting It All Together

func singnup(u userDTO, ch chan<- userDTO) {
 // Simulate saving to DB
 ch <- u
}

func main() {
 ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
 defer cancel()

 notificationChannel := make(chan userDTO, 1_000)

 // Split the input to two output handlers
 ch1, ch2 := tee(ctx.Done(), notificationChannel)

 // Start handlers
 go sendNotification(ctx.Done(), ch1, "marketing")
 go sendWelcomeEmail(ctx.Done(), ch2)

 // Simulate signups
 singnup(userDTO{id: 1, name: "Archit", email: "a@example.com"}, notificationChannel)
 singnup(userDTO{id: 2, name: "Lilly", email: "lilly@example.com"}, notificationChannel)

 time.Sleep(2 * time.Second) // Let handlers finish
}

You can find this complete code in my GitHub : https://github.com/architagr/The-Weekly-Golang-Journal/tree/main/tee-channel

🧠 A Few Pro Tips

The orDone pattern ensures your goroutines stop listening when the context is cancelled.
tee() is the magic sauce - it splits the input stream cleanly.
This is future-proof. You can later plug more consumers like analytics, onboarding workflows, etc., without modifying the producer.

🎯 When Should You Use Tee-Channels?

✅ When multiple consumers need the same data
✅ When you want to decouple event producers from consumers
✅ When you want to avoid unbounded goroutine creation
Not a good fit if:

You need real-time delivery with strict ordering guarantees
You expect high fan-out (many consumers) - in that case, use a pub-sub system

🧵 Final Thoughts: Small Pattern, Big Impact

Honestly, this pattern looks simple. But in high-scale systems, it becomes a lifesaver. It gives you concurrency without chaos and scalability without the CPU meltdown.
So next time someone signs up on your app - just tee it up! 😄

Stay Connected!

Master the Chain of Responsibility Pattern in Go with This Real-World Example

Archit Agarwal — Wed, 09 Apr 2025 10:45:00 +0000

🧶 Intro: From Spaghetti to Structured

Ever written a function that starts by fetching user data, dumps it into a file, zips the file, then emails it out - all in one go?
It feels like this:

func exportEverything() {
  fetchUsers()
  parseUsers()
  zipFile()
  emailZip()
}

And sure, it works. Until the day something changes.

Suddenly, you need to skip zipping for certain users, or plug in an S3 upload. You end up sprinkling conditionals everywhere. Before you know it, you've summoned a micro-monolith. And worse? It's not even testable.

So… what do we do?

🧩 Enter: Chain of Responsibility Pattern

The Chain of Responsibility is a behavioral design pattern that lets you pass requests down a chain of handlers. Each handler does its job and optionally passes the request forward.
Think of it like a tech support escalation:

Level 1 takes your call
If they can't help, they pass it to Level 2
If that fails, well… the manager steps in

In Go, we can use this pattern to cleanly break up our export logic into small, reusable, testable chunks.

🛠️ The Real-World Example: Exporting User Data

Let's say we have a process that:

Fetches users from the DB
Parses them into a file
Zips that file
Emails the zip to the requester

Using the Chain of Responsibility, each step becomes a handler:

type exportStepHandler interface {
 execute(req *exportRequest) error
 setNext(next exportStepHandler)
}

Each handler implements this interface and decides what to do with the request. Here's a quick peek:

🏃 Fetch Users

type exportFetchUsers struct {
 next exportStepHandler
}

func (h *exportFetchUsers) execute(req *exportRequest) error {
 fmt.Printf("RequestId(%d): Users fetched from DB\n", req.requestid)
 return h.callNext(req)
}

🧻 Parse Into File

type exportParseIntoFile struct {
 next exportStepHandler
}

func (h *exportParseIntoFile) execute(req *exportRequest) error {
 fmt.Printf("RequestId(%d): Users parsed into file\n", req.requestid)
 return h.callNext(req)
}

📦 Zip It Up

type exportZipFiles struct {
 next exportStepHandler
}

func (h *exportZipFiles) execute(req *exportRequest) error {
 fmt.Printf("RequestId(%d): file zipped\n", req.requestid)
 return h.callNext(req)
}

✉️ Email the Zip

type exportEmailZip struct {
 next exportStepHandler
}

func (h *exportEmailZip) execute(req *exportRequest) error {
 fmt.Printf("RequestId(%d): Zip emailed\n", req.requestid)
 return h.callNext(req)
}

🧩 Connecting the Chain

We then wire everything like a good old-fashioned factory:

func InitExportData() exportStepHandler {
 emailStep := &exportEmailZip{}

 zipStep := &exportZipFiles{}
 zipStep.setNext(emailStep)

 parseStep := &exportParseIntoFile{}
 parseStep.setNext(zipStep)

 fetchStep := &exportFetchUsers{}
 fetchStep.setNext(parseStep)

 return fetchStep
}

And then… 🧙 magic:

func main() {
 exportChain := InitExportData()
 exportChain.execute(&exportRequest{
  requestid: 1,
 })
}

🧠 Why This Pattern Rocks

✅ Readable: Each handler does one thing - clean and simple.

✅ Maintainable: Change one step without touching others.

✅ Flexible: Easily rewire or skip steps depending on context.

✅ Testable: Unit test each handler in isolation.

✅ Extensible: Want to log something or upload to S3? Just add a new handler!

🧵 Final Thoughts

If you've ever struggled with long, procedural workflows in Go, this pattern is a game-changer.
The Chain of Responsibility gives you a structure that scales. It turns a rigid flow into a flexible, testable, and modular pipeline.
So next time you think:

"Hmm, maybe I'll just add another if…"

Take a deep breath. Then chain it up. 🪢

Stay Connected!

The Strategy Pattern in Go: A Simple Guide to Writing Extensible Code

Archit Agarwal — Wed, 02 Apr 2025 10:45:00 +0000

Imagine you're running a coffee shop ☕, and customers ask for their order receipts in different formats - some want their receipts printed, some in PDF sent over Email, and one guy asks for a receipt over SMS. Now, imagine that you have written this billing software to support a printed receipt.🫣
Every time a new type of receipt is requested, you rewrite your entire billing system. Sounds painful, right? Well, that's precisely what happened in our Go code when UserService was initially responsible for exporting users as JSON and CSV, and now we onboard a client who wants this in XML. Let's look at the initial UserService.

Initial UserService: Without using Strategy Design Pattern

Imagine you have a UserService that fetches user data and allows exporting it in different formats. Right now, you support JSON and CSV, but what if tomorrow you need XML, PDF, or Parquet?

var (
 Err_NotSupportedExportType = errors.New("Not Supported export Type")
)

type IUserPersistence interface {
 ListUsers(paginationObj models.Pagination) []models.UserModel
}
type UserService struct {
 userPersistence IUserPersistence
}

func InitUserService(userPersistence IUserPersistence) *UserService {
 return &UserService{
  userPersistence: userPersistence,
 }
}

func (userSvc *UserService) GetUsers(paginationObj models.Pagination) []models.UserModel {
 return userSvc.userPersistence.ListUsers(paginationObj)
}

func (userSvc *UserService) ExportUsers(paginationObj models.Pagination, 
exportConfig models.ExportConfig) (string, error) {

 users := userSvc.GetUsers(paginationObj)

switch exportConfig.Type {
 case enums.ExportType_Json:
  jsonData, err := json.Marshal(users)
  return string(jsonData), err
 case enums.ExportType_CSV:
  sb := strings.Builder{}
  sb.WriteString("id,name,email\n")
  for _, u := range users {
   sb.WriteString(fmt.Sprintf("%d,%s,%s\n", u.Id, u.Name, u.Email))
  }
  return sb.String(), nil
 default:
  return "", Err_NotSupportedExportType
 }
}

The Problem with This Approach

With the current implementation, every time you add a new export format, you modify the ExportUsers method. This violates two key SOLID principles:

Single Responsibility Principle (SRP) - UserService should focus only on fetching users, not handling export logic.
Open/Closed Principle (OCP) - The class should be open for extension but closed for modification. Right now, adding a new export type means editing existing code, increasing the risk of breaking something.

Issues with this approach:

💔 UserService becomes a bottleneck.
💀 Every new format requires modifying existing code.
💥 One small change could break everything.
😭 Teams adding new export formats need to touch your code.
😫 Testing becomes harder as the service grows.

How Can We Fix This?

Instead of making UserService aware of every export format, we need a pluggable solution. This is where the Strategy Pattern shines! ✨

💡 Introducing the Strategy Pattern

Think of it like choosing a shipping method on Amazon: You pick Standard Shipping, Express, or Same-Day - but Amazon doesn't care how it's delivered. The delivery company handles that.
Similarly, our UserService should just fetch users and let the export strategy decide how to format them.

Are you ready to start the code repair 👩🏻‍🔧?

Step 1: Define a Common Export Interface

// Strategy interface
type IUserExport interface {
 Export(data []models.UserModel) (string, error)
}

Implement Concrete Strategies

// CSV Export: Concrete Strategy
type CsvExportStrategy struct {
}

func (e *CsvExportStrategy) Export(data []models.UserModel) (string, error) {
 if len(data) == 0 {
  return "", errors.New("No data")
 }
 sb := strings.Builder{}
 sb.WriteString(data[0].GetHeader())
 for _, u := range data {
  sb.WriteString(u.GetRow())
 }
 return sb.String(), nil
}

// JSON Export: Concrete Strategy
type JSONExportStrategy struct {
}

func (e *JSONExportStrategy) Export(data []models.UserModel) (string, error) {
 if len(data) == 0 {
  return "", errors.New("No data")
 }
 jsonData, err := json.Marshal(data)
 return string(jsonData), err
}

Step 3: Create a Strategy Builder

var (
 Err_NotSupportedExportType = errors.New("Not Supported export Type")
)

func UserExportBuilder(config *models.ExportConfig) (IUserExport, error) {
 if config.Type == enums.ExportType_CSV {
  return &CsvExportStrategy{}, nil
 } else if config.Type == enums.ExportType_Json {
  return &JSONExportStrategy{}, nil
 }
 return nil, fmt.Errorf("%w, %d", Err_NotSupportedExportType, config.Type)
}

Step 4: Update UserService 🥁

func (userSvc *UserService) ExportUsers(paginationObj models.Pagination, 
exportConfig exportstrategy.IUserExport) (string, error) {

 users := userSvc.GetUsers(paginationObj)
 return exportConfig.Export(users)
}

Now, ExportUsers does not care how data is exported. It only retrieves users and sends the data to the correct export strategy.

Step 5: Adding a New Format (XML)

// XML Export: Concrete Strategy
type XMLExportStrategy struct {
}

func (e *XMLExportStrategy) Export(data []models.UserModel) (string, error) {
 if len(data) == 0 {
  return "", errors.New("No data")
 }
 xmlData, err := xml.Marshal(data)
 return string(xmlData), err
}

Step 6: Update the Strategy Builder

func UserExportBuilder(config *models.ExportConfig) (IUserExport, error) {
 switch config.Type {
 case enums.ExportType_CSV:
  return &CsvExportStrategy{}, nil
 case enums.ExportType_Json:
  return &JSONExportStrategy{}, nil
 case enums.ExportType_Xml:
  return &XMLExportStrategy{}, nil
 default:
  return nil, fmt.Errorf("%w, %d", Err_NotSupportedExportType, config.Type)
 }
}

You can find this code on my Github: https://github.com/architagr/design_patterns/tree/main/golang/behavioral/strategy

🚀 Final Thoughts & Takeaways

Before: Every new format meant editing UserService, risking bugs.
After: Adding new formats is just creating a new strategy, with no changes to the core logic.
Note:
If your if-else statements are growing faster than your stress levels, it's time for the Strategy Pattern.

Stay Connected!

Never Miss an Update: Master the Observer Pattern in Go with Real-World Examples

Archit Agarwal — Wed, 26 Mar 2025 10:45:00 +0000

Why Should You Care About the Observer Pattern?

Have you ever felt the FOMO when you miss out on an important update? Imagine a world where you must constantly refresh your email to check for new messages. Sounds painful, right? 😩

Well, that’s exactly how inefficient polling works in software. Instead of constantly checking, wouldn’t it be better if you just got notified automatically when something changed?

That’s where the Observer Pattern comes in! This pattern lets different parts of your system subscribe to updates and automatically receive notifications when an event occurs. It’s the backbone of event-driven programming and is used in real-world systems like:

✅ Live sports score updates
✅ Stock market price alerts
✅ Job portal notifications
✅ E-commerce product price drop alerts
✅ Hashtag-based content subscription (which we’ll build today!)

In this article, we’ll demystify the Observer Pattern and implement a Hashtag Subscription System in Golang, where users can subscribe to specific hashtags and receive notifications when new articles are published.

What is the Observer Pattern?

The Observer Pattern is a behavioural design pattern where:

A Subject (Publisher) maintains a list of Observers (Subscribers).
Whenever the subject’s state changes, it notifies all registered observers automatically.
Observers can subscribe or unsubscribe dynamically without affecting the subject’s core logic. This pattern decouples objects, making systems more modular and scalable.

Implementing the Observer Pattern in Go

Let’s build a Hashtag Subscription System, where:

📌 Users subscribe to hashtags they’re interested in.
📌 When an article is published under a hashtag, subscribers get notified.
📌 Users can unsubscribe from hashtags at any time.
📌 Users can block specific authors if they don’t want to see their content.

Step 1: Define the Observer Interface (Users)

package publisher

import "fmt"

// Observer Interface (Subscribers)
type IHashtagObserver interface {
 Notify(articleID, author string)
}

Each user who wants to receive hashtag updates must implement the Notify method.

Step 2: Define the Subject (Hashtag Manager)

// Hashtag acts as a subject (Publisher)
type Hashtag struct {
 observers map[string]IHashtagObserver
 name      string
 articles  map[string]bool
}

// Register an observer (User)
func (tag *Hashtag) Register(name string, observer IHashtagObserver) {
 tag.observers[name] = observer
}

// Deregister an observer (User)
func (tag *Hashtag) Deregister(name string) {
 delete(tag.observers, name)
}

// Publish a new article
func (tag *Hashtag) NewArticlePublished(articleID, author string) {
 fmt.Printf("\n📢 Notifying subscribers of #%s about new article (ID: %s) by %s\n", tag.name, articleID, author)
 tag.notify(articleID, author)
}

// Notify all observers
func (tag *Hashtag) notify(articleID, author string) {
 for _, observer := range tag.observers {
  observer.Notify(articleID, author)
 }
}

The Hashtag Manager maintains a list of subscribers and notifies them when a new article is published.

Step 3: Implement the Concrete Observer (User)

// User struct acts as an Observer
type User struct {
 id            string
 name          string
 email         string
 slackUserID   string
 hashtags      map[string]bool
 blockedAuthor map[string]bool
}

// Add an author to the blocked list
func (u *User) AddBlockedAuthor(author string) {
 u.blockedAuthor[author] = true
}

// Remove an author from the blocked list
func (u *User) RemoveBlockedAuthor(author string) {
 delete(u.blockedAuthor, author)
}

// Subscribe to a hashtag
func (u *User) AddHashtag(tagName string) {
 u.hashtags[tagName] = true
 publisher.GetHashtag(tagName).Register(u.name, u)
}

// Unsubscribe from a hashtag
func (u *User) RemoveHashtag(tagName string) {
 delete(u.hashtags, tagName)
 publisher.GetHashtag(tagName).Deregister(u.name)
}

// Receive notifications for new articles
func (u *User) Notify(articleID, author string) {
 if u.blockedAuthor[author] {
  fmt.Printf("🚫 %s skipped notification for article (ID: %s) - blocked author: %s\n", u.name, articleID, author)
  return
 }
 fmt.Printf("\n📨 Sending notification to %s\n", u.name)
 if u.email != "" {
  fmt.Printf("📧 Email sent to %s for new article (ID: %s) by %s\n", u.email, articleID, author)
 }
 if u.slackUserID != "" {
  fmt.Printf("💬 Slack notification sent to %s for new article (ID: %s) by %s\n", u.slackUserID, articleID, author)
 }
}

Each user can subscribe/unsubscribe from hashtags dynamically!

Step 4: Bringing It All Together

func main() {
 var (
  tagCleanCode           = "Clean Code"
  tagSoftwareDevelopment = "Software Development"
 )
 publisher.AddNewHashtag(tagSoftwareDevelopment)
 publisher.AddNewHashtag(tagCleanCode)

 // Create users and subscribe them to hashtags
 user.InitUser("1", "Alice", "alice@example.com", "alice_slack", []string{tagSoftwareDevelopment}, nil)
 user.InitUser("2", "Bob", "bob@example.com", "bob_slack", []string{tagSoftwareDevelopment, tagCleanCode}, nil)
 user3 := user.InitUser("3", "Charlie", "charlie@example.com", "charlie_slack", []string{tagSoftwareDevelopment, tagCleanCode}, []string{"author1"})

 // Publish new articles under hashtags
 publisher.GetHashtag(tagSoftwareDevelopment).NewArticlePublished("article1", "author2")
 publisher.GetHashtag(tagSoftwareDevelopment).NewArticlePublished("article2", "author1") // Charlie blocked author1
 publisher.GetHashtag(tagCleanCode).NewArticlePublished("article3", "author1")

 // Charlie unsubscribes from "Clean Code" hashtag
 user3.RemoveHashtag(tagCleanCode)
 publisher.GetHashtag(tagCleanCode).NewArticlePublished("article4", "author2") // Charlie won't be notified
}

Expected Output

📢 Notifying subscribers of #Software Development about new article (ID: article1) by author2

📨 Sending notification to Alice
📧 Email sent to alice@example.com for new article (ID: article1) by author2
💬 Slack notification sent to alice_slack for new article (ID: article1) by author2

📨 Sending notification to Bob
📧 Email sent to bob@example.com for new article (ID: article1) by author2
💬 Slack notification sent to bob_slack for new article (ID: article1) by author2

📨 Sending notification to Charlie
📧 Email sent to charlie@example.com for new article (ID: article1) by author2
💬 Slack notification sent to charlie_slack for new article (ID: article1) by author2

📢 Notifying subscribers of #Software Development about new article (ID: article2) by author1

📨 Sending notification to Alice
📧 Email sent to alice@example.com for new article (ID: article2) by author1
💬 Slack notification sent to alice_slack for new article (ID: article2) by author1

📨 Sending notification to Bob
📧 Email sent to bob@example.com for new article (ID: article2) by author1
💬 Slack notification sent to bob_slack for new article (ID: article2) by author1
🚫 Charlie skipped notification for article (ID: article2) - blocked author: author1

📢 Notifying subscribers of #Clean Code about new article (ID: article3) by author1

📨 Sending notification to Bob
📧 Email sent to bob@example.com for new article (ID: article3) by author1
💬 Slack notification sent to bob_slack for new article (ID: article3) by author1
🚫 Charlie skipped notification for article (ID: article3) - blocked author: author1

📢 Notifying subscribers of #Clean Code about new article (ID: article4) by author2

📨 Sending notification to Bob
📧 Email sent to bob@example.com for new article (ID: article4) by author2
💬 Slack notification sent to bob_slack for new article (ID: article4) by author2

Boom! 🎉 Alice and Bob got their notifications instantly and Charlie also was able to block a particular author! No polling, no wasted CPU cycles. Just clean, efficient event-driven programming.

You can find this complete working code on my Github.

Key Takeaways

✅ The Observer Pattern helps create event-driven, decoupled systems.
✅ It's used in stock updates, job alerts, social media notifications, and more.
✅ Our Hashtag Subscription System shows how users can subscribe, unsubscribe, and receive notifications in real-time.

Final Thoughts

This is just the tip of the iceberg. You can extend this pattern for WebSockets, message brokers, or even real-time dashboards! 🚀

Stay Connected!

💡 Follow me here on LinkedIn for more insights on software development and architecture.
🎥 Subscribe to my YouTube channel for in-depth tutorials.
📬 Sign up for my newsletter, The Weekly Golang Journal, for exclusive content.
✍️ Follow me on Medium for detailed articles.
👨‍💻 Join the discussion on my subreddit, r/GolangJournal, and be part of the community!

Stop Writing Rigid Code! Master the Decorator Pattern in Go for Ultimate Flexibility

Archit Agarwal — Wed, 12 Mar 2025 10:45:00 +0000

Imagine you're a software developer building an ice cream vending machine for Disneyland. The menu was initially fixed - customers could only order predefined flavors with no customizations (boring, right? 😒). You wrote simple code to calculate costs based on these fixed options.

But this is Disneyland! Nobody wants a plain old scoop. People want triple scoops, extra chocolate sauce, stacked wafer cones, sprinkles, and more. You realize you can't hardcode every possible combination, or your codebase will become a nightmare! 🫠

So, how do you handle dynamic customizations without rewriting everything? Enter the Decorator Pattern, a lifesaver for scenarios where you need to dynamically extend an object's functionality without modifying its structure.

Let's first explore the problem with a naive approach and then refactor it using the Decorator Pattern for a flexible and scalable solution. 🚀

The Traditional Approach: Hardcoding Ice Cream Variants

Imagine our first attempt at coding the vending machine. A simple function creates a Butterscotch Ice Cream:

func CreateButterscotchIcecream(scoops int) IceCream {
    ingredients := []IceCreamIngredient{
        BASE_PLAIN_CONE,
    }
    for i := 0; i < scoops; i++ {
        ingredients = append(ingredients, FLAVOUR_BUTTERSCOTCH)
    }
    ingredients = append(ingredients, TOPPING_SPRINKLES)
    return Create(CreateIceCreamRequest{Ingrediants: ingredients})
}

Now, we add Vanilla Ice Cream:

func CreateVanillaIcecream(scoops int) IceCream {
    ingredients := []IceCreamIngredient{
        BASE_PLAIN_CONE,
    }
    for i := 0; i < scoops; i++ {
        ingredients = append(ingredients, FLAVOUR_VANILLA)
    }
    return Create(CreateIceCreamRequest{Ingrediants: ingredients})
}

This works fine for fixed flavours, but what if customers want to mix and match? What if someone wants vanilla with chocolate chips or a chocolate cone with butterscotch scoops? We can't keep adding new functions for every combination. 😵‍💫

The Problem? 🚨

Hardcoding every variation is not scalable.
The code becomes repetitive and difficult to maintain.
There is no flexibility to create custom orders dynamically.

Time to refactor using the Decorator Pattern!

Introducing the Decorator Pattern 🎩✨

The Decorator Pattern allows us to dynamically extend an object's functionality without modifying its structure. Instead of hardcoding different types of ice cream, we use composition over inheritance to wrap functionalities around each other.

Think of your manager adding their name to your presentation after changing the font size - that's the Decorator Pattern at work. 😂

Step 1: Define a Common Interface

We start by creating an interface that all ice cream components (base, flavours, and toppings) will implement:

type IIceCreamIngredient interface {
    GetPreparationSteps() []string
    GetCost() int
}

Step 2: Implement the Base Ingredient (Chocolate Cone)

Now, let's implement the Chocolate Cone decorator, which wraps around another ingredient:

type BaseChocolateCone struct {
 ExistingIngrediant IIceCreamIngrediant
}

func (ingrediant *BaseChocolateCone) GetPreperationSteps() []string {
 step := "Chocolate Cone"
 if ingrediant.ExistingIngrediant != nil {
  return append(ingrediant.ExistingIngrediant.GetPreperationSteps(), step)
 }
 return []string{step}
}
func (ingrediant *BaseChocolateCone) GetCost() int {
 oldCost := 0
 if ingrediant.ExistingIngrediant != nil {
  oldCost = ingrediant.ExistingIngrediant.GetCost()
 }
 return 12 + oldCost
}

✅ Breakdown:

If this ingredient is added on top of something else, it appends the steps to the existing preparation list.
If it's the first ingredient, it starts the list.
Cost calculation is handled dynamically by summing up all wrapped ingredients.

Step 3: Implement More Decorators

Let's implement a Butterscotch Flavor decorator:

type FlavourButterscotch struct {
 ExistingIngrediant IIceCreamIngrediant
}

func (ingrediant *FlavourButterscotch) GetPreperationSteps() []string {
 step := "1 scoop Butterscotch"
 if ingrediant.ExistingIngrediant != nil {
  return append(ingrediant.ExistingIngrediant.GetPreperationSteps(), step)
 }
 return []string{step}
}
func (ingrediant *FlavourButterscotch) GetCost() int {
 oldCost := 0
 if ingrediant.ExistingIngrediant != nil {
  oldCost = ingrediant.ExistingIngrediant.GetCost()
 }
 return 5 + oldCost
}

With this setup, we can now chain ingredients dynamically! 🎉

Step 4: Dynamically Creating Ice Cream Orders 🍨

Now, let's take a user's order and create their dream ice cream dynamically:

func main() {
    iceCream := &BaseChocolateCone{
        ExistingIngredient: &FlavourButterscotch{
            ExistingIngredient: &FlavourVanilla{},
        },
    }

    fmt.Println("Steps to prepare your ice cream:")
    for index, step := range iceCream.GetPreparationSteps() {
        fmt.Printf("Step %d: %s\n", index+1, step)
    }
    fmt.Printf("Total Cost: $%d\n", iceCream.GetCost())
}

Output:

Steps to prepare your ice cream:
Step 1: Chocolate Cone
Step 2: 1 scoop Butterscotch
Step 3: 1 scoop Vanilla
Total Cost: $20

✅ Now, any combination is possible dynamically!

No hardcoding different combinations
Easily scalable for new flavours & toppings
Follows the Open-Closed Principle (extend behavior without modifying existing code)

The complete Code can be found on my GitHub https://github.com/architagr/design_patterns/tree/main/golang/structural/decorator

Real-World Use Cases of the Decorator Pattern

Logging Middleware (Wrap API requests to log data)
Authentication Middleware (Add security checks dynamically)
Rate Limiting (Restrict API calls per user)
Caching Mechanism (Cache responses dynamically)
Monitoring & Metrics Collection (Track execution time)
Encryption & Compression (Wrap data processing functions)
Feature Flags (Enable/disable features at runtime)
Payment Processing (Add discounts/taxes dynamically)
Data Validation (Validate user input before processing)
Web Scraping Pipelines (Apply transformation layers dynamically)

Wrapping Up 🎁

The Decorator Pattern is a powerful technique in Go that allows you to dynamically compose behaviours while keeping your codebase clean and scalable. Next time you face a scenario where functionalities need to be added dynamically without modifying the base code think Decorators!

Have you used the Decorator Pattern in your projects? Share your experience in the comments! 👇

Stay Connected!

💡 Follow me here on LinkedIn for more insights on software development and architecture.

🎥 Subscribe to my YouTube channel for in-depth tutorials.

📬 Sign up for my newsletter, The Weekly Golang Journal, for exclusive content.

✍️ Follow me on Medium for detailed articles

👨‍💻 Join the discussion on my subreddit, r/GolangJournal, and be part of the community!

Mastering Fan-Out, Fan-In in Golang: Supercharge Your Concurrency Skills

Archit Agarwal — Wed, 26 Feb 2025 10:45:00 +0000

Golang thrives on simplicity and efficiency, and one of its most elegant features is its built-in concurrency model. With goroutines and channels, Go makes it ridiculously easy to manage concurrent processes - without the headaches of traditional threading models.

But how do you take this power and scale it efficiently? Enter the Fan-Out, Fan-In pattern. Today, we'll break it down with a real-world example: downloading files in parallel and adding them to a ZIP archive. We'll compare a naive synchronous approach versus an optimized concurrent solution - showing you how to write performant and scalable Go applications.

Prerequisites

To make the most of this, you should be familiar with:

Channels - Linkedin | Medium.com
sync.WaitGroup - Linkedin | Medium.com
Building pipelines in Golang - Linkedin | Medium.com

What is Fan-Out, Fan-In?

You might be thinking, Oh no, another fancy concurrency term! Don't worry. By the end of this article, you'll realize this is just common sense wrapped in a cool name.

Fan-Out

Multiple worker goroutines process data from a single input channel concurrently, improving throughput.
Analogy: Your team leader gets tasks from the manager and distributes them among you and your colleagues. More hands, faster work!

Fan-In

Multiple goroutines send their results to a single output channel, aggregating data efficiently.
Analogy: Your scrum master collects everyone's work updates and compiles them into a single report.

The Problem: Downloading and Zipping Files

Imagine we need to download 10 files. Each takes * to download. Once downloaded, we must add each to a ZIP archive, which takes 1 second per file. If we do this synchronously, it would take:

(10 files 2s) + (10 files 1s) = 20s + 10s = ~30 seconds

Let's look at the naive approach:

func DownloadFiles(done <-chan bool, fileUrlsStream <-chan string) <-chan []byte {
 fileStream := make(chan []byte, 10)

 go func() {
  defer close(fileStream)
  for url := range fileUrlsStream {
   log.Println("Downloading file from url: ", url)
   // download file
   time.Sleep(2 * time.Second)
   fileStream <- []byte("file content " + url)
  }
 }()
 return fileStream
}

This function downloads files one at a time - not great. Now let's Fan-Out this process.

Implementing Fan-Out for Downloads

Instead of downloading one file at a time, let's distribute the work across multiple workers.

numberOfWorkers := 4
urlStream := fileUrlStreamGenerator(fileUrls)
downloadStreamArr := make([]<-chan []byte, numberOfWorkers)
// Fan-Out: Launching multiple workers
for i := 0; i < numberOfWorkers; i++ {
 downloadStreamArr[i] = filedownloader.DownloadFiles(done, urlStream)
}

Now, we have 4 workers running in parallel. The new execution time? 10 files / 4 workers * 2s per file = 8s. Already a 60% improvement!

Implementing Fan-In: Processing the Downloaded Files

Once all files are downloaded, we need to aggregate them into a ZIP file. Instead of doing this sequentially, we can Fan-In multiple streams into one.

func Merge(done <-chan bool, contentStreams ...<-chan []byte) <-chan []byte {
 mergedStream := make(chan []byte)
 wg := sync.WaitGroup{}
 // This function takes single content stream and multiplexes it to mergedStream
 multiplex := func(done <-chan bool, contentStream <-chan []byte) {
  defer wg.Done()
  for content := range contentStream {
   // merge content
   select {
   case <-done:
    return
   case mergedStream <- content:
   }
  }
 }

 wg.Add(len(contentStreams))
 for _, contentStream := range contentStreams {
  // Fan-In
  // here we are starting multiple goroutines to multiplex content
                // from multiple content streams to mergedStream
  go multiplex(done, contentStream)
 }
        // Wait for all multiplexing goroutines to finish
 go func() {
  wg.Wait()
  close(mergedStream)
 }()
 return mergedStream
}

Now, the ZIP operation takes just 4 seconds instead of 10. 🚀

What Stages Are Best Candidates for Using Fan-Out?

Not every stage in a pipeline benefits from parallel execution. Here are some key scenarios where Fan-Out makes a difference:

I/O Bound Tasks → Reading from disk, network requests, or database queries.
CPU Intensive Computation → Tasks like image processing, encryption, or complex calculations.
Independent Data Processing → When each task doesn't rely on the output of others.

However, not all tasks are good candidates. If a stage requires sequential operations (e.g., writing to a single file), adding Fan-Out might reduce performance instead of improving it.

Additional Helper Functions

To make this work seamlessly, here are three key functions used in the pipeline:

ProcessContent

func ProcessContent(done <-chan bool, fileStream <-chan []byte) <-chan string {
 contentStream := make(chan string)

 go func() {
  defer close(contentStream)
  outFileName := "output.zip"
  // create a zip archive

  for fileContent := range fileStream {
   // add file to a zip archive
   time.Sleep(1 * time.Second)
   log.Printf("Adding file %s to zip archive\n", fileContent)
   // write file to zip
  }
  contentStream <- outFileName
 }()
 return contentStream
}

fileUrlStreamGenerator

func fileUrlStreamGenerator(fileUrls []string) <-chan string {
 fileUrlStream := make(chan string, len(fileUrls))
 go func() {
  defer close(fileUrlStream)
  for _, fileUrl := range fileUrls {
   fileUrlStream <- fileUrl
  }
 }()
 return fileUrlStream
}

startSynchronousProcessingStage

func startSynchronousProcessingStage(done <-chan bool, fileUrls []string) {
 log.Println("Starting synchronous processing stage")
 startTime := time.Now()
 urlStream := fileUrlStreamGenerator(fileUrls)

 downloadFileStream := filedownloader.DownloadFiles(done, urlStream)
 zipFileName := <-fileprocessor.ProcessContent(done, downloadFileStream)
 log.Println("Zip file created: ", zipFileName)
 log.Println("Time taken in synchronously processing stage: ", time.Since(startTime))
}

The Final Result

Synchronous - The time taken was approximately 30 seconds.
Fan-Out (4 workers) - The time taken was approximately 12 seconds.

That's almost a 60% reduction in time, simply by utilizing Go's concurrency capabilities.

Where to Find the Code?

You can find the complete implementation on my GitHub repository

Why This Matters

This example highlights how Go's lightweight concurrency model makes it incredibly simple to build scalable, efficient applications. With just a few lines of code, we:

Spun up multiple goroutines to execute tasks concurrently.
Used sync.WaitGroup to manage concurrent execution.
Used channels to collect results safely.
Drastically reduced execution time without adding unnecessary complexity.

Conclusion

If you're already using Go, you know how beautiful and efficient its concurrency model is. If you're not using Go yet, this is a perfect example of why you should start! The ability to easily scale workloads using Fan-Out, and Fan-In makes Go an ideal language for performance-intensive applications like web servers, data pipelines, and background processing systems.
Golang makes concurrency simple, elegant, and powerful - why not take advantage of it?

Stay Connected!

💡 Follow me here on LinkedIn for more insights on software development and architecture:
🎥 Subscribe to my YouTube channel for in-depth tutorials.
📬 Sign up for my newsletter, The Weekly Golang Journal, for exclusive content.
✍️ Follow me on Medium for detailed articles.
👨💻 Join the discussion on my subreddit, r/GolangJournal, and be part of the community!

Are you tired of APIs that crawl when they should fly?

Archit Agarwal — Wed, 19 Feb 2025 10:45:00 +0000

Picture this:

You’re building a batch update API to process 1,000 tasks in a single request. Each task needs to go through these steps:

Validate the input data.
Log an audit entry.
Update the database.
Notify the user.

Sounds simple, right? Well, here’s the catch: each step takes 100 milliseconds per task. Multiply that by 1,000 tasks across 4 steps, and voilà—you’re staring at over 6 minutes to process a single batch.

What if I told you it could be done in ~400ms?

Check out my latest article on Concurrent Pipelines in Go. I’ll walk you through building scalable APIs that are as fast as your users expect them to be.

Read the full article here and unlock the secrets of lightning-fast APIs. Your next backend system will thank you. 💻

Stay Connected!
💡 Follow me here on LinkedIn for more insights on software development and architecture. https://www.linkedin.com/in/architagarwal984/
🎥 Subscribe to my YouTube channel for in-depth tutorials: https://lnkd.in/gauaRed7
📬 Sign up for my newsletter, The Weekly Golang Journal, for exclusive content: https://lnkd.in/g8DzK7Ts
✍️ Follow me on Medium for detailed articles: https://lnkd.in/gXSMeXxm

Master Go Concurrency with the Or-Channel Pattern

Archit Agarwal — Wed, 12 Feb 2025 10:45:00 +0000

If you're serious about writing robust Go code, understanding the or-channel pattern is a game changer. Learn how to combine multiple done channels efficiently. 🚀

What you'll learn:

Use recursion to manage dynamic numbers of channels.
Practical examples to level up your Go skills.
Avoid common concurrency pitfalls.
📖 Read the article here

Let's connect and share ideas in the comments!