DEV Community: M Yauri M Attamimi

How I Personally Grasp the Essence of Concurrency in Go

M Yauri M Attamimi — Wed, 25 Mar 2026 18:02:44 +0000

Philosophy, Patterns & The Power of Built-in Tools

Why Go says “Don’t communicate by sharing memory” and how to build robust systems without external libraries.

If you come from a background in Java (like me), Python, or JavaScript, the word “concurrency” might trigger a slight sense of anxiety. We are taught that threads are dangerous, race conditions are lurking around every corner, and debugging deadlocks is a nightmare.

Then you meet Go.

Go doesn’t just offer a new way to write concurrent code; it offers a new way to think about it. But beyond the famous mantras, how does this philosophy translate to actual engineering ? And perhaps most importantly, do you need external libraries to make it work ?

The answer is a resounding NO. Everything you need to build enterprise-grade concurrent systems is built directly into the language and its standard library.

In this post, we’ll recap the core philosophies of Go concurrency, explore the patterns that make it powerful, and highlight the built-in tools that let you implement them without adding a single dependency.

1. The Core Philosophy: CSP vs. Shared Memory

The most famous quote in Go concurrency comes from Rob Pike:

“Don’t communicate by sharing memory; share memory by communicating.”

This is the principle of CSP (Communicating Sequential Processes). To understand it, we need to contrast it with the traditional model.

The Traditional Model: Shared Memory

Imagine a single-occupancy bathroom in an office or any public places.

The Resource: The bathroom (a variable in memory).
The Problem: Multiple people (threads) need to use it.
The Solution: A lock on the door (mutex). You must acquire the key, use the bathroom, and return (release/unlock) the key after you use it.
The Risk: What if someone forgets to unlock the door ? (Deadlock). What if someone sneaks in without the key ? (Race Condition).

The Go Model: CSP

Imagine a factory conveyor belt (a Channel).

The Resource: The parts being built (data).
The Process: Worker A places a part on the belt. The belt moves it to Worker B.
The Safety: At any specific moment, only one person is holding the part. When it is on the belt, no one is touching it.
The Focus: You aren’t protecting a static (shared) variable; You are managing the flow of data.

In Go: You don’t protect a variable with a lock! You pass the variable over a chan. Ownership is transferred safely from one goroutine to another.

2. The Engineering Mantra: Sequence and Backpressure

There is a second, practical mantra that follows the philosophy:

“Don’t over engineer things by using shared memory and complicated, error prone synchronization primitives; instead, use message-passing between Goroutines so variable and data can be used in the appropriate sequence.”

This is where Go shines in production. Channels aren’t just for moving data; they are for controlling time.

The Relay Race Analogy

Shared Memory: Workers check a whiteboard every second to see if the previous step is done. (Busy waiting, complex logic)
Channels: Workers stand in a line. Worker 2 physically cannot start until Worker 1 hands them the baton.

Why this matters:

Sequence Guaranteed: A receive operation ( <- ) blocks automatically until data arrives. You don’t need to write if done {...} loops.
Natural Backpressure: If the Consumer is slow, the Channel fills up. The Producer automatically blocks and waits. This prevents your program from consuming all RAM trying to process data faster than the database can save it.

3. The Producer-Consumer Problem (Solved Simply)

The classic Producer-Consumer pattern is kind of “Hello World” of concurrency. It solves the problem of balancing speed between data creation and data processing.

In many languages, implementing a bounded-buffer (a queue that stops accepting data when full) requires complex condition variables and locks.

The Traditional Way (as conceptually handled in Java)

// Requires Mutex, Condition Variables, Wait(), Signal(), etc.
// Easy to get wrong. Hard to read.
void put(item) {
    lock.acquire();
    while (queue.isFull()) { condition.wait(); }
    queue.add(item);
    condition.signal();
    lock.release();
}

The “Go” Way

In Go, a Buffered Channel is a thread-safe Producer-Consumer queue.

// Create a buffer that holds exactly 5 items
buffer := make(chan int, 5)

// Producer
go func() {
    for i := 0; i < 100; i++ {
        buffer <- i // Automatically blocks if channel is full (Backpressure!)
    }
    close(buffer)
}()

// Consumer
go func() {
    for item := range buffer { // Automatically blocks if channel is empty
        process(item)
    }
}()

That’s it. No locks. No condition variables. No manual signaling. The language runtime handles the synchronization for you.

4. The Go Standard Toolbox (No External Libraries Needed)

One of Go’s greatest strengths is that you do not need third-party frameworks to handle different patterns of concurrency. The standard library is batteries-included.

