Goroutines hum in a laptop’s fan-whirring depths, replaying bank events without a single overdraft glitch.
Concurrency vs parallelism in Go isn’t some abstract lecture — it’s the secret sauce turning Event Sourcing and CQRS from whiteboard dreams into bulletproof code. Picture that lone chef again, risotto simmering while he flips scallops, eyes on the sauce. That’s concurrency: juggling tasks on one core, fooling you into thinking magic’s afoot. Slam in ten chefs, each manning their station — parallelism, real multicore muscle flexing.
Rob Pike nailed it back in 2012:
“Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once.”
Everyone nods. Nobody gets it until their code race-conditions into oblivion.
Go? It hands you goroutines — featherweight threads, 2KB startups, millions without sweat. No OS thread bloat here. Fire ‘em up with ‘go’ keyword, and watch chaos compose.
Here’s a baby example:
package main
import (
"fmt"
"time"
)
func sayHello(name string) {
fmt.Println("Hello", name)
}
func main() {
go sayHello("Alice")
go sayHello("Bob")
go sayHello("Charlie")
time.Sleep(100 * time.Millisecond)
fmt.Println("Everyone said hello")
}
Output? Unpredictable. Alice first? Bob? Parallel on multicore? Maybe. That’s the thrill — and the terror.
But sharing data? Carnage without channels. Pipes for goroutines to whisper values, no shared memory nightmares.
package main
import "fmt"
func calculate(a, b int, result chan<- int) {
result <- a + b
}
func main() {
ch := make(chan int)
go calculate(3, 4, ch)
go calculate(10, 20, ch)
r1 := <-ch
r2 := <-ch
fmt.Println(r1, r2)
}
Sender closes channels. Receivers wait politely. Break that? Panic city.
Why Does Concurrency in Go Crush Traditional Event Sourcing Pitfalls?
Event Sourcing: Ditch the balance snapshot. Log every deposit, withdrawal — replay for truth. CQRS splits commands (writes, ordered) from queries (reads, parallelize ‘em).
Writes demand sequence — no two withdrawals faking a positive balance. Reads? Blast ‘em across cores.
Here’s the rub: naive multithreading? Race conditions devour your overdraft checks. Two goroutines peek at $100, both yank $80, boom — negative hell.
Go’s fix? Per-account channels. One goroutine per account, serializing commands. Other accounts? Parallel paradise.
My hot take — and this is the insight the originals gloss over: Go’s model echoes Erlang’s actor system from the ’80s telecom wars, but lighter, multicore-ready. It’s not hype; it’s the Unix pipes of tomorrow, primed for cloud-native event streams. Bold prediction: in five years, Kubernetes-sidecar event processors will all clone this pattern, making microservices actually reliable.
Take this banking beast:
type Account struct {
id string
balance float64
commands chan Command
}
type Command struct {
amount float64
response chan error
}
func (a *Account) process() {
// Loop forever, process one command at a time
for cmd := range a.commands {
if a.balance + cmd.amount < 0 {
cmd.response <- fmt.Errorf("insufficient funds")
} else {
a.balance += cmd.amount
cmd.response <- nil
}
}
}
func NewAccount(id string, initialBalance float64) *Account {
a := &Account{
id: id,
balance: initialBalance,
commands: make(chan Command, 10),
}
go a.process()
return a
}
Commands funnel in. Processed sequentially. No races. Scale to 10k accounts? Goroutines laugh.
How Do You Parallelize CQRS Reads Without Breaking Writes?
Writes: single goroutine, channel-serpentine.
Reads? Fan out. Replay events into projections — separate read models. Multiple goroutines crunch balances for queries, true parallelism on multicore feasts.
Imagine 100 users querying ledgers. Writes chug sequentially per account; reads explode in parallel, rebuilding projections from event logs. Speed? Night and day.
But here’s the corporate spin I’d skewer if this were AWS hawking it: they call it ‘serverless concurrency’ — nah, Go’s been doing pure, dev-owned concurrency for 15 years. No vendor lock-in vaporware.
Scale it: cluster of Go nodes, Kafka for events, channels everywhere. Eventual consistency? Handled. Your app? Feels instant.
Real-World Go Event Sourcing: From Chef to Production Kitchen
Start small. Build an account aggregator: deposits fire commands, queries spawn read goroutines replaying events into caches.
Add sync.WaitGroup for coordination — don’t sleep-hack main(). Channels for results, select{} multiplexing.
Pitfalls? Unbuffered channels deadlock if nobody receives. Buffered? Lose ordering hints. Learn by breaking — Go’s fast compiles encourage it.
Extend to CQRS full-tilt: command service routes to account goroutines. Query service replays events in parallel to materialized views. Databases? Postgres for events, Redis for projections. Boom.
And that historical parallel? Go’s concurrency revives Communicating Sequential Processes (CSP) from Hoare’s 1978 paper — theory meets multicore reality. While Java drowns in locks, Go flows like water.
🧬 Related Insights
- Read more: Blank Debian VM to Python CI/CD Pipeline: Zero to Hero in 60 Minutes
- Read more: Boreal UI: The React Library That Lets You Design Without the Design Drama
Frequently Asked Questions
What is concurrency vs parallelism in Go?
Concurrency juggles tasks (goroutines switching), even single-core. Parallelism cranks multiple cores simultaneously. Go blurs ‘em beautifully.
How does Go handle Event Sourcing with goroutines?
One goroutine per aggregate (like accounts) serializes events via channels. Prevents races, scales horizontally.
Will CQRS in Go replace my monolithic backend?
Not overnight — but pair it with clean separation, and yeah, it scales writes/reads independently like a dream.
Word count: ~950.
