Forem: Archit Agarwal

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!

Mastering Error Handling in Goroutines: Avoid Hidden Pitfalls in Go

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

Are Goroutine errors slipping under the radar in your Go apps? Don’t let them haunt your production systems!

In this article, I break down how to:

Catch and handle Goroutine errors effectively.
Avoid common pitfalls and ensure robust error handling.
Build clean, maintainable Go code with practical examples.
🔗 Read the full article here

Let’s make error handling less scary! 🚀

🚨 Prevent Goroutine Leaks in Go: Master Graceful Termination 🚨

Archit Agarwal — Wed, 29 Jan 2025 10:45:00 +0000

Goroutines are a superpower, but leaks can silently wreck your Go app! In my latest article, I cover:
✅ The three ways goroutines terminate.
✅ Why defer may fail silently.
✅ A foolproof method to stop leaks with done channels.

💡 Avoid silent disasters and make your apps rock-solid! Check it out here: https://www.linkedin.com/pulse/prevent-goroutine-leaks-like-pro-save-your-go-from-disaster-agarwal-qog7c