+---------------------+----------------+------------------+--------------+
|.  Pattern.          |. Tool.         | Package.         |.  Built-In ? | 
+---------------------|----------------|------------------|--------------+
| Lightweight Threads | goroutine      | Language Keyword |  ✅ Yes      |
| Communication       | chan           | Language Keyword |  ✅ Yes      |
| State Protection    | sync.Mutex     | sync             |  ✅ Yes      |
| Wait Groups         | sync.WaitGroup | sync             |  ✅ Yes      |
| High Perf Counters  | atomic         | sync/atomic      |  ✅ Yes      |
| Lifecycle/Timeout   | context        | context          |  ✅ Yes      |

Structure Concurrency with context

In traditional concurrency, knowing when to stop a goroutine is hard. Go solves this with the context package. It allows you to cascade cancellation signals.

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

// Pass ctx to your goroutines. 
// If the timeout hits, all listening goroutines stop gracefully.

This prevents goroutine leaks, a common bug in other languages where background tasks keep running forever after a request finishes.

5. When to Break the Rules

While “Share memory by communicating” is the default path, Go is pragmatic. As an engineer we know that there’s “size fits for all”. It always depends on the usecase / problem we’re trying to solve. There are times when shared memory is better:

Simple State: If you just need to protect a simple config map or cache, a sync.Mutex is often clearer than setting up a channel loop.
Performance: Channels have a small overhead. For extremely high-frequency counters, sync/atomic is faster.
Internal State: If a struct has internal state that shouldn’t be exposed, protecting it with a mutex inside its methods is cleaner.

The Rule of Thumb:

Use channels to orchestrate flow (pipelines, worker pools)

Use mutexes to protect state (caches, configs)

6. Beyond the Basics: Actor Model & Async

Go’s model is unique compared to other ecosystems:

Vs. Async/Await (JS/Python): Go hides the complexity. You write code that looks synchronous (e.g., response:= http.Get(...)), but the runtime parks the goroutine efficiently. No callback hell, no explicit await keywords everywhere.
Vs. Actor Model (Erlang/Elixir/Akka): Go is similar but more flexible. In Actor Model pattern: mailboxes (channel in Go) belong to actors. In Go, channels are independent entities that multiple goroutines can share. However, you can build an Actor in Go using a goroutine + switch statement + channel, but you aren’t forced into that paradigm.

Conclusion

Concurrency in Go is not just about doing multiple things at once; its about composing those things safely.

By adopting the CSP philosophy, you shift your mindset from protecting resources (locks) to managing flow (channels). By leveraging the built-in tools like chan, context, and sync, you avoid the dependency hell common in other ecosystems.
You get:

Safety: Race conditions are harder to introduce.
Backpressure: Systems self-regulate under load.
Simplicity: Complex workflows look like simple pipeline.

So.. the next time you face a concurrency problem, remember the mantra: Don’t communicate by sharing memory. Share memory by communicating. And trust the tools that come right out of the box.

Clean Code Architecture in Go

M Yauri M Attamimi — Sun, 05 Apr 2020 14:40:57 +0000

Everyone can write code to produce a software that functionally works as expected, yet not everyone care about how's their code architecture look like. The best chosen algorithms not always save us from the bad software design. There are many code architectures around, and recently i've been struggling and trying to promote the Clean Code Architecture from Robert C. Martin a.k.a. Uncle Bob. Let's start with how this sort of code architecture looks like in Go.

