Go-Patterns

← Bank Account Drama | Series Overview | Login Counter → The Problem: Selling Tickets That Don’t Exist A concert has 1,000 tickets. Multiple goroutines handle sales concurrently. Each seller checks if tickets remain, and if yes, decrements the count and sells one. Sounds simple, right? Two sellers check simultaneously. Both see “1 ticket remaining.” Both sell. You’ve just sold ticket number -1. Congratulations, you’ve discovered the check-then-act race condition, one of the most common concurrency bugs in the wild. ...

← Monte Carlo Pi | Series Overview | Mandelbrot Set → The Problem: Finding Primes with Filters The Sieve of Eratosthenes is an ancient algorithm for finding prime numbers. The concurrent version creates a pipeline of filters: each prime spawns a goroutine that filters out its multiples. The Algorithm: Generate sequence: 2, 3, 4, 5, 6, 7, 8, 9, 10, … Take first number (2), it’s prime, filter all multiples of 2 Take next number (3), it’s prime, filter all multiples of 3 Take next number (5), it’s prime, filter all multiples of 5 Repeat until desired count The Beauty: Each prime creates its own filter. Numbers flow through a pipeline of increasingly selective filters. What passes through all filters must be prime. ...

← Login Counter | Series Overview | Sieve of Eratosthenes → The Problem: Computing Pi by Throwing Darts Imagine a square dartboard with a circle inscribed inside it. Throw random darts at the square. The ratio of darts landing inside the circle to total darts thrown approaches π/4. Why? Mathematics: Square side length: 2 (from -1 to 1) Square area: 4 Circle radius: 1 Circle area: π × 1² = π Ratio: π/4 Throw 1 million darts, multiply by 4, and you’ve estimated π. More darts = better estimate. This is Monte Carlo simulation: using randomness to solve deterministic problems. ...

← Sieve of Eratosthenes | Series Overview | Collatz Explorer → The Problem: Rendering Fractals in Parallel The Mandelbrot set is defined by a simple iterative formula: Start with z = 0 Repeatedly compute z = z² + c If |z| exceeds 2, the point escapes (not in the set) Color each pixel by iteration count The beauty: Each pixel is completely independent. Perfect for parallelism! The challenge: Some pixels escape in 5 iterations, others take 1000+. This creates load imbalance—some workers finish instantly while others grind away. ...

← Ticket Seller | Series Overview | Monte Carlo Pi → The Problem: Counting What You Can’t See Count concurrent users. On login: increment. On logout: decrement. Simple, right? Now add reality: The counter is distributed across multiple servers A user’s session times out on one server but they’re active on another The increment message arrives after the decrement message Network partitions split your cluster Servers crash mid-operation Suddenly, this “simple” counter becomes a distributed systems nightmare. Welcome to distributed counting, where even addition is hard. ...

← Mandelbrot Set | Series Overview The Problem: The Simplest Unsolved Math Problem The Collatz conjecture (3n+1 problem) is deceptively simple: Start with any positive integer n If n is even: divide by 2 If n is odd: multiply by 3 and add 1 Repeat until you reach 1 The conjecture: Every positive integer eventually reaches 1. Example (n=12): 12 → 6 → 3 → 10 → 5 → 16 → 8 → 4 → 2 → 1 The mystery: This has been verified for numbers up to 2^68, but never proven. It’s one of mathematics’ most famous unsolved problems. ...

← Login Counter | Series Overview | Ticket Seller → The Problem: Money Vanishing Into Thin Air Two people share a bank account with $100. Both check the balance at the same time, see $100, and both withdraw $100. The bank just lost $100. This isn’t a hypothetical—race conditions in financial systems have caused real monetary losses. The bank account drama illustrates the fundamental challenge of concurrent programming: read-modify-write operations are not atomic. What seems like a simple operation actually involves multiple steps, and when multiple goroutines execute these steps concurrently, chaos ensues. ...

📚 Go Design Patterns 🎯Behavioral Pattern ← Command Pattern 📋 All Patterns Observer Pattern → What is Chain of Responsibility? The Chain of Responsibility pattern is a behavioral design pattern that allows you to pass requests along a chain of handlers. Each handler decides whether to process the request or pass it to the next handler in the chain. This pattern decouples the sender of a request from its receivers by giving multiple objects a chance to handle the request. ...

Go Concurrency Patterns Series: Series Overview | Goroutine Basics | Channel Fundamentals Introduction: Welcome to Go Coffee Shop Imagine running a busy coffee shop. You have customers placing orders, baristas making drinks, shared equipment like espresso machines and milk steamers, and the constant challenge of managing it all efficiently. This is exactly what concurrent programming in Go is like - and goroutines are your baristas! In this comprehensive guide, we’ll explore Go’s concurrency patterns through the lens of running a coffee shop. By the end, you’ll understand not just how to write concurrent Go code, but why these patterns work and when to use them. ...

📚 Go Design Patterns 🎯Behavioral Pattern ← Observer Pattern 📋 All Patterns State Pattern → What is Iterator Pattern? The Iterator pattern provides a way to access elements of a collection sequentially without exposing the underlying representation. It’s like having a remote control for your TV - you don’t need to know how the channels are stored internally, you just press “next” to move through them. ...