Search for a command to run...
Mastering Channels, Patterns, and Concurrency Flow in Go
No comments yet. Be the first to comment.
A technical follow-up covering the internals of Raft, the actual RPCs, every server's state, what happens in each failure mode, and the edge cases around commitment, leases, and reconfiguration that the paper works hard to get right.
Introduction to the Go Scheduler and the GMP Model
Laying the foundation every scalable system is built on
How to Install and Configure a Go Web Server on Amazon EC2
Concurrency means multiple tasks making progress at the same time.
It does not always mean running at the exact same moment (that is parallelism). Instead, concurrency is about structuring programs so many tasks can progress independently.
Go was designed to make concurrency simple and scalable.
Instead of relying on heavy threads and complicated locking, Go introduced two core primitives:
Lightweight concurrent functions. A goroutine is much cheaper than a traditional thread. You can run hundreds of thousands of them.
A channel in Go is a communication mechanism that allows goroutines to send and receive data safely.
Think of a channel as a typed pipe through which values flow between goroutines.
Channels are powerful because they provide three guarantees:
Channels synchronize goroutines automatically. Send blocks until receive happens, this ensures safe coordination.
Channels remove the need for:
mutexes
locks
condition variables
Channels enable powerful patterns such as:
One-to-One communication
Fan-Out (one producer, many workers)
Fan-In (many producers, one consumer)
Pipelines
Broadcast
Worker pools
These patterns make Go programs clean, scalable, and easy to reason about.
Channels in Go are strongly typed. This means a channel can only send and receive one specific type of data.
Example:
ch := make(chan int)
This channel can only transmit integers.
Valid:
ch <- 10
Invalid:
ch <- "hello" // compile-time error
This type safety prevents many runtime bugs and makes concurrent code more predictable.
Channels have a simple syntax consisting of three main operations.
Channels are created using the make function.
make(chan T)
Where:
T = type of data the channel carriesExample:
ch := make(chan int)
This creates a channel capable of sending and receiving integers.
Data is sent to a channel using the arrow operator.
ch <- value
Example:
ch <- 5
This means: send value 5 into channel ch
Usually this is done inside a goroutine.
go func() {
ch <- 5
}()
To receive a value from a channel:
value := <-ch
Example:
num := <-ch
fmt.Println(num)
This means: take a value from channel ch and store it in num
One of the most important characteristics of channels is blocking behavior.
Channels automatically synchronize goroutines.
When sending:
ch <- value
The goroutine waits until another goroutine receives the value.
When receiving:
value := <-ch
The goroutine waits until a value is available in the channel.
Sender --- waiting ---> Channel <--- waiting --- Receiver
Both sides must be ready.
This property is what makes channels safe for concurrency without locks.
Channels in Go can restrict how they are used.
A channel can be:
Bidirectional : send and receive
Send-only : only send values
Receive-only : only receive values
This restriction happens at compile time, preventing misuse of channels.
A bidirectional channel allows both sending and receiving.
Syntax:
chan T
Example:
ch := make(chan int)
ch <- 10 // send
value := <-ch // receive
Here the channel can perform both operations.
This is the default channel type in Go.
A send-only channel allows only sending data.
Syntax:
chan<- T
Example:
func sendData(ch chan<- int) {
ch <- 10
}
Inside this function:
Sending is allowed
ch <- 10
Receiving is NOT allowed
value := <-ch // compile-time error
This restriction ensures the function only produces data.
A receive-only channel allows only receiving data.
Syntax:
<-chan T
Example:
func receiveData(ch <-chan int) {
value := <-ch
fmt.Println(value)
}
Inside this function:
Receiving is allowed
value := <-ch
Sending is NOT allowed
ch <- 10 // compile-time error
A bidirectional channel can be converted to a directional one.
Example:
func producer(ch chan<- int) {
ch <- 5
}
func consumer(ch <-chan int) {
value := <-ch
fmt.Println(value)
}
func main() {
ch := make(chan int)
go producer(ch)
consumer(ch)
}
Here:
main -> bidirectional channel
producer -> send-only channel
consumer -> receive-only channel
Go automatically converts the channel type.
Channels in Go can behave in two different ways depending on how they are created:
Unbuffered Channels : synchronous communication
Buffered Channels : asynchronous communication
The difference lies in whether the channel has storage capacity (a buffer).
This behavior directly affects how goroutines coordinate with each other.
An unbuffered channel has no storage capacity.
This means a value cannot exist in the channel alone.
A sender and receiver must meet at the same time for communication to occur.
Since no capacity is provided, the channel is unbuffered by default.
Flow:
Receiver ---- waiting ---> Channel <--- waiting --- Sender
A buffered channel has internal storage capacity.
This allows values to be stored temporarily inside the channel.
Creation syntax:
ch := make(chan int, 3)
Here: channel capacity = 3
The channel can hold 3 values before blocking.
Buffer Capacity
The number given during creation defines the buffer size.
Example:
ch := make(chan int, 2)
This channel can store [ value1 | value2 ] inside its internal buffer.
Queue-like Behavior
Buffered channels behave like a FIFO queue (First-In-First-Out).
Example:
ch := make(chan int, 3)
ch <- 1
ch <- 2
ch <- 3
Internal buffer: [1 | 2 | 3]
Receiving values:
fmt.Println(<-ch)
fmt.Println(<-ch)
fmt.Println(<-ch)
Output:
1
2
3
Values come out in the same order they were sent.
Channels enable different communication patterns between goroutines.
These patterns define how data flows between concurrent tasks.
The most basic patterns are:
One-way communication
Two-way communication (Request–Response)
Understanding these patterns helps design structured concurrent systems.
In one-way communication, data flows in a single direction between goroutines.
There is one sender and one receiver, and no response is expected.
Two common forms are:
Main -> Goroutine
Goroutine -> Main
In this pattern, the main goroutine acts as the producer, sending data to another goroutine that performs some work.
Flow:
Main ---> Channel ---> Worker Goroutine
Example:
package main
import "fmt"
func worker(ch <-chan int) {
value := <-ch
fmt.Println("Worker received:", value)
}
func main() {
ch := make(chan int)
go worker(ch)
ch <- 10
}
Execution flow:
Main creates the channel
Worker goroutine starts and waits for data
Main sends value 10
Worker receives and processes it
Output:
Worker received: 10
Here the worker only consumes data.
In this pattern, a worker goroutine produces a result, and the main goroutine receives it.
Flow:
Worker Goroutine ---> Channel ---> Main
Example:
package main
import "fmt"
func compute(ch chan<- int) {
result := 5 * 5
ch <- result
}
func main() {
ch := make(chan int)
go compute(ch)
result := <-ch
fmt.Println("Result:", result)
}
A component sends a request, and another component sends a response.
This pattern is called request–response communication.
Flow:
Client --> Request Channel --> Worker --> Response Channel --> Client
The simplest approach uses two separate channels.
Example:
package main
import "fmt"
func worker(requests <-chan int, responses chan<- int) {
req := <-requests
responses <- req * 2
}
func main() {
requestCh := make(chan int)
responseCh := make(chan int)
go worker(requestCh, responseCh)
requestCh <- 10
result := <-responseCh
fmt.Println("Response:", result)
}
Execution flow:
Main sends a request
Worker receives the request
Worker processes it
Worker sends response
Main receives result
Output:
Response: 20
A more advanced approach uses reply channels embedded in the request.
Flow:
Client --> Request{data, replyChannel} --> Worker --> replyChannel --> Client
Example:
package main
import "fmt"
type Request struct {
data int
reply chan int
}
func worker(reqCh <-chan Request) {
req := <-reqCh
result := req.data * 2
req.reply <- result
}
func main() {
reqCh := make(chan Request)
go worker(reqCh)
replyCh := make(chan int)
reqCh <- Request{
data: 10,
reply: replyCh,
}
result := <-replyCh
fmt.Println("Response:", result)
}
Output:
Response: 20
These describe how goroutines are connected through channels.
Single producer -> single consumer
Similar concept as the One Way Communication
In this topology, one producer distributes work to multiple workers.
Key Idea:
Multiple goroutines compete to receive from the same channel.
Important Rule:
Each job is processed by exactly one worker because a channel delivers a value to only one receiver.
Use Case
Parallel processing
CPU-intensive tasks
Worker pools
Example
package main
import (
"fmt"
"time"
)
func worker(id int, jobs <-chan int) {
// Keep receiving values from the channel until it is closed
for job := range jobs {
fmt.Println("Worker", id, "processing job", job)
time.Sleep(time.Millisecond * 500)
}
}
func main() {
jobs := make(chan int)
// Start 3 workers
for i := 1; i <= 3; i++ {
go worker(i, jobs)
}
// Send jobs
for j := 1; j <= 5; j++ {
jobs <- j
}
close(jobs)
time.Sleep(time.Second * 2)
}
Work is distributed automatically.
In this topology, multiple producers send data to a single consumer.
Key Idea
Many goroutines produce results, and one goroutine collects them.
Use Case
Aggregating results
Merging streams
Logging systems
Example
package main
import "fmt"
func worker(id int, results chan<- int) {
results <- id * 10
}
func main() {
results := make(chan int)
for i := 1; i <= 3; i++ {
go worker(i, results)
}
for i := 1; i <= 3; i++ {
fmt.Println("Result:", <-results)
}
}
This is the most flexible topology.
Multiple producers
Multiple consumers
All connected through shared channels
Use Case
Worker pools
Distributed processing
Task queues
High-throughput systems
Example
package main
import "fmt"
func producer(id int, ch chan<- int) {
for i := 1; i <= 3; i++ {
ch <- id*10 + i
}
}
func consumer(id int, ch <-chan int) {
for val := range ch {
fmt.Println("Consumer", id, "received", val)
}
}
func main() {
ch := make(chan int)
// Producers
for i := 1; i <= 2; i++ {
go producer(i, ch)
}
// Consumers
for i := 1; i <= 3; i++ {
go consumer(i, ch)
}
// Let it run briefly
select {}
}
Channels are not just for passing data — they are powerful tools for coordinating goroutines.
They help answer questions like:
When should a goroutine stop?
How do multiple goroutines react to a single event?
How do we wait for multiple events?
This section covers control-oriented patterns using channels.
Broadcast means one signal wakes up multiple goroutines.
Concept: close(channel)
When a channel is closed, all goroutines waiting to receive from it are unblocked immediately.
close(ch)
Any receive operation:
<-ch
will now proceed instantly.
Key Idea: Closing a channel acts like a broadcast signal
Example
package main
import (
"fmt"
"time"
)
func worker(id int, done <-chan struct{}) {
<-done
fmt.Println("Worker", id, "stopping")
}
func main() {
done := make(chan struct{})
for i := 1; i <= 3; i++ {
go worker(i, done)
}
time.Sleep(time.Second)
close(done) // broadcast signal
time.Sleep(time.Second)
}
Use Cases
Graceful shutdown
Cancellation signals
Stopping worker pools
Sometimes you don’t need to send data, only a signal.
Concept: chan struct{}
done := make(chan struct{})
Here:
struct{} = empty type (no data)
Why use struct{}?
Zero allocation
No memory overhead
Pure signaling
Example
package main
import "fmt"
func main() {
done := make(chan struct{})
go func() {
fmt.Println("Work done")
done <- struct{}{}
}()
<-done
fmt.Println("Received signal")
}
Use Cases
Done signals
Event notifications
Synchronization triggers
By default, channel operations block.
Sometimes you want to avoid waiting.
Concept: select + default
select {
case ch <- value:
// sent successfully
default:
// fallback (non-blocking)
}
Example
package main
import "fmt"
func main() {
ch := make(chan int)
select {
case ch <- 10:
fmt.Println("Sent")
default:
fmt.Println("Channel not ready, skipping")
}
}
Behavior
If send/receive is possible -> it executes
Otherwise -> default runs immediately
Use Cases
Polling systems
Avoiding deadlocks
Building responsive systems
The select statement allows a goroutine to wait on multiple channels simultaneously.
Concept
select {
case <-ch1:
// event from ch1
case <-ch2:
// event from ch2
}
Key Idea: Whichever channel is ready first wins
Example
package main
import (
"fmt"
"time"
)
func main() {
ch1 := make(chan string)
ch2 := make(chan string)
go func() {
time.Sleep(time.Second)
ch1 <- "from ch1"
}()
go func() {
time.Sleep(2 * time.Second)
ch2 <- "from ch2"
}()
select {
case msg := <-ch1:
fmt.Println(msg)
case msg := <-ch2:
fmt.Println(msg)
}
}
Output:
from ch1
With Timeout
select {
case res := <-ch:
fmt.Println(res)
case <-time.After(time.Second):
fmt.Println("timeout")
}
Use Cases
Orchestration between goroutines
Timeout handling
Cancellation patterns
Event-driven systems
In Go, time is not just a utility — it becomes part of your concurrency model.
Instead of writing blocking logic like:
sleep(5 seconds)
Go lets you communicate with time using channels.
Core Idea: Go’s time package provides channels that send signals based on time.
time.AfterConcept: time.After(duration) returns a channel that sends a signal after a delay.
Example
select {
case msg := <-ch:
fmt.Println("Received:", msg)
case <-time.After(2 * time.Second):
fmt.Println("Timeout!")
}
Explanation
If ch responds -> success
If nothing happens for 2 seconds -> timeout triggers
This prevents goroutine blocking forever
Use Cases
API calls
Worker jobs
Waiting for responses
time.TickConcept: time.Tick(interval) returns a channel that sends signals repeatedly.
Example
ticker := time.Tick(1 * time.Second)
for {
select {
case <-ticker:
fmt.Println("Running every second")
}
}
Explanation
Every 1 second -> signal is received
Loop keeps running forever
Important: time.Tick cannot be stopped
Better approach:
ticker := time.NewTicker(1 * time.Second)
defer ticker.Stop()
Use Cases
Background jobs
Metrics collection
Polling systems
time.TimerConcept: A Timer gives you manual control over timing
Example
timer := time.NewTimer(2 * time.Second)
<-timer.C
fmt.Println("Executed after delay")
Advanced Control
timer := time.NewTimer(2 * time.Second)
go func() {
time.Sleep(1 * time.Second)
timer.Stop()
}()
<-timer.C // may or may not fire
Why use Timer?
Can stop or reset
Better control than time.After
Pipeline communication is about processing data in stages, where each stage does one job and passes the result forward.
Core Idea
A pipeline looks like this:
source --> stage1 --> stage2 --> stage3 --> output
Each stage:
Runs in its own goroutine
Communicates via channels
Processes and forwards data
This creates a streaming flow of data
Why Pipelines?
Pipelines help you:
Break complex work into smaller steps
Process data concurrently
Stream data instead of waiting for everything
Example
func generator(nums ...int) <-chan int {
out := make(chan int)
go func() {
for _, n := range nums {
out <- n
}
close(out)
}()
return out
}
func square(in <-chan int) <-chan int {
out := make(chan int)
go func() {
for n := range in {
out <- n * n
}
close(out)
}()
return out
}
func main() {
nums := generator(1, 2, 3, 4)
squared := square(nums)
for result := range squared {
fmt.Println(result)
}
}
Context is how goroutines communicate control signals like:
Cancellation
Deadlines
Request-scoped data
Core Idea: Context is not for data — it’s for control
What is context.Context?
It’s an interface provided by Go that allows you to:
Cancel operations
Set timeouts
Pass request-level metadata
Key Concept: ctx.Done()
ctx.Done()
returns a channel that is closed when cancellation happens
Mental Model
ctx.Done() -> "Stop everything now"
Example (Cancellation)
ctx, cancel := context.WithCancel(context.Background())
go func() {
for {
select {
case <-ctx.Done():
fmt.Println("Stopped!")
return
default:
fmt.Println("Working...")
time.Sleep(500 * time.Millisecond)
}
}
}()
time.Sleep(2 * time.Second)
cancel()
What’s happening?
Goroutine keeps working
cancel() is called
ctx.Done() channel closes
Goroutine exits gracefully
Sometimes, using channels is not the best choice.
In those cases, goroutines share memory directly, and we control access using:
sync.Mutex
sync/atomic
Core Idea: Multiple goroutines access the same variable, but in a controlled way
A mutex ensures: “Only one goroutine can access this critical section at a time”
Example
var mu sync.Mutex
counter := 0
go func() {
mu.Lock()
counter++
mu.Unlock()
}()
What’s happening?
Lock() → enter critical section
Unlock() → release access
Prevents race conditions
Important Rule
Always unlock:
mu.Lock()
defer mu.Unlock()
Concept
Atomic operations are: “Low-level, lock-free, super-fast operations”
Example
var counter int32
go func() {
atomic.AddInt32(&counter, 1)
}()
Why atomic?
No locking overhead
Faster than mutex
Safe for simple operations
Basic Usage
A WaitGroup has three main methods:
Add(n) → number of goroutines to wait for
Done() → called when a goroutine finishes
Wait() → blocks until all are done
Example
package main
import (
"fmt"
"sync"
)
func worker(id int, wg *sync.WaitGroup) {
defer wg.Done() // signal completion
fmt.Println("Worker", id, "done")
}
func main() {
var wg sync.WaitGroup
for i := 1; i <= 3; i++ {
wg.Add(1) // register goroutine
go worker(i, &wg)
}
wg.Wait() // wait for all workers
fmt.Println("All workers finished")
}
Execution Flow
wg.Add(1) increases the counter
Each goroutine calls wg.Done() when finished
wg.Wait() blocks until the counter becomes zero
Important Rules
Always call Add() before starting the goroutine
Always use defer wg.Done() inside goroutines
Do not copy a WaitGroup (always pass by pointer)
When to Use WaitGroup
Waiting for multiple goroutines to finish
Coordinating parallel tasks
Ensuring graceful program completion
WaitGroup vs Channels
WaitGroup -> used for waiting
Channels -> used for communication
They are often used together in real-world systems.
Go’s concurrency model is both simple and powerful. With goroutines and channels, you can build systems where tasks run independently while staying safely coordinated. Instead of managing threads and locks, Go encourages a design based on communication and data flow.
Channels act as both data pipelines and synchronization points, making concurrent programs easier to understand and scale. Combined with tools like select, time, and context, they help handle real-world challenges like timeouts and cancellation.
The key idea is: share memory by communicating. Once you adopt this mindset, writing clean and efficient concurrent systems in Go becomes much more intuitive.