I’m gonna start by implementing some of the functionalities within a shopping cart since it’s pretty straightforward. Bear in mind that what i’ll be showing here is restricted to the bounded context of the shopping cart, means we’ll just focus with the process of how a user/buyer choose the item and adding that particular item into his cart, and subsequently continue with the checkout. As for the billing/payment part, that will be in the bounded context of another service such as payment service. (if you’re neither really familiar nor confidence with what bounded context is, i would suggest you to read another article of mine from here.

By the way, all of the source code i explain here can be cloned/forked from

yauritux / clean-code-architecture

My personal opinion on the Clean Code Architecture in the context of Domain Driven Design (DDD), yet i adopted some terms from the Onion Architecture such as domain to avoid any misleading interpretations with the Entity in DDD

What are highlighted in the grey colors were standing outside of our shopping cart bounded context. Hence, we won’t tackle the nitty gritty details of those objects within our code implementation since those things would be in other services (e.g. product catalogue service and user service). Nevertheless, we’ll still be having those objects within our code, in the context of what our shopping cart needs. For instance, we won’t need user credentials information in our shopping cart since that should be catered from the user service context. Basically, we just need user information which is related to the shopping cart itself, such as: user_session_id, shipping address, billing address (furthermore, address information should also be catered from another service, e.g. : address service, even this is also optional).

There are some rules for this architecture those we must bear within our mind. I've summarized those rules as following:

Dependency between layer should be going inward in one direction. As far as i concern, it was designed like this to avoid any circular dependencies.
A layer should depend only on one direct layer (one level) beneath it, it shouldn’t know any layers beyond that level. For instance, A depends on B ( A → B ), and B depends on C ( B → C ), yet A shouldn’t know anything about C.
Each layer should depends upon abstraction ( interface ) rather than implementation. This complies with what Uncle Bob said about 2 rules to fix RFI issues, you can read it from my old article here.

Let’s jump to the implementation by creating our project folder from the terminal and also initialize the go module as shown below:

mkdir cart-service && cd cart-service
go mod init github.com/yauritux/cart-svc

Next step is creating our pkg directory (mkdir pkg) from the same terminal. This pkg directory will contain our implementation logic for the shopping cart which complies with the clean code architecture we’re discussing here.

By referring to the depicted shopping cart process diagram earlier, we’ll be having these following entities within our code:

User (this also represents a Buyer in the shopping cart bounded context).
Cart (as the name implies, this is our cart object which holds our shopping items).
Product (used as a placeholder for the product information. And for the sake of simplicity…, we won’t have any product categories because our goal here was merely to discuss the Clean Code Architecture).

I create those 3 entities within my pkg/domain/entity folder. To keep it simple, i deliberately marked all of the fields as exported fields (moving forward, we can think about hiding the fields information behind the setter / getter which are commons in Java).

Cart Entity:

User Entity:

Product Entity:

And here our value objects ( pkg/domain/valueobject ):

Cart Items (strongly related to Product entity).
Buyer Address (comprises of Billing and Shipping addresses, determined by the Address Type).

CartItem Value Object:

BuyerAddress Value Object:

Additionally, we will also have our enums as shown below:

If you’re wondering about the differences between entities and value objects, you can read it from

DDD Part II - M Yauri Attamimi - Medium

M Yauri Attamimi ・ Jul 15, 2017 ・ 5 min read
Medium

The next important thing to do is to implement our core business logic, which is part of Entities in Clean Code Architecture, or Core Domain in terms of Onion Architecture. This is something that is related to the enterprise business rules out of the application service rule.

In order to implement this kinda thing, we need to setup our aggregate root (i call it as user_cart aggregate). Again, take a look at what i wrote here if you’re still wondering about what is the aggregate all about.

Another to-do thing is to setup our repositories. Bear in mind, that when we’re talking about repository, it’s not always about the database. The storage implementation could be anything such as: web services, file, in-memory, etc.., and they should be abstracted by following some contracts defined on the interface. In that way, we can use them interchangeably later since we make our client code depends on the interface rather than directly on the implementation. In order to make it possible, we should start by abstracting our repositories with interfaces such as following:

Cart Repository Interface:

User Repository Interface:

Product Repository Interface:

I would assume that some of you will be asking about those empty interfaces :-). Why do they exist ? Why do we use them ?.

As far as i concern, we’ll be having different models for every layer in order to make our architecture more loosely-coupled. In that case, we should abstract our interface model as far as we can, thus we can have more flexibility within our code. Let’s say for the user repository interface, we can have 2 implementations for it, one implementation to get the user information from the database, and another one to get the information from a web service (e.g. REST). Therefore, definitely we’ll have 2 models here, one based on the database model, and another one is based on the web request-response model. That’s the reason why we use empty interface ( interface{} ) within our repository interface. You get it right ? :-). Don’t worry, everything will become clear once we implement our interface.

For the sake of simplicity, we'll be implementing just in-memory repository for now since our first goal is merely to discuss about how’s our clean code architecture will be looked like. However, i will incrementally update the code later for another kind of storage / repository, such as database or web service.

Let’s start to implement our repository interface by creating another directory (at the same level with our domain directory) as shown below:

mkdir -p pkg/adapter/repository/inmem/model

And here are our models (inside the pkg/adapter/repository/inmem/model directory) to be used in the context of our in-memory repository (remember about the interface{} before, when we designed our repository contract interface).

User Model for In-Memory Repository Implementation:

Cart Model for In-Memory Repository Implementation:

Product Model for In-Memory Repository Implementation:

subsequently followed by our in-memory repository implementation for those 3 models respectively (inside /adapter/repository/inmem directory):

User In-Memory Repository Implementation:

Cart In-Memory Repository Implementation:

Product In-Memory Repository Implementation:

And the use cases for cart and user as written below :

User Usecase Port:

User Usecase Interactor:

Cart Usecase Port:

Cart Usecase Interactor:

Product Usecase Interactor:

Last but not least, let’s create a small CLI program to test our shopping cart functionalities that we’ve created so far.

Shopping Cart CLI tester using in-memory repository:

Ok, some of you might get overwhelmed with all of the code here (while some of you might not), especially in regards with the use case port and interactor (what would be the difference between those 2).

Test our CLI by using this following command from the terminal:

go run cmd/cli/main.go

You can grab the full code from here

Let me know for any concerns and/or questions from you guys :-).