DEV Community: Cem AKAN

Golang Design Patterns: Behavioral Patterns

Cem AKAN — Fri, 29 May 2026 19:48:35 +0000

Welcome back, Gophers ❤. If you’ve followed along from our previous dives, you know that building a system isn’t just about spawning objects or making them fit together. In the real world, things change. Objects need to talk, react, argue, delegate, and remember.

Behavioral Design Patterns are the protocols of communication. They don’t care about how an object is built or where it sits in the hierarchy. They care about intent. How does a change in one corner of your app ripple through to the other? How do you avoid a switch statement that grows into a 2,000 line monster?

In this final installment, we aren’t just writing code; we are choreographing a dance. We’re going to make your Go code feel less like a rigid machine and more like a living, breathing ecosystem.

The Roadmap for Part 3

This isn’t a quick read. This is a “grab a coffee and sit on the balcony” kind of read. Here is the map for our final expedition into the social dynamics of Go:

The Deciders: Strategy and State.
The Communicators: Observer and Mediator.
The Workers: Command and Chain of Responsibility.
The Organizers: Iterator and Visitor.
The Philosophers: Template Method and Memento.

Why Behavioral Patterns in Go?

Let’s be honest. Go isn’t Java. We don’t have traditional class inheritance. We have Interfaces and Composition. Because of this, Behavioral patterns in Go look… different. They are cleaner. They rely on Go’s unique implicitly implemented interfaces and powerful channels.

When you apply these patterns correctly in Go, you stop writing spaghetti code and start writing legos. You can pull a piece out, swap it for another, and the rest of the system doesn’t even blink.

Before We Dive In…

We’ve come a long way from the Singleton in Part 1. We’ve moved past the Facade in Part 2. Now, we are entering the world of Runtime Dynamics.

Ready to level up from a developer to a true Software Architect? Let’s begin our first step into the most common and powerful behavioral tool: The Strategy Pattern.

1. Strategy Pattern:

Imagine you are building a high-scale e-commerce engine. You have a Checkout process. Everything is going great until the marketing team says: “We need to support Credit Cards.” Then a week later: “We need PayPal.” Then: “Crypto is the future, add Bitcoin.” Without the Strategy Pattern, your Checkout function becomes a graveyard of if-else or switch statements. Every time you add a new payment method, you risk breaking the entire checkout flow.

The Strategy Pattern lets you define a family of algorithms (payment methods), put each of them into a separate struct, and make them interchangeable. The checkout process doesn’t care how you pay; it just knows it needs to call a Pay method

A) The Architecture:

B) Go Implementation: The Shopping Cart

Implementing the Strategy pattern in Go feels incredibly natural because of implicit interfaces. Unlike other languages, your structs don’t need a specific implements keyword to link them to an interface; if they have the required method, they simply work. In the example below, we treat our payment methods as plug-and-play components that the ShoppingCart uses without needing to know their internal secrets.

package main
import "fmt"
// 1. The Strategy Interface
// This is the Contract. Any new payment method must follow this.
type PaymentStrategy interface {
 Pay(amount int) string
}
// 2. Concrete Strategy: Credit Card
type CreditCard struct {
 CardNumber string
 CVV        string
}
func (cc *CreditCard) Pay(amount int) string {
 return fmt.Sprintf("Paid %d using Credit Card (No: %s)", amount, cc.CardNumber)
}
// 3. Concrete Strategy: PayPal
type PayPal struct {
 Email string
}
func (pp *PayPal) Pay(amount int) string {
 return fmt.Sprintf("Paid %d using PayPal (Email: %s)", amount, pp.Email)
}
// 4. The Context: ShoppingCart
// It doesn't know WHICH strategy it's using. It just uses "PaymentStrategy".
type ShoppingCart struct {
 TotalAmount int
 PaymentMethod PaymentStrategy
}
func (sc *ShoppingCart) SetPaymentMethod(method PaymentStrategy) {
 sc.PaymentMethod = method
}
func (sc *ShoppingCart) Checkout() {
 if sc.PaymentMethod == nil {
  fmt.Println("Error: Please select a payment method!")
  return
 }
 result := sc.PaymentMethod.Pay(sc.TotalAmount)
 fmt.Println(result)
}
func main() {
 cart := &ShoppingCart{TotalAmount: 500}
 // Dynamic decision at runtime: User chooses Credit Card
 cart.SetPaymentMethod(&CreditCard{CardNumber: "1234-5678", CVV: "123"})
 cart.Checkout()
 // Later, user changes mind and chooses PayPal
 cart.SetPaymentMethod(&PayPal{Email: "gopher@golang.org"})
 cart.Checkout()
}

C) The Architect’s Perspective:

Open/Closed Principle: You can add 50 new payment methods (Apple Pay, Stripe, Klarna) without changing a single line of code in the ShoppingCart or the Checkout logic.
Testability: You can easily pass a “MockPayment” strategy to test your checkout logic without actually hitting a bank API.
Clean Code: No more giant switch blocks. Each payment logic lives in its own small, manageable file.

While Strategy lets us swap algorithms from the outside, sometimes an object needs to change its behavior from the inside based on its own mood or status. That brings us to the internal logic of the State Pattern*.*

2. State Pattern:

If the Strategy pattern is about you (the client) choosing a tool, the State Pattern is about the object itself deciding how to act based on its internal mood.

Imagine a Vending Machine. If you press the dispense button when you haven’t put any money in, it does nothing. If you’ve inserted a coin, it gives you a soda. If the machine is out of stock, it returns your coin. The dispense button is the same, but the machine’s behavior depends entirely on its internal state.

In Go, we use this to eliminate the conditional hell, those massive switch or if-else blocks that check if doc.Status == "Draft" or if doc.Status == "Moderation". Instead, we let the status be its own object.

A) The Architecture:

B) Go Implementation: The Vending Machine

package main
import "fmt"
// 1. The State Interface
type State interface {
 RequestItem() error
 DispenseItem() error
}
// 2. The Context: VendingMachine
type VendingMachine struct {
 hasItemState   State
 noItemState    State
 itemCount      int
 currentState   State
}
func (v *VendingMachine) RequestItem() {
 err := v.currentState.RequestItem()
 if err != nil {
  fmt.Println(err)
  return
 }
 v.currentState.DispenseItem()
}
func (v *VendingMachine) setState(s State) {
 v.currentState = s
}
// 3. Concrete State: HasItem (The machine is ready)
type HasItemState struct {
 vendingMachine *VendingMachine
}
func (i *HasItemState) RequestItem() error {
 if i.vendingMachine.itemCount == 0 {
  i.vendingMachine.setState(i.vendingMachine.noItemState)
  return fmt.Errorf("Item out of stock")
 }
 fmt.Println("Item requested")
 return nil
}
func (i *HasItemState) DispenseItem() error {
 fmt.Println("Dispensing item")
 i.vendingMachine.itemCount--
 if i.vendingMachine.itemCount == 0 {
  i.vendingMachine.setState(i.vendingMachine.noItemState)
 }
 return nil
}
// 4. Concrete State: NoItem (Out of stock)
type NoItemState struct {
 vendingMachine *VendingMachine
}
func (i *NoItemState) RequestItem() error {
 return fmt.Errorf("Item out of stock")
}
func (i *NoItemState) DispenseItem() error {
 return fmt.Errorf("Item out of stock")
}
func main() {
 vendingMachine := &VendingMachine{
  itemCount: 1,
 }
 hasItemState := &HasItemState{vendingMachine: vendingMachine}
 noItemState := &NoItemState{vendingMachine: vendingMachine}
 vendingMachine.hasItemState = hasItemState
 vendingMachine.noItemState = noItemState
 // Set initial state
 vendingMachine.setState(hasItemState)
 // First request: Success
 vendingMachine.RequestItem()
 // Second request: Fails because it's now in NoItemState
 vendingMachine.RequestItem()
}

C) The Engineering Edge:

Single Responsibility: Each state-specific behavior is isolated in its own struct.
Encapsulation: The machine doesn’t need to check how many items are left every time a button is pressed; the state transitions handle that logic automatically.
Cleaner Transitions: Adding a MaintenanceState or PowerOffState doesn’t require rewriting the RequestItem function.

Now that our object can manage its internal changes effectively, how do we let the rest of the system know when something important has actually happened? Let’s tune into the notification broadcast of the Observer Pattern.

3. Observer Pattern:

In the e-commerce world, when an order is shipped, many things need to happen: the customer gets an email, the database updates, and the warehouse logs the exit. If you put all this code inside your ShipOrder() function, you've just built a god function that is impossible to maintain.

The Observer Pattern allows a subject to maintain a list of observers (Email, Warehouse, Analytics). When the subject changes, it shouts out to the list, and everyone reacts in their own way.

A) The Architecture:

B) Go Implementation: The Order Notification System

package main
import "fmt"
// 1. The Observer Interface
type Observer interface {
 Update(string)
}
// 2. The Subject (Publisher)
type OrderManager struct {
 observers []Observer
}
func (o *OrderManager) Register(observer Observer) {
 o.observers = append(o.observers, observer)
}
func (o *OrderManager) Notify(orderID string) {
 for _, observer := range o.observers {
  observer.Update(orderID)
 }
}
// 3. Concrete Observer: Email Service
type EmailService struct{}
func (e *EmailService) Update(orderID string) {
 fmt.Printf("Email Service: Sending confirmation for order %s\n", orderID)
}
// 4. Concrete Observer: Warehouse Service
type WarehouseService struct{}
func (w *WarehouseService) Update(orderID string) {
 fmt.Printf("Warehouse: Preparing items for order %s\n", orderID)
}
func main() {
 manager := &OrderManager{}
 // Registering different departments
 manager.Register(&EmailService{})
 manager.Register(&WarehouseService{})
 fmt.Println("New order received!")
 manager.Notify("ORDER_7788")
}

C) Gopher Wisdom:

Decoupling: The OrderManager doesn't know the EmailService exists. It just knows it has a list of things that want to be updated.
Scalability: Need to add a Slack notification for the team? Just create a SlackObserver struct and register it. You don't have to touch a single line of the existing OrderManager code.
Asynchronicity: In a real-world Go app, a senior developer would often run the Notify loop in separate goroutines or use channels, allowing the main process to continue without waiting for every observer to finish.

Observers are great for broadcasts, but when too many objects start shouting at each other, the network becomes a chaotic web of dependencies. To bring order to this chaos, we need an air traffic controller: the Mediator Pattern.

4. Mediator Pattern:

As your application grows, you’ll find that objects start knowing too much about each other. A button needs to talk to a text field, which needs to talk to a checkbox, which needs to trigger a save operation. This leads to a spaghetti dependency where every object is connected to every other object (O(N²) complexity).

The Mediator Pattern solves this by forcing objects to stop talking to each other directly. Instead, they all talk to a central Mediator. Think of it as an Air Traffic Control Tower: pilots don’t call other pilots to coordinate landings; they all talk to the tower. The tower manages the traffic, and the pilots just follow instructions.

A) The Architecture:

B)Go Implementation: Air Traffic Control

In Go, the Mediator pattern is powerful because it allows us to keep our plane structs very slim. They don’t need to know about other planes; they only need to hold a reference to the Mediator interface.

package main
import "fmt"
// 1. The Mediator Interface
type Mediator interface {
 Notify(sender string, event string)
}
// 2. The Components (Colleagues)
type Plane struct {
 callSign string
 mediator Mediator
}
func (p *Plane) RequestLanding() {
 fmt.Printf("Plane %s: Requesting permission to land.\n", p.callSign)
 p.mediator.Notify(p.callSign, "landing_requested")
}
func (p *Plane) Land() {
 fmt.Printf("Plane %s: I am landing. Clear the runway!\n", p.callSign)
}
// 3. The Concrete Mediator
type ControlTower struct {
 planes map[string]*Plane
}
func (c *ControlTower) RegisterPlane(p *Plane) {
 c.planes[p.callSign] = p
}
func (c *ControlTower) Notify(sender string, event string) {
 if event == "landing_requested" {
  fmt.Printf("Tower: Received landing request from %s. Checking runway...\n", sender)

  // The tower coordinates: Telling other planes to hold
  for callSign, plane := range c.planes {
   if callSign != sender {
    fmt.Printf("Tower: Telling %s to circle and wait.\n", callSign)
   }
  }

  // Permission granted to the sender
  c.planes[sender].Land()
 }
}
func main() {
 tower := &ControlTower{planes: make(map[string]*Plane)}
 plane1 := &Plane{callSign: "GopherAir-101", mediator: tower}
 plane2 := &Plane{callSign: "SkyGo-502", mediator: tower}
 tower.RegisterPlane(plane1)
 tower.RegisterPlane(plane2)
 // Plane 1 initiates the request through the mediator
 plane1.RequestLanding()
}

C) Why This Wins at Scale:

Reduced Coupling: The planes are completely oblivious to each other. You could have 1,000 planes, and none of them would need to store a list of the other 999.
Centralized Logic: If the rules for landing change (e.g., emergency priority), you only change the logic in the ControlTower, not in every single Plane struct.
Ease of Reuse: Because the Plane only depends on a Mediator interface, you can reuse the same Plane logic in a different "World" or simulation just by passing a different mediator.

Centralizing communication is key, but what if we want to package the actual request itself into a standalone, portable object? It’s time to wrap our intents into capsules with the Command Pattern.

5. Command Pattern:

In a growing application, you often want to trigger actions from different places. For example, a save action could be triggered by a button, a keyboard shortcut (Ctrl+S), or an auto-save timer. If you hardcode the save logic into the button, you’ll have to duplicate it for the shortcut and the timer.

The Command Pattern solves this by turning the request into a stand-alone object. Think of a Restaurant Order Slip: the waiter (Invoker) doesn’t need to know how to cook a pizza; they just write the request on a slip (Command) and hand it to the kitchen. The chef (Receiver) eventually takes the slip and performs the work. This allows you to queue requests, log them, or even undo them later.

A) The Architecture:

B) Go Implementation: The Universal Remote

In Go, the Command pattern is incredibly clean. Since we use interfaces, the Invoker (the Remote Control) doesn’t need to know if it’s turning on a light, a TV, or an air conditioner. It just calls Execute()

package main
import "fmt"
// 1. The Command Interface
type Command interface {
 Execute()
}
// 2. The Receiver: Light
// This is the object that actually knows HOW to do the work.
type Light struct {
 isOn bool
}
func (l *Light) On() {
 l.isOn = true
 fmt.Println("Light is ON")
}
func (l *Light) Off() {
 l.isOn = false
 fmt.Println("Light is OFF")
}
// 3. Concrete Command: Turn Light On
type LightOnCommand struct {
 light *Light
}
func (c *LightOnCommand) Execute() {
 c.light.On()
}
// 4. Concrete Command: Turn Light Off
type LightOffCommand struct {
 light *Light
}
func (c *LightOffCommand) Execute() {
 c.light.Off()
}
// 5. The Invoker: Remote Control
type RemoteControl struct {
 command Command
}
func (r *RemoteControl) SetCommand(c Command) {
 r.command = c
}
func (r *RemoteControl) PressButton() {
 r.command.Execute()
}
func main() {
 // Create the Receiver
 livingRoomLight := &Light{}
 // Create Concrete Commands
 lightOn := &LightOnCommand{light: livingRoomLight}
 lightOff := &LightOffCommand{light: livingRoomLight}
 // Create the Invoker
 remote := &RemoteControl{}
 // Turning the light ON
 remote.SetCommand(lightOn)
 remote.PressButton()
 // Turning the light OFF
 remote.SetCommand(lightOff)
 remote.PressButton()
}

C) The Clean Code Advantage:

Undo/Redo Capability: By storing a history of Command objects in a stack, you can easily implement “Undo” by adding an Unexecute() method to the interface.
Command Queueing: You can store commands in a slice and process them one by one. This is perfect for background tasks or job processors.
Decoupling Sender and Receiver: The RemoteControl (Sender) has zero knowledge of the Light (Receiver). This makes your UI code completely independent of your business logic.

A Command carries a specific intent, but what if that intent needs to pass through a series of checkpoints or filters before being executed? Let’s build a relay race of logic with the Chain of Responsibility Pattern.

6. Chain of Responsibility Pattern:

Imagine you are calling technical support. First, you talk to an automated bot. If the bot can’t solve your “how do I reset my password” question, it passes you to a Level 1 Operator. If your problem is a complex server crash, the operator passes you to a Senior Engineer. This is the Chain of Responsibility.

In software, we use this when an order or a request needs to go through multiple stages like authentication, logging, validation, and caching. Instead of one giant function doing everything, you create a chain of independent handlers. Each handler does its job and decides: “Do I solve this now, or do I pass it to the next person?”.

A) The Architecture:

B) Go Implementation: The Middleware Chain

In Go, this pattern is the secret sauce behind almost every major web framework’s Middleware. Each step is a handler that decides whether to stop the request or let it flow to the next one.

package main
import "fmt"
// 1. The Handler Interface
// It defines how to link handlers and how to process the request.
type Handler interface {
 Execute(*Data)
 SetNext(Handler)
}
// Data represents the request context
type Data struct {
 IsAuthenticated bool
 IsValidated     bool
 IsCached        bool
}
// 2. Base Handler: Authentication
type AuthHandler struct {
 next Handler
}
func (h *AuthHandler) SetNext(next Handler) {
 h.next = next
}
func (h *AuthHandler) Execute(d *Data) {
 if d.IsAuthenticated {
  fmt.Println("Auth: User already authenticated. Passing to next...")
  if h.next != nil {
   h.next.Execute(d)
  }
  return
 }
 fmt.Println("Auth: Authenticating user...")
 d.IsAuthenticated = true
 if h.next != nil {
  h.next.Execute(d)
 }
}
// 3. Concrete Handler: Validation
type ValidationHandler struct {
 next Handler
}
func (h *ValidationHandler) SetNext(next Handler) {
 h.next = next
}
func (h *ValidationHandler) Execute(d *Data) {
 if d.IsValidated {
  fmt.Println("Validation: Data already validated. Passing...")
  if h.next != nil {
   h.next.Execute(d)
  }
  return
 }
 fmt.Println("Validation: Validating request data...")
 d.IsValidated = true
 if h.next != nil {
  h.next.Execute(d)
 }
}
func main() {
 // Initialize handlers
 auth := &AuthHandler{}
 validation := &ValidationHandler{}
 // Create the chain: Auth -> Validation
 auth.SetNext(validation)
 // Execute the request
 requestData := &Data{}
 fmt.Println("Chain: Starting request processing...")
 auth.Execute(requestData)
 fmt.Printf("\nFinal Result: Auth: %v, Valid: %v\n", 
  requestData.IsAuthenticated, requestData.IsValidated)
}

C) Beyond the Syntax:

Single Responsibility: Your authentication logic doesn’t know about validation logic. You can change one without touching the other.
Dynamic Chains: You can change the order of the chain at runtime. Want to check the cache before authentication? Just swap the SetNext calls.
Open/Closed Principle: You can add a LoggerHandler or a MetricsHandler anywhere in the chain without modifying existing handlers.

Relaying requests through a chain is vital for logic flow, but what about moving through your actual data? To navigate complex collections without getting lost in the implementation details, we reach for the Iterator Pattern.

7. Iterator Pattern:

In Go, we deal with slices and maps all the time. But what happens when your data is stored in a complex Binary Tree, a Graph, or a Linked List? If you force the client to understand how to traverse a tree (Left -> Root -> Right), you are leaking implementation details.

The Iterator Pattern provides a way to access elements of a collection without exposing its underlying representation. Think of Prayer Beads (Tespih) or a TV Remote: you don’t care how the beads are strung together or how the channels are stored in the TV’s memory; you just press the

A) The Architecture:

B) Go Implementation: The User Collection

Go doesn’t have a built-in Iterator interface like Java or C#, so we define our own. This is especially useful when your collection is fetched from an API in pages, and you want to hide that paging logic from the user.

package main
import "fmt"
// 1. The Item
type User struct {
 Name string
}
// 2. The Iterator Interface
type Iterator interface {
 HasNext() bool
 Next() *User
}
// 3. The Collection Interface
type Collection interface {
 CreateIterator() Iterator
}
// 4. Concrete Collection
type UserCollection struct {
 users []*User
}
func (u *UserCollection) CreateIterator() Iterator {
 return &UserIterator{
  users: u.users,
 }
}
// 5. Concrete Iterator
type UserIterator struct {
 index int
 users []*User
}
func (u *UserIterator) HasNext() bool {
 return u.index < len(u.users)
}
func (u *UserIterator) Next() *User {
 if u.HasNext() {
  user := u.users[u.index]
  u.index++
  return user
 }
 return nil
}
func main() {
 // Creating a collection
 user1 := &User{Name: "Alice"}
 user2 := &User{Name: "Bob"}
 user3 := &User{Name: "Charlie"}
 collection := &UserCollection{
  users: []*User{user1, user2, user3},
 }
 // Traversing using the Iterator
 iterator := collection.CreateIterator()
 fmt.Println("Iterator: Walking through the users...")
 for iterator.HasNext() {
  user := iterator.Next()
  fmt.Printf("User: %s\n", user.Name)
 }
}

C) Architectural Mastery:

Encapsulation: The client doesn’t know if users is a slice, a map, or a linked list. You could change the internal storage to a complex tree tomorrow, and the for iterator.HasNext() loop wouldn't change a single character.
Uniform Interface: It allows you to write generic functions that can process any collection (Users, Products, Orders) as long as they provide an iterator.
Safety: It prevents the client from accidentally modifying the collection while iterating, as they only have access to the Next() element, not the underlying slice index.

Now that we know how to walk through every element in a collection, how do we perform specialized operations on them without cluttering their original code? Let’s invite a specialist in with the Visitor Pattern.

8. Visitor Pattern:

As a project grows, your data structs often become god objects. You start with a clean Project struct, but then you add ExportToPDF(), then CalculateTax(), then ValidateSecurity(). Soon, your data structures are bloated with logic that has nothing to do with data.

The Visitor Pattern separates the algorithms from the objects on which they operate. Think of a doctor’s visit: the patient (the Struct) stays still. A heart specialist (Visitor A) comes to check the heart, then a LungsSpecialist (Visitor B) comes to check the lungs. You don’t add DoHeartCheck() methods inside the Patient struct; you let external specialists "visit" the patient and perform their specific task.

A) The Architecture:

B) Go Implementation: The Project Exporter

In Go, the Visitor pattern is your ultimate weapon for defending the open/closed principle. It allows your data structs to stay clean and focused strictly on data. By defining an Accept method in our structs, we create a simple protocol that allows any external specialist whether they are exporting to PDF, calculating taxes, or auditing security to step in and work without us ever touching the original struct code again.

package main
import "fmt"
// 1. The Visitor Interface
// Defines what the "Specialist" can do to each type of data.
type Visitor interface {
 VisitTask(*Task)
 VisitEmployee(*Employee)
}
// 2. The Element Interface
// This allows our data structs to host a Visitor.
type Element interface {
 Accept(Visitor)
}
// 3. Concrete Element: Task
type Task struct {
 Name string
}
func (t *Task) Accept(v Visitor) {
 v.VisitTask(t)
}
// 4. Concrete Element: Employee
type Employee struct {
 Name string
}
func (e *Employee) Accept(v Visitor) {
 v.VisitEmployee(e)
}
// 5. Concrete Visitor: PDF Exporter
type PDFExporter struct{}
func (p *PDFExporter) VisitTask(t *Task) {
 fmt.Printf("PDF: Creating a beautiful page for Task [%s]\n", t.Name)
}
func (p *PDFExporter) VisitEmployee(e *Employee) {
 fmt.Printf("PDF: Adding Employee [%s] to the project appendix\n", e.Name)
}
// 6. Concrete Visitor: Payroll Specialist
type PayrollSpecialist struct{}
func (ps *PayrollSpecialist) VisitTask(t *Task) {
 // Tasks don't affect payroll, so we just skip.
}
func (ps *PayrollSpecialist) VisitEmployee(e *Employee) {
 fmt.Printf("Payroll: Calculating salary and bonuses for %s...\n", e.Name)
}
func main() {
 // Our data structures
 projectElements := []Element{
  &Task{Name: "Refactor Database"},
  &Employee{Name: "Gopher Senior"},
 }
 // Operation 1: The CEO wants a PDF Export
 pdfExporter := &PDFExporter{}
 fmt.Println("--- Action: Generating PDF ---")
 for _, el := range projectElements {
  el.Accept(pdfExporter)
 }
 // Operation 2: HR wants to run Payroll
 payroll := &PayrollSpecialist{}
 fmt.Println("\n--- Action: Running Payroll ---")
 for _, el := range projectElements {
  el.Accept(payroll)
 }
}

C) Why Seasoned Gophers Prefer This:

Open/Closed Principle: You can add 10 new operations (JSON Export, Security Audit, Time Tracking) without changing a single line of code in the Task or Employee structs.
Separation of Concerns: Your data structs stay clean. They only contain the fields they need. All extraneous logic like exporting or calculating is moved to dedicated Visitor classes.
Flexibility: It’s especially useful when dealing with complex object trees (like a file system or a project structure) where you need to perform different actions depending on the specific type of node you encounter.

Visitor allows us to add external logic to our structs, but sometimes we need a fixed internal skeleton for an algorithm while leaving the specific steps to the implementation. This brings us to the Template Pattern.

9. Template Pattern:

In engineering, we often have a fixed process that only varies in one or two steps. For example, every data miner follows the same workflow:

Open File -> Extract Data -> [Parse Specific Format] -> Close File.

If you write three different classes for CSV, PDF, and JSON, you’ll end up duplicating the Open and Close logic everywhere.

The Template Method defines the skeleton of an algorithm in a base class but allows subclasses to override specific steps without changing the algorithm’s overall structure. It’s like a Coloring Book : the lines are already drawn (the template), but you decide which colors to fill in (the implementation).

A) The Architecture:

B) Go Implementation: The Data Miner

Since Go doesn’t have abstract classes, we implement the Template Method by creating a master function or struct that accepts an interface for the variable steps.

package main
import "fmt"
// 1. The Interface for variable steps
type Miner interface {
 Open()
 Parse()
 Close()
}
// 2. The "Template" Function
// This defines the fixed skeleton of the algorithm.
func RunMining(m Miner) {
 fmt.Println("Template: Starting Workflow...")
 m.Open()
 m.Parse()
 m.Close()
 fmt.Println("Template: Workflow Completed.\n")
}
// 3. Concrete Implementation: CSV Miner
type CSVMiner struct{}
func (c *CSVMiner) Open() {
 fmt.Println("CSV: Opening comma-separated file.")
}
func (c *CSVMiner) Parse() {
 fmt.Println("CSV: Parsing rows and columns.")
}
func (c *CSVMiner) Close() {
 fmt.Println("CSV: Closing file handle.")
}
// 4. Concrete Implementation: PDF Miner
type PDFMiner struct{}
func (p *PDFMiner) Open() {
 fmt.Println("PDF: Opening binary document.")
}
func (p *PDFMiner) Parse() {
 fmt.Println("PDF: Extracting text from coordinates.")
}
func (p *PDFMiner) Close() {
 fmt.Println("PDF: Clearing memory buffers.")
}
func main() {
 // Execute CSV Mining
 csv := &CSVMiner{}
 RunMining(csv)
 // Execute PDF Mining
 pdf := &PDFMiner{}
 RunMining(pdf)
}

C) Future-Proofing Your Logic:

DRY (Don’t Repeat Yourself): You write the high-level logic (error handling, logging, step order) only once in the template.
Consistency: Every parser is guaranteed to close the file because the Close() call is baked into the template, not left to the individual developer's memory.
Hook Support: You can add hooks (optional steps) in the template. For example, a Validate() step that does nothing by default but can be overridden by specific miners if needed.

The Template Method ensures our workflows are consistent, but even the best workflows need a safety net. To capture a moment in time and undo any mistakes along the way, we need the save point of the Memento Pattern.

10. Memento Pattern:

Have you ever spent hours writing code only to realize your logic was fundamentally flawed, wishing you could just hit a global undo button? That is the essence of the Memento Pattern.

In complex applications, objects change state constantly. Sometimes, you need to save a snapshot of an object’s state so you can restore it later without exposing its private internals to the rest of the world. Think of it as a save point in a video game: you save your progress before a boss fight.

A)The Architecture:

B)Go Implementation: The Undo System

In Go, we keep the Memento struct simple and immutable. The Originator (the Editor) is the only one who knows how to use the Memento to travel back in time.

package main
import "fmt"
// 1. The Memento
// This is a "value object" that stores the state. It should be immutable.
type Memento struct {
 state string
}
func (m *Memento) GetSavedState() string {
 return m.state
}
// 2. The Originator
// This is the object whose state we want to save.
type Editor struct {
 content string
}
func (e *Editor) Write(text string) {
 e.content += text
}
func (e *Editor) Save() *Memento {
 fmt.Printf("Editor: Saving snapshot -> \"%s\"\n", e.content)
 return &Memento{state: e.content}
}
func (e *Editor) Restore(m *Memento) {
 e.content = m.GetSavedState()
 fmt.Printf("Editor: State restored to -> \"%s\"\n", e.content)
}
// 3. The Caretaker
// Manages the history of mementos.
type History struct {
 mementos []*Memento
}
func (h *History) Push(m *Memento) {
 h.mementos = append(h.mementos, m)
}
func (h *History) Pop() *Memento {
 if len(h.mementos) == 0 {
  return nil
 }
 lastIndex := len(h.mementos) - 1
 m := h.mementos[lastIndex]
 h.mementos = h.mementos[:lastIndex]
 return m
}
func main() {
 editor := &Editor{}
 history := &History{}
 // Step 1: User writes something and saves
 editor.Write("Hello ")
 history.Push(editor.Save())
 // Step 2: User writes more and saves
 editor.Write("World!")
 history.Push(editor.Save())
 // Step 3: User makes a mistake
 editor.Write(" This is a mess.")
 fmt.Printf("Current Content: %s\n", editor.content)
 // Step 4: Undo
 fmt.Println("Action: User clicks Undo.")
 editor.Restore(history.Pop()) // Back to "Hello World!"

 // Step 5: Undo again
 editor.Restore(history.Pop()) // Back to "Hello "
}

C) The Maintainability Factor:

Encapsulation Protection: The History (Caretaker) stores the state but has no idea what’s inside it. It just holds a black box.
Memory Management: A Senior architect knows that storing thousands of mementos can kill RAM. You would implement a limited stack (e.g., only the last 20 actions) or use diff-based snapshots for large data.
Separation of Concerns: The Editor focuses on editing. The History focuses on storage. Neither leaks logic into the other.

Behavioral Cheat Sheet

We’ve choreographed the dance. We’ve turned our rigid machine into an ecosystem. To help you choose the right partner for your next Go project, here is the ultimate behavioral summary:

You’ve finished the trilogy. You now have the Creational tools to build your world, the Structural glue to hold it together, and the Behavioral intelligence to make it move.

Go is a language of simplicity. These patterns are not meant to make your code fancy, they are meant to make it resilient. Use them wisely, don’t over-engineer, and always remember: Code is for humans to read, and only incidentally for machines to execute.

Keep building, keep learning, and Keep calm and recover() from your panic ;))

See you in the next article 🚀

Golang Design Patterns: Structural Patterns.

Cem AKAN — Fri, 29 May 2026 19:45:01 +0000

Welcome back, Gophers ❤

In the first part of this series, we mastered the art of creation learning how to spawn objects like a pro using Singletons, Factories, and Builders. But let’s be honest: creating objects is the easy part. The real challenge starts when those objects need to talk to each other without turning your codebase into a plate of spaghetti code.

Welcome to Part 2: Structural Patterns.

Think of these patterns as the architectural glue of your software. If Creational Patterns are about the bricks, Structural Patterns are about how you arrange those bricks to build a skyscraper that won’t collapse when the wind blows. We’re going to explore how to make your Go structs and interfaces work together in harmony, keeping your system flexible, efficient, and most importantly clean.

Ready to level up from a coder to an architect? Let’s dive into the structural magic of Go :)

2- Structural Patterns

Structural Patterns are design patterns that focus on how classes and objects are combined to create larger structures. They simplify the relationships between entities, making the system more flexible and easier to maintain.

Adapter Pattern:

We can imagine this pattern like a real electric adapter. When we plug an adapter into a socket, it converts high voltage to lower voltage.

Without adapters, we would need sockets for every voltage type in our walls. Thanks to adapters, we have one main source that we can convert to suit our needs.

Okay, I added an example for this method. First, let’s look at a diagram of the example, and after that, I will explain it.

Diagram:

First of all, we need to understand why we used the adapter pattern in our payment system. We implemented it to unify various payment methods under a single main interface because each payment system API has its own uniquely named functions.

Define the Main Payment Interface: We start by defining a common interface with a single “Pay” method prototype.
Implement Payment Structs and Functions: Next, we create structs for each payment method and implement their specific payment functions.
Create Adapter Structs: Finally, we define adapter structs that wrap the existing payment structs. These adapter structs provide methods with the same name as the main payment interface’s method.

By using these adapter structs, we can call the specific payment functions through a unified interface, allowing us to work with different payment systems in a consistent manner.

Code:

package main
import "fmt"
//Payment interface with pay method
type Payment interface {
 Pay(amount float32) string
}
//Paypal struct
type Paypal struct{}
//Paypal pay method 
func (p *Paypal) payingWithPaypal(amount float32) string {
 return fmt.Sprintf("Paying with paypal: %f", amount)
}
//Adapter for paypal
type adapterPaypal struct {
 paypal *Paypal
}
//Pay method for adapter paypal
func (a *adapterPaypal) Pay(amount float32) string {
 return a.paypal.payingWithPaypal(amount)
}
//Stripe struct
type Stripe struct{}
//Stripe pay method
func (s *Stripe) payingWithStripe(amount float32) string {
 return fmt.Sprintf("Paying with stripe: %f", amount)
}
//Adapter for stripe
type adapterStripe struct {
 stripe *Stripe
}
//Pay method for adapter stripe
func (a *adapterStripe) Pay(amount float32) string {
 return a.stripe.payingWithStripe(amount)
}
func main() {
 //Create paypal and stripe objects
 paypal := &Paypal{}
 stripe := &Stripe{}
 //Create adapters
 paypalAdapter := &adapterPaypal{paypal}
 stripeAdapter := &adapterStripe{stripe}
 //Pay with paypal and stripe
 fmt.Println(paypalAdapter.Pay(100))
 fmt.Println(stripeAdapter.Pay(200))
}

Bridge Pattern:

We use the Bridge method when our project has multiple interfaces and their related functions need to be combined. Instead of writing special functions for each combination, we utilize the Bridge pattern.

Okay, let’s look at an example diagram and code.

Diagram:

I want to explain the Bridge method using an example from the Adapter method. I’ve added some functions to make it suitable for the Bridge pattern. Now, we have a new, comprehensive interface for payment platforms and platform structures with their related order functions.

Previously, we linked all payment methods using the Adapter method, so when we use the general ‘Pay’ function, it selects the appropriate type for the operation.

Instead of writing specialized functions for each platform and payment method combination, we use the general ‘Pay’ function within the platform’s order functions.

Code:

package main
import "fmt"
// Payment interface with pay method
type Payment interface {
 Pay(amount float32) string
}
// Paypal struct
type Paypal struct{}
// Paypal pay method
func (p *Paypal) payingWithPaypal(amount float32) string {
 return fmt.Sprintf("Paying with paypal: %f", amount)
}
// Adapter for paypal
type adapterPaypal struct {
 paypal *Paypal
}
// Pay method for adapter paypal
func (a *adapterPaypal) Pay(amount float32) string {
 return a.paypal.payingWithPaypal(amount)
}
// Stripe struct
type Stripe struct{}
// Stripe pay method
func (s *Stripe) payingWithStripe(amount float32) string {
 return fmt.Sprintf("Paying with stripe: %f", amount)
}
// Adapter for stripe
type adapterStripe struct {
 stripe *Stripe
}
// Pay method for adapter stripe
func (a *adapterStripe) Pay(amount float32) string {
 return a.stripe.payingWithStripe(amount)
}
// giveOrder interface
type giveOrder interface {
 giveOrder(amount float32)
}
// WebSite struct
type WebSite struct {
 Paying Payment
}
// giveOrder method for website
func (w *WebSite) giveOrder(amount float32) {
 fmt.Printf("Order given: %f", amount)
 w.Paying.Pay(amount)
}
//mobileApp struct
type MobileApp struct {
 Paying Payment
}
// giveOrder method for mobileApp
func (m *MobileApp) giveOrder(amount float32) {
 fmt.Printf("Order given: %f", amount)
 m.Paying.Pay(amount)
}
func main() {
 //Create paypal and stripe objects
 paypal := &Paypal{}
 stripe := &Stripe{}
 //Create adapters
 paypalAdapter := &adapterPaypal{paypal}
 stripeAdapter := &adapterStripe{stripe}
 //Create website and mobileApp objects
 website := &WebSite{Paying: paypalAdapter}
 mobileapp := &MobileApp{Paying: stripeAdapter}
 //Give order
 website.giveOrder(100)
 mobileapp.giveOrder(200)
}

Composite Pattern:

We use the Composite Pattern for projects that involve tree-like structures. These structures can include elements that contain sub-elements or elements at the same level.

With this pattern, we can execute specific functions for each element.

Now, let’s take a look at an example diagram and code.

Diagram:

After creating all the objects and adding them, we use the top element’s “ShowInfo” function. Thanks to the “ShowInfo” function, we can execute the appropriate function for each element by calling the “ShowInfo” function of other types or by using it recursively.

Code:

package main
import "fmt"
// Component interface is the base interface for all components
type Component interface {
 // ShowInfo method is used to show the information of the component
 ShowInfo() string
}
// Employee struct is a leaf component
type Employee struct {
 name string
}
// ShowInfo method is used to show the information of the employee
func (e Employee) ShowInfo() string {
 return "\t Employee: " + e.name + "\n"
}
// Team struct is a composite component that contains employees and other teams
type Team struct {
 name       string
 Components []Component
}
// ShowInfo method is used to show the information of the team
func (t Team) ShowInfo() string {
 result := "Team: " + t.name + "\n"

 for _, comp := range t.Components {
      result += "\t" + comp.ShowInfo()
 }
 return result
}
// AddComponent method is used to add a component to the team
func (t *Team) AddComponent(c Component) {
 t.Components = append(t.Components, c)
}
// Department struct is a composite component that contains teams and other departments
type Department struct {
 name       string
 Components []Component
}
// ShowInfo method is used to show the information of the department
func (d Department) ShowInfo() string {
 result := "Department: " + d.name + "\n"
 for _, comp := range d.Components {
    result += "\t" + comp.ShowInfo()
 }
 return result
}
// AddComponent method is used to add a component to the department
func (d *Department) AddComponent(c Component) {
 d.Components = append(d.Components, c)
}
func main() {
 // Diagram
 /*
                           Department A
                           /          \
                Deparment B           Team A
                /         \           /     \
           Team B        Team C    Team D   Em. A
          /      \      /     \     /    \
        Em.B   Em.C  Em.D    Em.E  Em.F   Em.G
 */
 // Create Employees
 employeeA := Employee{name: "A"}
 employeeB := Employee{name: "B"}
 employeeC := Employee{name: "C"}
 employeeD := Employee{name: "D"}
 employeeE := Employee{name: "E"}
 employeeF := Employee{name: "F"}
 employeeG := Employee{name: "G"}
 // Create Teams
 teamA := Team{name: "A"}
 teamB := Team{name: "B"}
 teamC := Team{name: "C"}
 teamD := Team{name: "D"}
 // Create Departments
 departmentA := Department{name: "A"}
 departmentB := Department{name: "B"}

 // Add Employees to Teams
   // Team D
 teamD.AddComponent(employeeG)
 teamD.AddComponent(employeeF)

   // Team A
 teamA.AddComponent(employeeA)

   // Team B
 teamB.AddComponent(employeeB)
 teamB.AddComponent(employeeC)

   // Team C
 teamC.AddComponent(employeeD)
 teamC.AddComponent(employeeE)

 // Add Sub Teams to Teams
   //Team A
 teamA.AddComponent(teamD)

 // Add Teams to Departments
   // Department B
 departmentB.AddComponent(teamB)
 departmentB.AddComponent(teamC)
   // Department A
 departmentA.AddComponent(teamA)

 // Add Sub Departments to Departments
   // Department A
 departmentA.AddComponent(departmentB)

 // Show Info
 fmt.Println(departmentA.ShowInfo())
}

Facade Pattern:

Architecture is often about hiding a messy truth behind a beautiful exterior. In Go, we use the Facade pattern to provide a clean and simple entry point to a complex set of classes. It acts as the master controller that shields users from internal systemic chaos.

Diagram:

By maintaining references to the TV, SoundSystem, and Lights, the facade manages their full lifecycle and ensures operations happen in the correct order.

The diagram illustrates a clean hierarchy where the facade wraps complex subsystems into a single interface. The user calls one simple command, triggering an orchestrated sequence across multiple objects that otherwise operate independently. This design keeps your main logic decoupled from low-level details, making the entire structure significantly more resilient to change.

Code:

package main
import fmt
// Subsystem 1: The Visuals
type TV struct{}
func (t *TV) On() {
    fmt.Println(`TV is now powering on...`)
}
func (t *TV) Off() {
    fmt.Println(`TV is shutting down.`)
}
// Subsystem 2: The Audio
type SoundSystem struct{}
func (s *SoundSystem) SetVolume(level int) {
    fmt.Printf(`Adjusting speakers to volume level: %d\n`, level)
}
func (s *SoundSystem) Off() {
    fmt.Println(`Surround sound system turned off.`)
}
// Subsystem 3: The Atmosphere
type Lights struct{}
func (l *Lights) Dim(percent int) {
    fmt.Printf(`Dimming house lights to %d percent.\n`, percent)
}
func (l *Lights) Reset() {
    fmt.Println(`Lights returned to full brightness.`)
}
// The Facade: The master controller for the theater
type HomeTheaterFacade struct {
    tv     *TV
    audio  *SoundSystem
    lights *Lights
}
// NewHomeTheaterFacade initializes the complex dependencies
func NewHomeTheaterFacade() *HomeTheaterFacade {
    return &HomeTheaterFacade{
        tv:     &TV{},
        audio:  &SoundSystem{},
        lights: &Lights{},
    }
}
// WatchMovie provides the simplified entry point
func (h *HomeTheaterFacade) WatchMovie() {
    fmt.Println(`Preparing the theater for your movie...`)
    h.lights.Dim(20)
    h.tv.On()
    h.audio.SetVolume(15)
    fmt.Println(`Enjoy the show!`)
}
// EndMovie handles the cleanup in one call
func (h *HomeTheaterFacade) EndMovie() {
    fmt.Println(`Cleaning up after the movie...`)
    h.tv.Off()
    h.audio.Off()
    h.lights.Reset()
}
func main() {
    // The client only interacts with the simple facade interface
    theater := NewHomeTheaterFacade()

    // Start the complex sequence with one click
    theater.WatchMovie()

    fmt.Println(`--- Time passes ---`)

    // Shut everything down with one click
    theater.EndMovie()
}

Proxy Pattern:

Now that we’ve simplified the interface with Facade, let’s see how we can control access to those objects using Proxy.

Proxy pattern acts as a sophisticated gatekeeper for your objects. While the Facade pattern simplifies an entire subsystem, the Proxy pattern focuses on a single object, acting as a substitute or placeholder to control access to it. It can handle lazy initialization, perform access control, or add logging without the client ever knowing the difference

Diagram:

To understand how the Proxy sits between your user and your logic, let us look at a network server implementation. The following diagram visualizes how the Proxy implements the same interface as the real service, allowing it to disguise itself perfectly while managing the request lifecycle.

The true strength of the Proxy stems from its ability to act as a seamless intermediary where both the proxy and the actual service implement the same interface to remain perfectly interchangeable from the perspective of the client.

By taking full responsibility for the lifecycle of the service object, it can defer heavy initialization until the exact moment it is needed, effectively saving system resources.

Most importantly, it serves as a sophisticated gatekeeper that can validate credentials, enforce rate limits, or return cached results before the real application logic is even triggered, keeping your core system protected and highly efficient.

Code:

package main
import "fmt"
// Server defines the common interface for both proxy and real object
type Server interface {
    HandleRequest(url, method string) (int, string)
}
// RealApplication provides the primary business logic
type RealApplication struct{}
func (r *RealApplication) HandleRequest(url, method string) (int, string) {
    if url == "/app/status" && method == "GET" {
        return 200, "OK: Application is healthy"
    }
    return 404, "Not Found"
}
// NginxProxy acts as a placeholder to control access
type NginxProxy struct {
    application       *RealApplication
    maxAllowedRequest int
    rateLimiter       map[string]int
}
// NewNginxProxy manages the lifecycle of the RealApplication
func NewNginxProxy() *NginxProxy {
    return &NginxProxy{
        application:       &RealApplication{},
        maxAllowedRequest: 2,
        rateLimiter:       make(map[string]int),
    }
}
// HandleRequest performs access control before delegating to the real service
func (n *NginxProxy) HandleRequest(url, method string) (int, string) {
    allowed := n.checkRateLimit(url)
    if !allowed {
        return 403, "Not Allowed: Rate limit exceeded"
    }
    // Logging behavior added by the proxy
    fmt.Printf("Proxy: Forwarding %s request to %s\n", method, url)

    // Delegation to the real service
    return n.application.HandleRequest(url, method)
}
func (n *NginxProxy) checkRateLimit(url string) bool {
    if n.rateLimiter[url] >= n.maxAllowedRequest {
        return false
    }
    n.rateLimiter[url]++
    return true
}
func main() {
    // The Client works with the Proxy via the Server interface
    var server Server = NewHomeProxy()
    appUrl := "/app/status"
    // Request 1: Passes through
    code, body := server.HandleRequest(appUrl, "GET")
    fmt.Printf("Status: %d | Body: %s\n", code, body)
    // Request 2: Passes through
    code, body = server.HandleRequest(appUrl, "GET")
    fmt.Printf("Status: %d | Body: %s\n", code, body)
    // Request 3: Blocked by the Proxy (Rate Limit)
    code, body = server.HandleRequest(appUrl, "GET")
    fmt.Printf("Status: %d | Body: %s\n", code, body)
}
// Helper to match diagram name
func NewHomeProxy() Server {
    return NewNginxProxy()
}

Decorator Pattern:

While inheritance feels like a permanent tattoo on your class hierarchy, decoration is more like a custom outfit you change based on the weather. In the world of Go, we often reach a point where creating a new subclass for every possible feature combination leads to a combinatorial explosion of types. The Decorator pattern solves this by letting you wrap objects inside other objects, adding superpowers to them at runtime without ever touching the original code.

Think of it as the programming equivalent of a Matryoshka doll. You start with a simple base, and then you keep wrapping it in layers of functionality. Each layer knows how to do its own small job and then delegates the rest to the object inside it.

Diagram:

The genius of this pattern is found in its recursive nature where both the foundation and the enhancements speak the same language through a shared interface. By treating the core component and its wrappers as equals, we can stack behaviors infinitely like an onion, allowing each layer to perform its specific duty before handing the task deeper into the stack.

This approach keeps your primary business logic isolated from the endless combinations of optional features, giving your system the freedom to grow and adapt without the need for a massive, hard-to-maintain hierarchy .

Code:

package main
import fmt
// Beverage defines the common ground for all coffee types
type Beverage interface {
    GetDescription() string
    GetPrice() int
}
// BasicCoffee is the essential core of our system
type BasicCoffee struct{}
func (c *BasicCoffee) GetDescription() string {
    return "Basic Coffee"
}
func (c *BasicCoffee) GetPrice() int {
    return 10
}
// MilkDecorator enhances the beverage with milk logic
type MilkDecorator struct {
    beverage Beverage
}
func (m *MilkDecorator) GetDescription() string {
    return m.beverage.GetDescription() + ", Milk"
}
func (m *MilkDecorator) GetPrice() int {
    return m.beverage.GetPrice() + 5
}
// SugarDecorator adds a sweet layer to the drink
type SugarDecorator struct {
    beverage Beverage
}
func (s *SugarDecorator) GetDescription() string {
    return s.beverage.GetDescription() + ", Sugar"
}
func (s *SugarDecorator) GetPrice() int {
    return s.beverage.GetPrice() + 2
}
func main() {
    // We start with a plain order
    order := Beverage(&BasicCoffee{})
    fmt.Printf("Initial Order: %s | Total: %d\n", order.GetDescription(), order.GetPrice())
    // We dynamically wrap the order in milk
    order = &MilkDecorator{beverage: order}
    fmt.Printf("Updated Order: %s | Total: %d\n", order.GetDescription(), order.GetPrice())
    // Finally, we add sugar on top of the milk-wrapped coffee
    order = &SugarDecorator{beverage: order}
    fmt.Printf("Final Order: %s | Total: %d\n", order.GetDescription(), order.GetPrice())
}

Flyweight Pattern:

Now we arrive at our final destination: the Flyweight pattern. This is not just a performance trick; it is an act of respect for limited resources. Imagine rendering a forest with millions of trees in a game. If every tree carries its own heavy textures and models, your RAM will suffocate.

Flyweight asks a simple question: Does every object really need its own copy of everything? By sharing common traits like colors or textures across millions of instances, we keep the system light and efficient

Diagram:

At the heart of the Flyweight lies the division of state. The TreeType represents the intrinsic state heavy data like names and colors that never change. The Tree represents the extrinsic state unique data like coordinates and a pointer to the shared type. The TreeFactory acts as a gatekeeper, ensuring that if a type already exists in memory, it is reused rather than duplicated.

This allows your system to handle massive amounts of objects while maintaining a minimal memory footprint.

Code:

package main
import "fmt"
// TreeType stores shared, unchanging data (Intrinsic)
type TreeType struct {
    name  string
    color string
}
func (t *TreeType) Draw(x, y int) {
    fmt.Printf("Drawing %s tree in %s at %d:%d\n", t.name, t.color, x, y)
}
// TreeFactory manages and reuses shared objects
type TreeFactory struct {
    treeTypes map[string]*TreeType
}
func (f *TreeFactory) GetTreeType(name, color string) *TreeType {
    if f.treeTypes == nil {
        f.treeTypes = make(map[string]*TreeType)
    }
    if _, exists := f.treeTypes[name]; !exists {
        f.treeTypes[name] = &TreeType{name: name, color: color}
        fmt.Println("Shared type created: "+ name)
    }
    return f.treeTypes[name]
}
// Tree stores unique, contextual data (Extrinsic)
type Tree struct {
    x, y    int
    typePtr *TreeType
}
func (t *Tree) Draw() {
    t.typePtr.Draw(t.x, t.y)
}
func main() {
    factory := &TreeFactory{}
    pineType := factory.GetTreeType("Pine", "Green")

    forest := []Tree{
        {x: 1, y: 5, typePtr: pineType},
        {x: 10, y: 20, typePtr: pineType},
    }
    for _, tree := range forest {
        tree.Draw()
    }
}

We’ve covered a lot of ground today. To help you choose the right tool for your architectural needs, I’ve prepared a quick summary table. Think of this as your cheat sheet for structural patterns:

And there you have it. We’ve just toured the structural wonders of the Go world. From the Adapter to the Flyweight, you now have the tools to compose complex systems that remain elegant and easy to manage.

Remember: A good developer writes code that works; a great developer builds structures that last.

But wait… our journey isn’t over yet. We know how to create objects, and we know how to organize them. But how do we handle the complex communication and ‘social lives’ of these objects? How do they react when things change?

In the third and final part of this series, we will dive into Behavioral Patterns. We’ll be talking about Strategy, Observer, State, and more. It’s where your code truly comes to life.

Stay tuned, keep coding, and don’t let your pointers dangle.

See you in Part-3 🚀

Golang Design Patterns: Creational Patterns

Cem AKAN — Fri, 29 May 2026 19:43:24 +0000

Hello, Go enthusiasts. Welcome to the first installment of our deep dive into Golang Design Patterns 🎉

In this part, we’ll be mastering the Creational Patterns. These patterns are the fundamental building blocks for sophisticated software architecture, focusing on making your object creation process flexible, reusable, and decoupled from your core business logic.

We’ve explored five powerful techniques:

Singleton Pattern
Factory Pattern
Abstract Factory Pattern
Builder Pattern
Prototype Pattern

Let’s start :)

First of all, what is the design patterns?

Especially, we can see this term after object-oriented programming (OOP) entered our lives. After the long development years, programmers saw they repeated using the same templates. And these repeated patterns showed us that if we solved a problem in one of them, we could solve the other repeated ones. So, programmers created an approach which includes common problems and solution methods for repeated structures and named it design patterns.

We can categorize design patterns in three subtitles: Creational Patterns, Structural Patterns and Behavioral Patterns.

1- Creational Patterns:

We use creational patterns for manage object creation process and optimize it.

Singleton Pattern:

Our first creational pattern is singelton pattern. We use this method for creation only one object from the struct in our project. In singelton method, if we try to re-create a same type object after the first create, our program must detects it and returns first created object to us.

We provide an example of this method to make it more understandable. So let’s look at the diagram and code for the example below.

Diagram:

We define a struct which name is “Singelton”. It has a string variable. And we create a variable from it and was named it “instance”. After that, we define a function for assignment to instance variable. With this function, we also limited the create with one and provide to return first created object for later creates.

Code:

package main
import (
 "fmt"
 "sync"
)
// Singleton struct represents the Singleton design pattern.
// It has a single instance that is shared across the application.
type Singleton struct {
 value string // value holds the state or data for the Singleton instance
}
// instance holds the single instance of Singleton. It is initialized as nil.
var instance *Singleton
// once ensures that the Singleton instance is created only once.
// sync.Once is a type from the sync package that allows a function to be executed only once.
var once sync.Once
// GetInstance returns the single instance of Singleton. 
// It creates the instance if it doesn't already exist.
func GetInstance() *Singleton {
 // sync.Once.Do ensures that the provided function is executed only once.
 // This guarantees that only one instance of Singleton is created.
 once.Do(func() {
  instance = &Singleton{
   value: "Singleton Instance", // Initialize the Singleton instance with a default value
  }
 })
 return instance
}
// main function demonstrates the usage of the Singleton pattern.
func main() {
 // Retrieve the Singleton instance using GetInstance.
 singleton1 := GetInstance()
 singleton2 := GetInstance()
 // Print the value of both instances.
 // Since Singleton is a singleton, both instances should have the same value.
 fmt.Println(singleton1.value) // Output: Singleton Instance
 fmt.Println(singleton2.value) // Output: Singleton Instance
 // Check if both instances are the same.
 // This should return true because Singleton ensures only one instance exists.
 if singleton1 == singleton2 {
  fmt.Println("Both instances are the same.")
 } else {
  fmt.Println("Instances are different.")
 }
}

Factory Pattern:

Factory pattern (virtual constructor) provides an interface for creating objects, but let superclasses decide which type of objects that will be created.

Commonly, we use this method to define functions with the same purpose for different structs and avoid using different names for these functions by collecting them into a common interface. This approach helps us manage user functions more clearly in our service.

Okay, let’s make an example to understand it more clearly.

Imagine that you’re creating a geometry calculator application. It can calculate square’s and circle’s area and perimeter with their piece’s length.

But these calculator functions should have same name for clear user controls. So we give them “area” and “perim” names.

Now, let’s look at the diagram below and examine the mechanism of our code. If you don’t fully understand, don’t worry; everything will be explained at the end of the diagram.

Diagram:

Firstly, we define a two struct scheme: “circle” and “square” which has special parameters. And we define functions: “area” and “perim” which return’s type float64, and we link them with “areaAndPerim” interface to reach them above struct with their common names. After that we create a super function which name is “GeometryFactory”. It creates struct based on the user’s choice and returns “areaAndPerim” interface.

In the final, when users import our service, they can only see the super function and interface based common functions.

Now that we understand the concept, we can look at its implementation in code.

Code:

package main
// we import the math package to use the math.Pi constant
import "math"
type (
 // we define a circle struct with a radius field of type float64
 circle struct {
  radius float64
 }
 // we define a square struct with a side field of type float64
 square struct {
  side float64
 }
 // we define an interface with two methods area and perim that return float64 values
 areaAndPerim interface {
  area() float64
  perim() float64
 }
)
// we define the area method for the circle struct
func (c circle) area() float64 {
 return 2 * math.Pi * c.radius
}
// we define the perim method for the circle struct
func (c circle) perim() float64 {
 return math.Pi * c.radius * c.radius
}
// we define the area method for the square struct
func (s square) area() float64 {
 return s.side * s.side
}
// we define the perim method for the square struct
func (s square) perim() float64 {
 return 4 * s.side
}
// we define a GeometryFactory function that returns an areaAndPerim interface
func GeometryFactory(typeName string, pieceLength float64) areaAndPerim {
 // if the typeName is circle, we return a circle struct with the radius equal to pieceLength
 if typeName == "circle" {
  return circle{radius: pieceLength}
  // if the typeName is square, we return a square struct with the side equal to pieceLength
 } else if typeName == "square" {
  return square{side: pieceLength}
  // if the typeName is neither circle nor square, we return nil
 } else {
  return nil
 }
}
func main() {
 // we create a circle and a square with the GeometryFactory function
 c := GeometryFactory("circle", 5)
 s := GeometryFactory("square", 5)
 // we print the area and perim of the circle and the square
 println(c.area())
 println(c.perim())
 println(s.area())
 println(s.perim())
}

Abstract Factory Pattern:

We use abstract factory method, when we work on multiple factories. We make a main factory maker function to reach them. And after that we can use all features of created factories.

Then, without losing any time, let’s look at an example diagram and code for this pattern.

Diagram:

In this example, we have two factory complexes. We want to manage them using a single main factory creator function, which we call “AbstractFactory” in the diagram. Using this main function, we can create individual factories and utilize their specific substructures and functions through the associated interfaces.

However, we need to ensure that the abstract factory’s return function (import variables) and interface{} are correctly configured. Our factories must have the same type and number of variables, and their prototype forms should be defined in the abstract factory. To provide a common prototype, we use interface{} for the return type.

After creating a factory, to use it, we should append the specific interface name of that factory with parentheses.

Code:

package main
import "fmt"
type (
 // Structs definition
 A struct {
  text string
 }
 B struct {
  text string
 }
 C struct {
  text string
 }
 D struct {
  text string
 }
 // Interfaces definitions
 InterfaceA interface {
  Func1() string
  Func2() string
 }
 InterfaceB interface {
  Func3() string
  Func4() string
 }
 // Abstract Factory definition for simple returns
 Factory func(string, string) interface{}
)
//function for interfaceA
// functions for struct A
func (a *A) Func1() string {
 return a.text + " Func1"
}
func (a *A) Func2() string {
 return a.text + " Func2"
}
// functions for struct B
func (b *B) Func1() string {
 return b.text + " Func1"
}
func (b *B) Func2() string {
 return b.text + " Func2"
}
//function for interfaceB
// functions for struct C
func (c *C) Func3() string {
 return c.text + " Func3"
}
func (c *C) Func4() string {
 return c.text + " Func4"
}
// functions for struct D
func (d *D) Func3() string {
 return d.text + " Func3"
}
func (d *D) Func4() string {
 return d.text + " Func4"
}
// Factory functions definitions. They create a struct based on typeName and return the interface{} type
// Factory function for interfaceA
func FirstFactory(typeName, text string) interface{} {
 switch typeName {
 case "A":
  return &A{text}
 case "B":
  return &B{text}
 }
 return nil
}
// Factory function for interfaceB
func SecondFactory(typeName, text string) interface{} {
 switch typeName {
 case "C":
  return &C{text}
 case "D":
  return &D{text}
 }
 return nil
}
// Abstract Factory for first and second factories. It returns a factory function based on the factoryType, with these functions we can create structs based on the typeName
func CreateFactory(factoryType string) Factory {
 switch factoryType {
 case "FirstFactory":
  return FirstFactory
 case "SecondFactory":
  return SecondFactory
 }
 return nil
}
// Main function,
func main() {
 // Setup the first factory
 firstFactory := CreateFactory("FirstFactory")
 // Create a struct A
 a := firstFactory("A", "Hello").(InterfaceA)
 // Setup the second factory
 secondFactory := CreateFactory("SecondFactory")
 // Create a struct C
 c := secondFactory("C", "World").(InterfaceB)
 // Call the functions for the structs
 fmt.Println(a.Func1())
 fmt.Println(c.Func3())
}
/*
Output:
Hello Func1
World Func3
*/

Builder Pattern:

The Builder pattern is used for step-by-step construction of complex objects that have numerous optional components. It is especially useful when a product has multiple configurations.

When it was used, we can use predefined functions in addition to step-by-step functions that provide creating custom objects.

Okay, let’s look at an example diagram and code for this pattern.

Graph:

We define a “ConcretePizzaBuilder” struct that include “Pizza” struct to create methods. With this we can links configuration functions with each others.

In configuration functions we return the PizzaBuilder interface for continuing to change same object in the configuration function chain.

In the final, we end our function chain with the “Buid” function that returns “Pizza” object in the ConcretePizzaBuilder struct.

Also, we can use pre-defined functions to create objects. For using these functions, we PizzaDirector struct.

Code:

package main
import "fmt"
type (
 // Pizza struct represents a pizza
 Pizza struct {
  size      string
  cheese    bool
  pepperoni bool
 }
 // PizzaBuilder is an interface for creating a pizza
 PizzaBuilder interface {
  SetSize(size string) PizzaBuilder
  AddPepperoni() PizzaBuilder
  AddCheese() PizzaBuilder
  Build() Pizza
 }
 // ConcertePizzaBuilder is a struct that implements PizzaBuilder
 ConcertePizzaBuilder struct {
  pizza Pizza
 }
 // PizzaDirector is a struct that directs the creation of a pizza
 PizzaDirector struct{}
)
// SetSize sets the size of the pizza
func (pb *ConcertePizzaBuilder) SetSize(size string) PizzaBuilder {
 pb.pizza.size = size
 // Set default values
 pb.pizza.cheese = false
 pb.pizza.pepperoni = false
 return pb
}
// AddPepperoni adds pepperoni to the pizza
func (pb *ConcertePizzaBuilder) AddPepperoni() PizzaBuilder {
 pb.pizza.pepperoni = true
 return pb
}
// AddCheese adds cheese to the pizza
func (pb *ConcertePizzaBuilder) AddCheese() PizzaBuilder {
 pb.pizza.cheese = true
 return pb
}
// Build builds the pizza
func (pb *ConcertePizzaBuilder) Build() Pizza {
 return pb.pizza
}
// Predefined pizza creator functions
// CreatePepperoniPizza creates a pepperoni pizza of a given size
func (pd *PizzaDirector) CreatePepperoniPizza(size string, builder PizzaBuilder) Pizza {
 return builder.SetSize(size).AddPepperoni().AddCheese().Build()
}
func main() {
 // initialize the builder and director objects
 builder := &ConcertePizzaBuilder{}
 director := &PizzaDirector{}
 // Create a large pizza with pepperoni and cheese
 pizza := director.CreatePepperoniPizza("large", builder)
 fmt.Println("Predefined pepperoni pizza:", "size:", pizza.size, "cheese:", pizza.cheese, "pepperoni:", pizza.pepperoni)
 // Custom pizza creation
 // Create a custom pizza with medium size with cheese
 customPizza := builder.SetSize("medium").AddCheese().Build()
 fmt.Println("Custom pizza:", "size:", customPizza.size, "cheese:", customPizza.cheese, "pepperoni:", customPizza.pepperoni)
}

Prototype Pattern:

The Prototype pattern allows you to copy existing objects without making your code dependent on related objects.

The idea is to create new objects by copying an existing prototype rather than building them from scratch.

This pattern is particularly useful when object creation is time-consuming and costly.

Okay, let’s look at an example diagram and code.

Diagram:

Firstly, we define a “Cloner” interface which contains “Clone” method function which associate with “Rectangle” and “Circle” structs. After the defining related structs, we start to define the “Clone” functions.

The function, it use created objects parameters for cloning to new one. After that, it returns “Cloner” interface to back because return object’s type can be change.

Finally, in the end of “Clone” function call, we should add object’s struct name between brackets to define their type.

Code:

package main
import "fmt"
type (
 // define Cloner interface
 Cloner interface {
  Clone() Cloner
 }
 // define Rectangle struct with Width & Height parameters
 Rectangle struct {
  Width, Height int
 }
 //define Circle struct with Radius parameter
 Circle struct {
  Radius int
 }
)
// cloner function for Circle
func (c *Circle) Clone() Cloner {
 newCircle := &Circle{
  Radius: c.Radius,
 }
 return newCircle
}
// cloner function for Rectangle
func (r *Rectangle) Clone() Cloner {
 newRectangle := &Rectangle{
  Width:  r.Width,
  Height: r.Height,
 }
 return newRectangle
}
func main() {
 // create new Circle object
 circle := Circle{
  Radius: 10,
 }
 // clone Circle object
 newCircle := circle.Clone().(*Circle)
 // create new Rectangle object
 rectangle := Rectangle{
  Width:  10,
  Height: 20,
 }
 // clone Rectangle object
 newRectangle := rectangle.Clone().(*Rectangle)
 // print newCircle object
 fmt.Println(newCircle)
 // print newRectangle object
 fmt.Println(newRectangle)
}

We’ve laid the groundwork for flexible and controlled object creation in Go by covering the Singleton, Factory, Abstract Factory, Builder, and Prototype patterns. These are your tools for writing decoupled, scalable, and maintainable code.

Next time, we shift gears to Structural Patterns, learning how to compose Go’s structs and interfaces into robust, beautiful architectures.

Don’t miss out. Stay tuned. Byee :D

I Built a Chaos Engine That Goes Where No Tool Has Gone Before

Cem AKAN — Fri, 29 May 2026 19:36:47 +0000

No team. No budget. Just Go. This is the engineering deep dive behind pastaay, a chaos engine that breaks everything from HTTP headers to physical memory.

1. Why This Exists

I started this project with a simple question: why do all chaos engineering tools stop at the network?

Netflix’s Chaos Monkey kills instances. That’s useful if your failure mode is “pod died.” Gremlin adds CPU spikes. Litmus runs pod level experiments in Kubernetes. They’re all valuable tools. But none of them let you walk into a single Go binary and say: “intercept this gRPC bidirectional stream, drop every third Kafka message, corrupt this MongoDB aggregation pipeline, and while you’re at it, eat 2GB of RAM and burn 4 CPU cores for 30 seconds.” None of them give you one YAML file that defines destruction across seven different protocols plus the OS itself, then deploys that destruction through a CLI with a dead man’s switch, a Kubernetes operator managing CRDs, or an AI that reads your live Prometheus metrics and writes the attack plan for you.

This is the gap pastaay fills. It’s not a wrapper around existing tools. It’s not a YAML generator for litmus experiments. Every interceptor, every operator controller, every JavaScript panel, every line of Go is built from scratch.

The name comes from paSta’ay, a ritual of Taiwan’s Saisiyat people honoring the Da’ai, a tribe of diminutive but uncommonly powerful spirits. Chaos, remembrance, and things that punch above their weight. Seemed fitting.

Let me walk you through how each piece works, with real code, real architecture diagrams, and the real engineering decisions behind them.

2. System Architecture

Before we dive into individual components, here’s how the entire system fits together:

The engine has three entry points, web console, CLI, and Kubernetes operator, all feeding into the same Config Manager. The Manager holds the source of truth: an atomic pointer to the current configuration. Every interceptor reads from this pointer on every request. The file watcher updates this pointer when the YAML changes on disk. The telemetry bus collects events from every layer and feeds them to the web console, Prometheus, and OpenTelemetry.

3. The Policy Engine

3.1 O(1) Lookup Without a Single Heap Allocation

This is the most important performance decision in the entire project. On every HTTP request, literally every request your application serves, pastaay needs to check: “is there an active policy that targets this path?” If that check allocates memory, and you’re serving 50,000 requests per second, you’re creating 50,000 heap allocations per second. The garbage collector will eat you alive.

The solution is a type-indexed cache behind an atomic pointer. Thanks to Go 1.19’s atomic.Pointer, we can do this safely and cleanly without interface{} type assertions:

type Manager struct {
    mu            sync.Mutex
    cfg           atomic.Pointer[PastaayConfig]
    typedPolicies atomic.Pointer[map[string][]Policy]
    startTime     time.Time
    sensorStatus  sync.Map
}
func (m *Manager) GetActivePolicies(policyType string) []Policy {
    ptr := m.typedPolicies.Load()
    cfg := m.cfg.Load()
    if ptr == nil || (cfg != nil && time.Since(m.startTime) < cfg.WarmupDuration) {
        return nil
    }
    return (*ptr)[policyType]
}

When the configuration is updated (by file watcher, webhook, or operator), the Manager takes a write lock once, rebuilds the type-indexed map, and atomically swaps the pointer. Every subsequent read, and there are potentially millions of reads per second, is just an atomic load followed by a map lookup. Zero allocation. Zero lock contention.

The warmup check at the top prevents chaos from triggering during the initial configuration load. If your application starts and chaos policies fire before the server is ready, you get a false-positive outage. The warmup period (default 10 seconds) gives everything time to stabilize.

3.2 Stable Hashing for Policy Identity

Every policy gets a deterministic FNV-1a hash computed from all its fields:

func generateStableHash(p *Policy) uint64 {
    // FNV-1a: a non-cryptographic hash that distributes well
    // and is deterministic, same input always produces same output.
    var h uint64 = 14695981039346656037 // FNV offset basis
    const fnvPrime uint64 = 1099511628211
    // Hash string fields with field separators to prevent
    // "ab" + "c" from colliding with "a" + "bc".
    sep := func() { h ^= 0; h *= fnvPrime }
    for _, s := range []string{p.Name, p.Target, p.Type, p.ErrorBody, p.StreamRollMode} {
        for i := 0; i < len(s); i++ {
            h ^= uint64(s[i])
            h *= fnvPrime
        }
        sep()
    }
    // ... numeric fields, match headers ...
    return h
}

Why does this matter? The resource sabotage daemon uses policy hashes for deduplication. If you change a policy’s RAM chunk from 256MB to 512MB, the hash changes, and the daemon kills the old RAM leaker and spawns a new one. If nothing changed, the daemon does nothing. This prevents the classic “restart all goroutines on every config reload” problem.

3.3 SQL Command Normalization

SQL interception has a unique challenge: the same logical query can have different textual representations. SELECT * FROM users and select * from users and SELECT * FROM users are the same query. The CleanSQLCommand function normalizes SQL text by stripping comments, collapsing whitespace, and uppercasing:

func CleanSQLCommand(cmd string) string {
    var result strings.Builder
    inString := false
    var stringChar byte
    for i := 0; i < len(cmd); i++ {
        char := cmd[i]
        if char == '\'' || char == '"' {
            // Handle escaped quotes
            isEscaped := false
            for j := i - 1; j >= 0 && cmd[j] == '\\'; j-- {
                isEscaped = !isEscaped
            }
            if !isEscaped {
                if inString && char == stringChar {
                    inString = false
                } else if !inString {
                    inString = true
                    stringChar = char
                }
            }
        }
        if !inString {
            if char == '-' && i+1 < len(cmd) && cmd[i+1] == '-' {
                // Skip SQL line comment
                for i < len(cmd) && cmd[i] != '\n' {
                    i++
                }
                result.WriteByte(' ')
                continue
            }
        }
        result.WriteByte(char)
    }
    return strings.ToUpper(strings.Trim(result.String(), " \r\n\t;()"))
}

This is one of those functions that looks simple but took three iterations to get right. The string aware comment stripping (so inside a SQL string literal doesn't get treated as a comment) was the hardest part. Version 1 used a regex. Version 2 used a simple loop but broke on escaped quotes. Version 3 (this one) is the first that handles all edge cases correctly.

4. The Config Manager

4.1 Atomic Pointer Swap: How Policy Updates Don’t Block Requests

The Manager’s Update method is the only write path. It's protected by a mutex, but that mutex is never contended during normal operation because updates happen rarely (once per config file change). Here's the full method:

func (m *Manager) Update(newCfg *PastaayConfig) {
    m.mu.Lock()
    defer m.mu.Unlock()
    if newCfg != nil {
        // Pre-compute all policy metadata
        for i := range newCfg.Policies {
            p := &newCfg.Policies[i]
            // Generate metric tag (type:target, truncated to 64 chars)
            tag := p.Type + ":" + p.Target
            if len(tag) > 64 {
                tag = tag[:61] + "..."
            }
            p.MetricTag = tag
            // SQL regex compilation
            if strings.EqualFold(p.Type, "sql") {
                // ... compile regex for SQL target matching ...
            }
            // Compute stable FNV-1a hash
            p.PolicyHash = generateStableHash(p)
        }
        m.cfg.Store(newCfg)
    }
    // Rebuild type-indexed cache
    cache := make(map[string][]Policy)
    if newCfg != nil {
        for _, p := range newCfg.Policies {
            cache[p.Type] = append(cache[p.Type], p)
        }
    }
    m.typedPolicies.Store(&cache)
}

The critical design choice here: the metadata pre-computation happens under the write lock, not on the hot path. Every interceptor calls GetActivePolicies which does nothing but an atomic load and a map lookup. The regex compilation, hash computation, and metric tag generation all happen once during the update, not millions of times during request processing.

5. The Hot Reload Watcher

5.1 Why File Watching Is Harder Than You Think

The naive approach to watching a configuration file:

watcher, _ := fsnotify.NewWatcher()
watcher.Add("pastaay.yaml")
for event := range watcher.Events {
    if event.Has(fsnotify.Write) {
        reload()
    }
}

This breaks in production. Here’s why:

Vim writes use a temp file then rename. The watcher sees a RENAME event, not WRITE.
Kubernetes ConfigMaps create a symlink swap. The old inode is deleted, a new one appears.
Atomic editors (like sed -i) create a new file and rename it over the old one.
Multiple write events fire for a single logical change. Without debouncing, you reload the config 4 times in 10 milliseconds.

Pastaay’s watcher handles all of these:

const debounceWindow = 300 * time.Millisecond
func WatchConfig(filePath string, reloadCallback func(*PastaayConfig)) (cancel func(), err error) {
    ctx, cancelCtx := context.WithCancel(context.Background())
    watcher, werr := fsnotify.NewWatcher()
    if werr != nil {
        cancelCtx()
        return nil, werr
    }
    if aerr := watcher.Add(filePath); aerr != nil {
        _ = watcher.Close()
        cancelCtx()
        return nil, aerr
    }
    var (
        timer    *time.Timer
        timerMu  sync.Mutex
        fireWG   sync.WaitGroup // tracks in-flight reloads so cancel() waits for them
        stopFlag = make(chan struct{})
    )
    // scheduleReload is the single entry point for ALL file events.
    // Remove, Rename, Chmod (inode changes), Write, Create, and even
    // watcher errors all go through here. This eliminates the race
    // condition that existed when Remove and Write had separate paths.
    scheduleReload := func(reason string) {
        timerMu.Lock()
        defer timerMu.Unlock()
        // If stopFlag is closed, cancel() has been called.
        // Don't schedule anything new.
        select {
        case <-stopFlag:
            return
        default:
        }
        // Reset the debounce timer. Every new event pushes the reload
        // 300ms into the future. This prevents 4 rapid reloads when an
        // editor saves a file.
        if timer != nil {
            timer.Stop()
        }
        timer = time.AfterFunc(debounceWindow, func() {
            // Register BEFORE doing any work so cancel() can track us.
            fireWG.Add(1)
            defer fireWG.Done()
            // Re-check: if cancel() was called during the 300ms wait,
            // bail out immediately.
            select {
            case <-stopFlag:
                return
            default:
            }
            // Reattach: remove the old inode, then retry Add.
            // vim writes a temp file then renames. sed -i creates a
            // new file. K8s ConfigMaps swap symlink targets. All of
            // these are handled by Remove + Add.
            _ = watcher.Remove(filePath)
            for attempt := 0; attempt < 10; attempt++ {
                if err := watcher.Add(filePath); err == nil {
                    break
                }
                select {
                case <-stopFlag:
                    return
                case <-time.After(50 * time.Millisecond):
                }
            }
            newCfg, loadErr := LoadConfig(filePath)
            if loadErr != nil {
                log.Printf("[Pastaay-Config] reload skipped (%s): %v", reason, loadErr)
                return
            }
            // Validate rejects broken YAML. Engine keeps the last valid config.
            if vErr := newCfg.Validate(); vErr != nil {
                log.Printf("[Pastaay-Config] reload rejected (%s): %v", reason, vErr)
                return
            }
            // Final gate: if cancel() was called during LoadConfig or
            // Validate, do NOT invoke the callback. The caller has
            // already torn down and a stale config push would be a bug.
            select {
            case <-stopFlag:
                return
            default:
            }
            reloadCallback(newCfg)
        })
    }
    var loopWG sync.WaitGroup
    loopWG.Add(1)
    go func() {
        defer loopWG.Done()
        defer watcher.Close()
        for {
            select {
            case <-ctx.Done():
                return
            case event, ok := <-watcher.Events:
                if !ok { return }
                // All event types go to the same debounced path.
                // No more separate CAS reattach goroutine.
                if event.Has(fsnotify.Write) || event.Has(fsnotify.Create) ||
                    event.Has(fsnotify.Remove) || event.Has(fsnotify.Rename) ||
                    event.Has(fsnotify.Chmod) {
                    scheduleReload(event.Op.String())
                }
            case errEv, ok := <-watcher.Errors:
                if !ok { return }
                log.Printf("[Pastaay-Config] watcher error (forcing reattach): %v", errEv)
                scheduleReload("watcher-error")
            }
        }
    }()
    cancel = func() {
        close(stopFlag)       // signal all goroutines to stop
        cancelCtx()           // cancel the root context
        timerMu.Lock()
        if timer != nil {
            timer.Stop()      // stop any pending debounce timer
        }
        timerMu.Unlock()
        loopWG.Wait()         // wait for the event loop goroutine
        fireWG.Wait()         // wait for any in-flight reload callback
    }
    return cancel, nil
}

All file events; Write, Create, Remove, Rename, Chmod, and watcher
errors, go through a single scheduleReload path. A 300ms debounce
prevents burst reloads. Inside the callback, watcher.Remove + Add
handles inode changes from vim, sed -i, and Kubernetes ConfigMap
symlink swaps. If LoadConfig fails or Validate rejects, the engine
keeps running with the last valid config.

The critical detail: fireWG.Add(1) happens inside the AfterFunc body
but BEFORE the I/O work. cancel() closes stopFlag, stops the timer,
then calls loopWG.Wait() then fireWG.Wait(). Any callback past the
stopFlag gate completes before Wait returns. Any callback still in
the debounce window sees stopFlag closed and bails. Zero use-after-cancel.

Invalid configurations are rejected. If you write broken YAML, the engine keeps running with the last valid configuration. The error is logged. No crash, no rollback, no surprise.

6. The Interceptor Pattern

6.1 HTTP: The Reference Implementation

Every protocol interceptor in pastaay follows the same skeleton. Here’s the HTTP middleware in full:

func Middleware(mgr *config.Manager) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            // Step 1: Check if this path is protected (whitelist)
            if mgr.IsCommandIgnored("http", r.URL.Path) {
                next.ServeHTTP(w, r)
                return
            }
            // Step 2: Get active policies for this protocol (zero alloc atomic load)
            policies := mgr.GetActivePolicies("http")
            // Step 3: Iterate policies, match path and headers
            for i := range policies {
                p := &policies[i]
                if !matchPath(r.URL.Path, p) || !matchHeaders(r, p.MatchHeaders) {
                    continue
                }
                // Step 4a: Latency injection with context cancellation support
                if p.LatencyChance > 0 && rand.Float64() < p.LatencyChance {
                    metrics.InjectedFaultsTotal.WithLabelValues(metricTag, "latency").Inc()
                    ctx, span := tracing.StartChaosSpan(r.Context(),
                        "pastaay.http.latency", p.Target, "latency")
                    timer := time.NewTimer(p.LatencyDuration)
                    select {
                    case <-timer.C:
                        span.End()
                    case <-ctx.Done():
                        timer.Stop()
                        span.End()
                        w.WriteHeader(499) // 499: Nginx standard for Client Closed Request
                        return
                    }
                }
                // Step 4b: Error injection
                if p.ErrorChance > 0 && rand.Float64() < p.ErrorChance {
                    metrics.InjectedFaultsTotal.WithLabelValues(metricTag, "error").Inc()
                    _, span := tracing.StartChaosSpan(r.Context(),
                        "pastaay.http.error", p.Target, "error")
                    defer span.End()
                    status := p.ErrorCode
                    if status == 0 { status = http.StatusInternalServerError }
                    w.Header().Set("Content-Type", "application/json")
                    w.WriteHeader(status)
                    if p.ErrorBody != "" {
                        io.WriteString(w, p.ErrorBody)
                    }
                    return // Stop chain, don't call next handler
                }
            }
            // Step 5: No matching policy with active probability, pass through
            next.ServeHTTP(w, r)
        })
    }
}

6.2 The Wildcard Matching Problem

Path matching isn’t as simple as strings.HasPrefix. Consider:

Policy target: /api/users/*
Request path:  /api/users/123     ✓ Match
Request path:  /api/usersettings  ✗ Should NOT match

The solution requires checking that the character immediately after the prefix is either / or end of string:

func matchPath(reqPath string, p *config.Policy) bool {
    // Exact match or wildcard "all" catches everything.
    if strings.EqualFold(p.Target, "all") || strings.EqualFold(reqPath, p.Target) {
        return true
    }
    if p.IsWildcard {
        reqPathUpper := strings.ToUpper(reqPath)
        if strings.HasPrefix(reqPathUpper, p.WildcardPrefix) {
            remaining := reqPathUpper[len(p.WildcardPrefix):]
            // The character AFTER the prefix must be '/' or end-of-string.
            // This prevents /api/users* from matching /api/usersettings.
            if strings.HasSuffix(p.WildcardPrefix, "/") ||
               len(remaining) == 0 ||
               remaining[0] == '/' {
                return true
            }
        }
    }
    return false
}

The third condition (remaining[0] == '/') is the key: after stripping the wildcard prefix, the next character must be a path separator. This prevents /api/users* from matching /api/usersettings.

6.3 gRPC: Streaming vs Unary

gRPC interception is more complex than HTTP because of bidirectional streaming. A unary RPC that fails returns an error code to the client immediately. A streaming RPC that fails mid-stream leaves the client hanging unless the server actively closes the stream.

The gRPC interceptor handles this by distinguishing between unary and streaming contexts. For streaming, the interceptor wraps the server stream to inject faults on individual messages rather than the entire stream. This allows you to drop message #3 in a stream of 100 messages without affecting the rest, a far more realistic failure mode than killing the entire connection.

7. The SQL Driver Wrapper

7.1 Intercepting database/sql at the Driver Level

SQL interception is fundamentally different from HTTP interception. With HTTP, you wrap a handler. With SQL, you wrap the database driver itself, at the database/sql/driver interface level.

type WrapperDriver struct {
    original   driver.Driver      // the real driver (pgx, sqlite3, mysql, etc.)
    cfgManager *config.Manager
}
type WrapperConnector struct {
    original   driver.Connector   // Go 1.10+ connector interface
    cfgManager *config.Manager
}
func (d *WrapperDriver) Open(name string) (driver.Conn, error) {
    // Apply chaos BEFORE opening: can drop connections entirely
    // or add latency before the handshake.
    if err := applyConnectionChaos(context.Background(), d.cfgManager); err != nil {
        return nil, err
    }
    conn, err := d.original.Open(name)
    if err != nil {
        return nil, err
    }
    // Wrap the real connection so every Query/Exec/Begin gets intercepted.
    return &WrapperConn{originalConn: conn, cfgManager: d.cfgManager}, nil
}

Every connection that passes through the wrapper gets a WrapperConn that intercepts Prepare, Exec, Query, Begin, and Commit. Each of these methods checks the policy engine before passing through to the real connection.

The OpenConnector method handles Go 1.10+ driver connector interface, which is what modern database drivers use internally:

func (d *WrapperDriver) OpenConnector(name string) (driver.Connector, error) {
    // Go 1.10+ database/sql uses connectors internally.
    // We must wrap the connector too, or the driver bypasses our interceptor.
    if dc, ok := d.original.(driver.DriverContext); ok {
        connector, err := dc.OpenConnector(name)
        if err != nil {
            return nil, err
        }
        return &WrapperConnector{original: connector, cfgManager: d.cfgManager}, nil
    }
    // Fallback for older drivers that don't implement DriverContext.
    return &fallbackConnector{driver: d, name: name}, nil
}

7.2 The “Don’t Break Transactions” Rule

SQL chaos has a critical safety constraint: never inject faults inside an active transaction’s lifecycle. Breaking a COMMIT is the worst thing you can do to a database, it leaves locks held, connections stuck, and the application in an undefined state.

SQL chaos checks are applied at connection open and statement execution
points. BEGIN also receives a chaos check, but Commit and Rollback are
passed through without interception. You can still introduce latency (the transaction takes longer), but you can't drop the connection or inject query errors during the transaction body.

This is the kind of constraint that only comes from production experience. Version 1 of the SQL driver didn’t have this protection, and it corrupted test data. Version 2 added it after a very long debugging session.

8. OS Resource Sabotage

This is the feature that makes people do a double take. Most chaos tools stop at the network layer. Pastaay eats your CPU and RAM.

8.1 CPU Starvation: Beating the Compiler Optimizer

func BurnCPU(ctx context.Context, cores int, threshold int) {
    if cores <= 0 {
        cores = runtime.NumCPU() // saturate all cores by default
    }
    if threshold <= 0 {
        threshold = 100000 // empirically ~95% CPU on a single core
    }
    var wg sync.WaitGroup
    for i := 0; i < cores; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            payload := []byte("pastaay-cpu-vector")
            var localSink [32]byte // compiler can't optimize this away
            for {
                for j := 0; j < threshold; j++ {
                    // SHA-256 is in assembly (crypto/sha256).
                    // The compiler cannot elide it as dead code.
                    localSink = sha256.Sum256(payload)
                }
                // runtime.KeepAlive tells the compiler "localSink is still
                // live", prevents the entire loop from being optimized out.
                runtime.KeepAlive(localSink)
                select {
                case <-ctx.Done(): // clean exit when TTL expires or HALT is pressed
                    return
                default:
                    continue
                }
            }
        }()
    }
    wg.Wait()
}

The Go compiler is smart. If it detects that your computation has no observable side effects, it eliminates the entire loop. The empty for {} burns CPU in debug builds but vanishes in optimized builds. So we use SHA-256 hashing, a cryptographic operation the compiler cannot elide because it's implemented in assembly via the crypto/sha256 package.

Two subtleties here:

**runtime.KeepAlive(localSink)**, Without this, the compiler might notice that localSink is never read after the loop and eliminate the assignment. KeepAlive is a compiler directive that says "this variable is still live." It's a no op at runtime but prevents dead code elimination.

**select** with **ctx.Done()**, This is the clean escape hatch. The default branch keeps the loop spinning. When the context is cancelled (experiment TTL expires, halt button pressed, policy removed), the goroutine exits immediately. No leaks, no orphans.

The threshold parameter controls intensity through iteration count. Empirically:

10,000 iterations = ~30% CPU on a single core
100,000 iterations = ~95% CPU
500,000 iterations = effectively 100%

8.2 Memory Exhaustion: Page Forcing and Global Ceilings

func LeakRAM(ctx context.Context, chunkMB int, interval time.Duration) {
    if interval <= 0 { interval = 1 * time.Second }
    if chunkMB <= 0 { return }
    ticker := time.NewTicker(interval)
    defer ticker.Stop()
    chunkSize := chunkMB * 1024 * 1024
    var pool [][]byte
    defer func() {
        atomic.AddInt64(&currentPoolMB, -int64(len(pool)*chunkMB))
        pool = nil
        runtime.GC()
    }()
    allocate := func() bool {
        if atomic.LoadInt64(&currentPoolMB)+int64(chunkMB) > maxRAMPoolMB {
            log.Printf("[Pastaay-Resource] RAM ceiling %dMB reached, refusing new chunk (%dMB)",
                maxRAMPoolMB, chunkMB)
            return false
        }
        chunk := make([]byte, chunkSize)
        // Page forcing: touch every 4096th byte
        for i := 0; i < chunkSize; i += 4096 {
            chunk[i] = 1
        }
        pool = append(pool, chunk)
        atomic.AddInt64(&currentPoolMB, int64(chunkMB))
        return true
    }
    allocate()
    for {
        select {
        case <-ctx.Done():
            return
        case <-ticker.C:
            allocate()
        }
    }
}

This function embodies three engineering principles I consider non negotiable for any chaos tool:

1. Page forcing. make([]byte, chunkSize) allocates virtual memory but doesn't commit physical pages. The OS uses demand paging, physical RAM is only assigned when a page is actually touched. By writing to every 4096th byte (the standard page size on both x86 and ARM64), we force the kernel to commit real, physical memory. Without this, your /proc/meminfo looks scary but the kernel hasn't actually allocated anything meaningful.

2. Global ceiling. maxRAMPoolMB is hard coded at 4096MB. I hardcoded this to 4GB because it’s a safe upper bound that prevents catastrophic node eviction (OOMKill) on standard 8GB/16GB cloud worker nodes, while still being devastating enough for any application-level test. No matter what the YAML says, the engine will never allocate more than 4GB across all RAM leaking policies combined. The check is an atomic load compare at the allocation site, if you're already at 3.9GB and request another 256MB chunk, the allocation is refused and logged. The guard module catches unrealistic values at validation time, but the runtime ceiling is the absolute last line of defense.

3. Guaranteed cleanup, the Amnesia Protocol. The defer block zeros the pool slice, subtracts the atomic counter, and triggers runtime.GC(). When the context is cancelled (because the experiment's TTL expired, you clicked the HALT button, or the policy was removed from the YAML), all memory returns to the OS. No restart required. No dangling allocations. The name "Amnesia Protocol" comes from the idea that the engine should forget it ever held that memory, complete, verifiable amnesia.

The resource sabotage daemon MonitorAndTrigger polls policies every 2 seconds, comparing policy hashes to detect changes. This is a state machine with exactly two states: running (with a cancel function) and idle:

func MonitorAndTrigger(ctx context.Context, mgr *config.Manager) {
    ticker := time.NewTicker(2 * time.Second)
    defer ticker.Stop()
    var lastResourceHash uint64      // tracks policy identity across reloads
    var activeCancel context.CancelFunc
    for {
        select {
        case <-ctx.Done():
            if activeCancel != nil {
                activeCancel()       // kill any running sabotage goroutines
            }
            return
        case <-ticker.C:
            policies := mgr.GetActivePolicies("resource")
            // Kill-switch: if all resource policies are removed from YAML,
            // immediately stop sabotage and release all memory.
            if len(policies) == 0 {
                if activeCancel != nil {
                    activeCancel()
                    activeCancel = nil
                    lastResourceHash = 0
                }
                continue
            }
            // Compute combined hash of all active resource policies.
            // Only restart sabotage if policies actually changed.
            var combinedHash uint64
            for _, p := range policies {
                combinedHash = (combinedHash<<1 | combinedHash>>63) ^ p.PolicyHash
            }
            if combinedHash != lastResourceHash {
                if activeCancel != nil {
                    activeCancel()   // kill old sabotage before starting new
                }
                lastResourceHash = combinedHash
                var chaosCtx context.Context
                chaosCtx, activeCancel = context.WithCancel(ctx)
                for _, p := range policies {
                    TriggerResourceSabotage(chaosCtx, buildResourcePolicy(p))
                }
            }
        }
    }
}

9. The Blast Radius Guard

The guard is not a gatekeeper, it doesn’t stop you from deploying dangerous policies. It’s an analysis tool that tells you exactly how dangerous your policies are before you deploy them.

func Analyze(cfg *config.PastaayConfig) PlanResult {
    res := PlanResult{Issues: make([]string, 0)}
    if cfg == nil || len(cfg.Policies) == 0 {
        return PlanResult{Status: "SAFE", Score: 0, TotalRisk: 0.0, Issues: []string{}}
    }
    systemSurvival := 1.0 // multiplicative survival probability
    // Core guard: disabled default-ignored = 15% flat risk penalty
    if !cfg.EnableDefaultIgnored {
        res.Issues = append(res.Issues,
            "CORE GUARD DISABLED: System base vulnerability increased.")
        systemSurvival *= 0.85
    }
    targets := make(map[string]string) // detect overlapping policies
    for _, p := range cfg.Policies {
        // Skip no-op policies (all probabilities zero, no resource effects)
        if p.LatencyChance == 0 && p.ErrorChance == 0 &&
           !p.DropConnection && p.RAMChunkMB == 0 && p.ThrottleThreshold == 0 {
            continue
        }
        // Factor 1: Scope — how much of the system does this hit?
        // 0.4 = targeted endpoint, 1.0 = entire protocol layer
        scopeWeight := 0.4
        if p.Target == "all" || p.Target == "database" || p.Target == "*" || p.Target == "" {
            scopeWeight = 1.0
            res.Issues = append(res.Issues,
                fmt.Sprintf("[%s] Global Target: Exposes entire '%s' infrastructure layer.",
                    p.Name, p.Type))
        }
        // Factor 2: Collision — two policies hitting the same target
        // compound. Each overlap adds +0.2 to scope weight.
        key := p.Type + ":" + p.Target
        if orig, exists := targets[key]; exists {
            res.Issues = append(res.Issues,
                fmt.Sprintf("[%s] Collision: Overlaps with '%s'. Cascading failure probability increased.",
                    p.Name, orig))
            scopeWeight = min(1.0, scopeWeight+0.2)
        }
        targets[key] = p.Name
        // Factor 3: Fault severity — the worst single effect this policy can cause
        maxSeverity := 0.0
        if p.DropConnection {
            maxSeverity = 1.0 // hard TCP drop = maximum severity
            res.Issues = append(res.Issues,
                fmt.Sprintf("[%s] Hard TCP Drop: Triggers immediate network circuit-breakers.", p.Name))
        }
        if p.ErrorChance > 0 {
            maxSeverity = max(maxSeverity, p.ErrorChance)
        }
        if p.LatencyChance > 0 {
            latMultiplier := 0.3
            if p.LatencyDuration >= 5*time.Second {
                latMultiplier = 1.0 // thread pool exhaustion territory
                res.Issues = append(res.Issues,
                    fmt.Sprintf("[%s] 5s+ Timeout: Causes severe thread pool exhaustion.", p.Name))
            } else if p.LatencyDuration >= 1*time.Second {
                latMultiplier = 0.6
            }
            maxSeverity = max(maxSeverity, p.LatencyChance*latMultiplier)
        }
        if p.Type == "resource" {
            resSeverity := 0.0
            if p.RAMChunkMB >= 1024 {
                resSeverity = 0.9 // OOM territory
            } else if p.RAMChunkMB >= 256 {
                resSeverity = 0.5
            } else if p.RAMChunkMB > 0 {
                resSeverity = 0.2
            }
            if p.ThrottleThreshold >= 100000 {
                resSeverity = max(resSeverity, 0.8) // near-100% CPU lock
            }
            maxSeverity = max(maxSeverity, resSeverity)
        }
        // Policy risk = severity × scope. Multiplicative survival model.
        policyRisk := maxSeverity * scopeWeight
        systemSurvival *= (1.0 - policyRisk)
    }
    finalRisk := 1.0 - systemSurvival
    res.TotalRisk = finalRisk
    res.Score = int(finalRisk * 100.0)
    switch {
    case res.Score >= 75: res.Status = "CRITICAL"
    case res.Score >= 50: res.Status = "HIGH"
    case res.Score >= 25: res.Status = "ELEVATED"
    default:              res.Status = "SAFE"
    }
    return res
}

The scoring model is multiplicative survival analysis: each policy reduces the “survival probability” of the system by maxSeverity × scopeWeight. Policies with global scope and high severity compound dramatically. Two CRITICAL policies don't add, they multiply.

10. The Telemetry Bus

The telemetry system uses a lock-free circular buffer that can handle concurrent writes from multiple goroutines (one per protocol) and concurrent reads from the web console polling endpoint:

type LogEntry struct {
    Pod     string `json:"pod"`
    Source  string `json:"source"`
    Name    string `json:"name"`
    Message string `json:"msg"`
    Ts      int64  `json:"ts"`
}
var (
    mu       sync.RWMutex
    buf      [256]LogEntry
    head     int
    size     int
    nodeName string
)
func Emit(source, name, msg string) {
    mu.Lock()
    defer mu.Unlock()
    buf[head] = LogEntry{
        Source: source, Name: name, Pod: source + "/" + name,
        Message: msg, Ts: time.Now().UnixMilli(),
    }
    head = (head + 1) % 256
    if size < 256 { size++ }
}
func Snapshot() []LogEntry {
    mu.RLock()
    defer mu.RUnlock()
    out := make([]LogEntry, size)
    start := (head - size + 256) % 256
    for i := 0; i < size; i++ {
        out[i] = buf[(start+i)%256]
    }
    return out
}

The ring buffer holds 256 entries. When it fills, older entries are silently overwritten. This is intentional, the telemetry bus is not a persistence layer. If you need long term storage, pipe the logs to your existing observability stack via OpenTelemetry or scrape the Prometheus metrics.

The EmitError and EmitInfo helpers automatically attach OpenTelemetry trace and span IDs when available, creating a direct link between chaos events in the log and spans in your tracing backend:

func EmitError(protocol, target, msg, payload string, span trace.Span) {
    logData := map[string]interface{}{
        "level": "ERROR", "protocol": protocol, "target": target,
        "message": msg, "payload": payload,
    }
    if span != nil && span.SpanContext().IsValid() {
        logData["trace_id"] = span.SpanContext().TraceID().String()
        logData["span_id"] = span.SpanContext().SpanID().String()
    }
    jsonLog, _ := json.Marshal(logData)
    Emit(nodeName, protocol, string(jsonLog))
}

This trace correlation was one of the best decisions I made. When you see “Kafka message dropped” in the web console journal, you can copy the trace ID, paste it into Jaeger, and see the entire request journey, which services it touched, where the fault was injected, and what the downstream effects were.

11. The Oracle

11.1 Teaching an LLM to Write Valid Chaos Engineering YAML

The Oracle is the feature that gets the most attention, so let me explain exactly how it works.

The problem: designing good chaos engineering policies requires SRE expertise. Most developers don’t know what failure modes to test, what probability thresholds make sense, or how to combine faults into realistic scenarios. An experienced SRE might spend hours designing a multi vector attack. Most teams never do it at all.

The solution: give an LLM structured context about your running system and let it figure out the attack plan.

But LLMs hallucinate. They invent YAML fields. They use range durations like 5s-15s which are syntactically valid YAML but semantically meaningless. They output error_chance: 0 instead of omitting the field. They generate single policy tests when you need multi vector attacks.

The system prompt for the Oracle is 40 lines of engineering specification that exist to constrain the LLM into producing only valid, deployable output.

The actual system prompt, constructed in Go and sent to the LLM, looks like this:

You are Pastaay Oracle, a Senior Site Reliability Engineering (SRE) AI.
Analyze the provided telemetry and system configuration matrices.
Your ONLY output must be a highly complex, devastating, multi layered
Chaos Engineering blueprint in valid Pastaay V1 YAML wrapped in a markdown
yaml block.
CRITICAL DIRECTIVES:
1. Output ONLY valid Pastaay V1 YAML wrapped in a markdown yaml block
   (using triple backticks and yaml specifier). NO conversational text.
2. DO NOT write single policy basic tests. Generate a Multi Vector Attack
   containing at least 3 concurrent policies.
3. INTENSITY LEVEL HIGH: Use severe probabilities (0.7-0.9), extreme latency
   (3s-8s), and enable drop_connection where appropriate.
4. STRICT SCHEMA RULES:
   - NEVER use ranges for durations (e.g., '5s-15s' is ILLEGAL.
     Use exactly '5s' or '15s').
   - NEVER invent types like 'multi'. Stick EXACTLY to the provided schema.
   - FATAL GUARD: For 'resource' policies, NEVER exceed ram_chunk_mb: 512.
   - CLEAN YAML RULE: NEVER output error_chance: 0 or latency_chance: 0.
     If a probability is 0, completely OMIT the field from the YAML.
   - RESOURCE TYPE RULE: For 'resource' policies, completely OMIT
     error_chance, error_code, latency_chance, and drop_connection.
     They are invalid for OS level sabotage.

Notice the style: imperative, negative constraints, all caps enforcement words (NEVER, ILLEGAL, FATAL GUARD, STRICT, ONLY). I went through four iterations of this prompt. Version 1 was conversational and polite. It produced garbage YAML. Version 2 added schema rules but was too permissive. Version 3 added negative constraints but still allowed ranges. Version 4 (this one) works reliably across all four LLM providers.

I learned something important about prompt engineering: LLMs are not creative collaborators. They are literal instruction followers. If you leave room for interpretation, they will interpret, usually incorrectly. If you say “don’t use ranges,” they might still use them. If you say “NEVER use ranges, this is ILLEGAL,” they comply. The difference in output quality between “avoid X” and “NEVER do X. X is ILLEGAL” is dramatic.

11.2 Live Telemetry Context Injection

The Oracle doesn’t operate in a vacuum. Before calling the LLM, the engine constructs a telemetry matrix from live Prometheus data:

finalPrompt := fmt.Sprintf(
    "User Request: %s\n\n--- LIVE TELEMETRY MATRIX ---\n%s",
    userPrompt, sysContext,
)

The sysContext contains:

Active policy count and types
Prometheus counter values for pastaay_injected_faults_total by target and fault type
Currently targeted services
Sensor health status

This means if you type “stress the payment service,” the Oracle sees that payments is already receiving latency faults but not errors, and generates an attack plan that introduces error injection to the payment endpoints while adding latency to the notification service for a multi vector scenario. It’s not guessing, it’s making data informed decisions.

11.3 Multi Model Architecture

The Oracle supports four providers through a unified interface. OpenAI and DeepSeek share a code path because both use OpenAI compatible APIs:

func callLLM(ctx context.Context, apiKey, model, url, sysPrompt, userPrompt, provider string) (string, error) {
    // OpenAI and DeepSeek share the same API shape: Chat Completions.
    payload := map[string]interface{}{
        "model": model,
        "messages": []map[string]string{
            {"role": "system", "content": sysPrompt},
            {"role": "user", "content": userPrompt},
        },
        "temperature": 0.5,
    }
    req, err := buildJSONRequest(ctx, http.MethodPost, url, payload)
    if err != nil {
        return "", err
    }
    req.Header.Set("Authorization", "Bearer "+apiKey) // standard OpenAI-style auth
    return executeRequest(req, provider, func(b []byte) (string, error) {
        var res struct {
            Choices []struct {
                Message struct {
                    Content string `json:"content"`
                } `json:"message"`
            } `json:"choices"`
        }
        if err := json.Unmarshal(b, &res); err != nil {
            return "", fmt.Errorf("%s decode: %w", provider, err)
        }
        if len(res.Choices) == 0 {
            return "", fmt.Errorf("%s: no choices", provider)
        }
        return res.Choices[0].Message.Content, nil
    })
}

Gemini uses a fundamentally different API:

func callGemini(ctx context.Context, apiKey, model, sysPrompt, userPrompt string) (string, error) {
    // Gemini uses a different API shape than OpenAI/Anthropic.
    // The key goes into a header, NOT the URL query string.
    // Query params leak into proxy logs and OTel spans.
    url := "https://generativelanguage.googleapis.com/v1beta/models/" +
        model + ":generateContent"
    // Gemini's system instruction is a top-level field, not a message role.
    payload := map[string]interface{}{
        "system_instruction": map[string]interface{}{
            "parts": map[string]string{"text": sysPrompt},
        },
        "contents": []map[string]interface{}{
            {"parts": []map[string]string{{"text": userPrompt}}},
        },
        "generationConfig": map[string]interface{}{"temperature": 0.5},
    }
    req, err := buildJSONRequest(ctx, http.MethodPost, url, payload)
    if err != nil {
        return "", err
    }
    req.Header.Set("x-goog-api-key", apiKey) // NOT ?key= in URL
    return executeRequest(req, "gemini", func(b []byte) (string, error) {
        var res struct {
            Candidates []struct {
                Content struct {
                    Parts []struct{ Text string `json:"text"` } `json:"parts"`
                } `json:"content"`
            } `json:"candidates"`
        }
        if err := json.Unmarshal(b, &res); err != nil {
            return "", fmt.Errorf("gemini decode: %w", err)
        }
        // Gemini wraps responses deeper than OpenAI.
        // Guard against empty responses from rate limits or safety filters.
        if len(res.Candidates) == 0 || len(res.Candidates[0].Content.Parts) == 0 {
            return "", fmt.Errorf("gemini: no candidates")
        }
        return res.Candidates[0].Content.Parts[0].Text, nil
    })
}

Anthropic uses yet another format:

func callAnthropic(ctx context.Context, apiKey, model, sysPrompt, userPrompt string) (string, error) {
    // Anthropic uses its own Messages API, different from both
    // OpenAI and Gemini. System prompt is a top-level field.
    payload := map[string]interface{}{
        "model":      model,
        "max_tokens": 4096,
        "system":     sysPrompt,
        "messages":   []map[string]string{{"role": "user", "content": userPrompt}},
    }
    req, err := buildJSONRequest(ctx, http.MethodPost,
        "https://api.anthropic.com/v1/messages", payload)
    if err != nil {
        return "", err
    }
    req.Header.Set("x-api-key", apiKey)
    req.Header.Set("anthropic-version", "2023-06-01")
    return executeRequest(req, "anthropic", func(b []byte) (string, error) {
        var res struct {
            Content []struct{ Text string `json:"text"` } `json:"content"`
        }
        if err := json.Unmarshal(b, &res); err != nil {
            return "", fmt.Errorf("anthropic decode: %w", err)
        }
        if len(res.Content) == 0 {
            return "", fmt.Errorf("anthropic: no content")
        }
        return res.Content[0].Text, nil
    })
}

Each model has a carefully chosen default: DeepSeek R1 (deepseek-reasoner) for the Oracle's reasoning heavy workload, GPT-4o-mini for cost efficiency, Gemini 2.5 Flash for speed, and Claude Sonnet for Anthropic's ecosystem.

12. The Web Console

12.1 Vanilla Everything

There is no React. No Node.js. No npm. No webpack. No build step. The entire frontend is embedded in the Go binary:

//go:embed templates/*
var TemplatesFS embed.FS
//go:embed static/*
var StaticFS embed.FS

When pastaay starts, it registers routes that serve these embedded files directly from memory:

func RegisterHandlers(mux *http.ServeMux, mgr *config.Manager) {
    tmpl := template.Must(template.ParseFS(TemplatesFS, "templates/*.html"))
    mux.Handle("/static/", http.FileServer(http.FS(StaticFS)))
    mux.Handle("/console/docs/raw/",
        http.StripPrefix("/console/docs/raw/", http.FileServer(http.FS(docs.FS))))
    mux.HandleFunc("/console", func(w http.ResponseWriter, r *http.Request) {
        renderHTML(tmpl, w, "dashboard")
    })
    mux.HandleFunc("/console/docs", func(w http.ResponseWriter, r *http.Request) {
        renderHTML(tmpl, w, "docs")
    })
    mux.HandleFunc("/console/builder", func(w http.ResponseWriter, r *http.Request) {
        renderHTML(tmpl, w, "builder")
    })
    mux.HandleFunc("/console/api/state", requireConsoleToken(adminToken, handleState(mgr)))
    mux.HandleFunc("/console/api/oracle", requireConsoleToken(adminToken, handleOracle))
    mux.HandleFunc("/console/api/plan", requireConsoleToken(adminToken, handlePlan))
    mux.HandleFunc("/console/api/rollback", requireConsoleToken(adminToken, handleRollback(mgr)))
    mux.HandleFunc("/console/api/probe", requireConsoleToken(adminToken, handleProbe))
    mux.HandleFunc("/console/api/metrics", handleMetrics)
    mux.HandleFunc("/console/api/discover", requireConsoleToken(adminToken, handleDiscover))
}

The authentication middleware uses constant time comparison to prevent timing attacks on the API token. If PASTAAY_WEBHOOK_TOKEN is set as an environment variable, every API call requires it in the X-Pastaay-Token header. If it's empty, the console is open access, which is fine for local development but should be configured in production.

12.2 The Widget System

The dashboard grid is a proper drag and drop implementation. Each panel is a self contained widget that manages its own data fetching, rendering, and lifecycle. The layout persists in localStorage:

// From widget.js, layout persistence
saveLayout() {
    const order = [];
    this.grid.querySelectorAll('[data-widget-id]').forEach(el => {
        order.push(el.dataset.widgetId);
    });
    localStorage.setItem('pastaay_layout', JSON.stringify(order));
}
loadLayout() {
    const saved = localStorage.getItem('pastaay_layout');
    if (!saved) return;
    const order = JSON.parse(saved);
    order.forEach(id => {
        const el = this.grid.querySelector(`[data-widget-id="${id}"]`);
        if (el) this.grid.appendChild(el);
    });
}

Widgets communicate with the engine through a REST API served by the same Go process. The state endpoint returns the current policy state, telemetry snapshot, and sensor health in a single JSON response. Widgets poll this endpoint at configurable intervals and update themselves. There’s no WebSocket, no Server Sent Events, no complex state management, just HTTP polling that works through any firewall.

A closer look at two of the panels. The Global Fault Velocity chart tracks the total fault injection rate across all targets in real time:

The Blast Radius Matrix breaks down errors, latency spikes, and dropped connections across the most targeted services:

12.3 The Resilience Probe

The resilience probe uses Apdex scoring. Apdex (Application Performance Index) classifies response times into three buckets relative to a configurable threshold T:

Satisfied: response ≤ T
Tolerating: T < response ≤ 4T
Frustrated: response > 4T or error

The Apdex score = (Satisfied + Tolerating/2) / Total. A score of 0.94+ means the target is healthy. Below 0.70 means it’s degrading. Below 0.50 means it’s failing.

The probe sends HTTP requests through a server side proxy to bypass browser CORS restrictions:

func handleProbe(w http.ResponseWriter, r *http.Request) {
    var req struct{ URL string `json:"url"` }
    json.NewDecoder(r.Body).Decode(&req)
    start := time.Now()
    // Server-side proxy, bypasses browser CORS restrictions.
    // The probe targets services the browser can't reach directly.
    client := &http.Client{Timeout: 10 * time.Second}
    resp, err := client.Get(req.URL)
    elapsed := time.Since(start).Milliseconds()
    result := map[string]interface{}{"elapsed_ms": elapsed}
    if err != nil {
        result["status"] = 0
        result["error"] = err.Error()
    } else {
        defer resp.Body.Close()
        result["status"] = resp.StatusCode
    }
    json.NewEncoder(w).Encode(result)
}

The probe supports multi target round robin probing, EMA smoothed scoring, and clickable diagnostic popovers that explain each field in plain English.

12.4 Kubernetes Log Streaming

The web console can stream pod logs in real time. The backend uses the Kubernetes Watch API to detect new pods and attach log streams:

// Watch for new pods and stream their logs in real time.
w, err := clientset.CoreV1().Pods(namespace).Watch(ctx, metav1.ListOptions{})
for event := range w.ResultChan() {
    pod, ok := event.Object.(*corev1.Pod)
    if !ok { continue }
    switch event.Type {
    case watch.Added, watch.Modified:
        // Only attach to Running pods, pending/terminating pods ignored.
        if pod.Status.Phase == corev1.PodRunning {
            streamCtx, cancel := context.WithCancel(ctx)
            activeStreams[pod.Name] = cancel // store cancel for cleanup
            go startKubeLogStreamer(streamCtx, clientset, namespace, pod.Name)
        }
    case watch.Deleted:
        // Pod removed — cancel its log stream to free resources.
        if cancel, exists := activeStreams[pod.Name]; exists {
            cancel()
            delete(activeStreams, pod.Name)
        }
    }
}

Log streams use the Kubernetes Pod Log API with Follow: true. Each line is emitted to the telemetry bus, which feeds the System Output Journal panel in the web console. The journal supports hierarchical filtering (Pod → Protocol → Method), text search, live/pause toggle, and clic -to decrypt payload tracing.

The watch loop reconnects on failure with exponential backoff, capping at 30 seconds. If the watch channel closes (which happens periodically), the loop restarts the watch and reattaches to any running pods.

Here is the full console in action:

13. The Kubernetes Operator

The pastaay Kubernetes operator manages chaos policies as Custom Resources. When you apply a ChaosPolicy CRD to your cluster, the operator detects it, translates it into the engine's configuration format, and pushes it to the target pods through the webhook API:

apiVersion: chaos.pastaay.io/v1
kind: ChaosPolicy
metadata:
  name: payment-service-stress
spec:
  policies:
    - name: http-latency-spike
      type: http
      target: /api/payments/*
      latency_chance: 0.8
      latency_duration: 3s
    - name: db-connection-drop
      type: sql
      target: database
      drop_connection: true
      error_chance: 0.3

The operator controller watches for CRD changes and reconciles the desired state against the engine. It also handles the RBAC necessary for the log streaming feature, a separate ClusterRole that grants pod log read access.

[IMAGE: docs/assets/operator_header.png, the operator architecture header]

14. Zero Allocation

14.1 The Performance Guarantee

Every policy lookup in pastaay is zero allocation.

1. Atomic pointers for configuration. The policy cache is behind an atomic.Pointer. Reading it requires no lock. The pointer swap during updates takes microseconds and doesn't block readers.

2. Type indexed slice cache. Instead of iterating all policies on every request, policies are pre grouped by protocol type. An HTTP request only checks HTTP policies. A Kafka message only checks Kafka policies. The map lookup is O(1).

3. Lock free PCG random number generator. Go’s math/rand/v2 uses the PCG (Permuted Congruential Generator) algorithm, which is lock free and allocation free. Comparing rand.Float64() < p.ErrorChance is a single atomic operation.

4. No intermediate allocations. The policy struct is stack allocated. The path matching uses only stack variables. The context based delay uses time.NewTimer which pre allocates its internal structures. No fmt.Sprintf, no strings.Builder, no temporary slices.

5. OpenTelemetry BatchSpanProcessor. Spans are batched and flushed asynchronously. If your tracing backend is slow or offline, chaos spans queue up in memory and flush later. The critical path (injecting the fault) never blocks on span export.

15. What I Learned

This section is the part you won’t find in the README or the documentation. These are the things that cost me days of debugging, rewrites, and staring at stack traces at 2 AM.

Filesystem watchers will betray you

I spent three days debugging why the watcher stopped working after a Kubernetes ConfigMap update. The ConfigMap gets mounted as a symlink to a directory containing the file. When the ConfigMap changes, Kubernetes replaces the symlink target, which means the old file’s inode is deleted and a new one appears. fsnotify sees this as RENAME followed by nothing, because the watcher was attached to the old inode. The fix took an hour to code and three days to discover was necessary.

I learned more about Linux filesystems from this one bug than from any course or book. Actual knowledge: fsnotify watches inodes, not paths. Vim writes to a temp file and renames. sed -i does the same. Kubernetes ConfigMaps create symlink forests. Your watcher needs to handle all of these, or your tool silently stops working.

LLMs need negative constraints, not positive guidance

My first Oracle prompt was friendly. “Please generate a chaos engineering YAML configuration.” The output: a single HTTP policy with error_chance: 0 and a conversational preamble thanking me for the opportunity.

I tried making it more specific. “Generate a multi vector attack with at least 3 policies.” The output: three policies, but one had type multi (not a valid type), one used latency_duration: 5s-15s (range, not a valid duration), and one had ram_chunk_mb: 2048 which the guard would reject.

The working prompt is imperatives and prohibitions. “NEVER use ranges. NEVER invent types. output_chance: 0 is ILLEGAL. OMIT the field entirely.” The difference in output quality between “please avoid” and “NEVER do X” is the difference between a working tool and a demo that crashes.

This is general advice for anyone building LLM powered tools: don’t be polite. Be precise. Negative constraints are more powerful than positive ones. Tell the model what NOT to do, and exactly why it’s wrong.

Zero allocation is a mindset, not a technique

The first version of the policy engine used sync.Map and allocated a new slice on every lookup. It worked. At 100 requests per second, nobody noticed. At 10,000 requests per second, the garbage collector woke up every 50 milliseconds and ate 30% of CPU.

Rewriting to use atomic.Pointer and type indexed slices took two weeks. The first week was figuring out what to change. The second week was discovering all the places that implicitly allocated, a fmt.Sprintf here, a strings.Join there, a temporary map created for header matching.

The lesson: design for zero allocation from the start. Adding it later is refactoring your entire hot path. The success rate of that kind of refactoring is low. Mine worked because pastaay was small enough at that point. For a larger codebase, it would have been impossible.

Trace correlation closes the observability gap

I almost cut the OpenTelemetry integration from scope. It seemed like a “nice to have” that would add weeks of work for marginal benefit. I was wrong. The first time I traced a single HTTP request through latency injection, to a Kafka consumer that dropped the message, to a Redis hook that returned a timeout, all visible in a single Jaeger trace tree, the entire value proposition of distributed tracing clicked.

Chaos engineering without tracing is guesswork. You inject a fault and observe the outcome, but you don’t know the causal chain. Did the payment service fail because of the latency, or because the notification service dropped a message that the payment service was waiting for? Without tracing, you can’t tell. With trace correlation, every chaos event has a span ID that links it to the specific request journey it affected.

16. What’s Next

Pastaay is not finished. Here’s what’s on the roadmap:

CEL Driven Rule Engine. Google’s Common Expression Language compiles expression strings to ASTs and evaluates them with zero allocation overhead. Imagine writing policies like:

policies:
  - name: conditional-latency
    type: http
    target: /api/*
    condition: "request.header('X-Priority') == 'low' && error_chance > 0.5"
    latency_duration: 5s

The condition is compiled once at policy load time and evaluated on every request inline with the existing interceptor. This turns pastaay from a probability based chaos tool into a truly programmable chaos platform.

Trace Aware Injection. Using OpenTelemetry Baggage to propagate chaos decisions across service boundaries. If a request enters your system with a specific baggage header, pastaay can inject faults based on the complete distributed request journey, targeting specific end to end transaction flows rather than individual services.

Community Interceptors. The interceptor pattern is designed to be extensible. Adding a new protocol requires implementing a single interface. I’d like to see community contributed interceptors for Cassandra, Elasticsearch, S3, and whatever else people are running.

If you’ve read this far, you now understand pastaay better than most people who will ever use it. This article is my attempt to document not just what the code does, but why it does it that way, the constraints, the failed approaches, the late night realizations.

Pastaay is at github.com/CemAkan/pastaay. It’s a single Go binary. It has no external runtime dependencies. It works on macOS, Linux, and anywhere Go compiles. Everything in this article is backed by real, working, tested code.

I built this alone, from scratch, during my senior year. If you try it and something breaks, open an issue. If you build an interceptor for a protocol I haven’t covered, open a PR. If you use it to find a bug in production before your users do, that’s exactly why it exists.

Stop Overloading Your REST APIs: A Practical Guide to gRPC

Cem AKAN — Fri, 29 May 2026 19:30:49 +0000

Why traditional REST isn’t always enough and how gRPC is changing the way our microservices talk to each other.

If you are building microservices, mobile backends, or real-time data streams, you have probably hit a wall with traditional API communication. The web has grown, our systems have scaled, and the old ways of doing things are starting to show their limits.

Recently, I had the privilege of presenting a webinar to the Cloud Native Addis Ababa community about one of the most powerful technologies in modern backend development: gRPC. I wanted to adapt that session into a comprehensive article series because understanding gRPC is rapidly becoming an essential skill for any backend engineer.

Before we start looking at lines of code or complex architecture diagrams, we need to set the stage. At its core, modern backend development is entirely about communication. We are not just talking about how we collaborate as humans, but how we enable efficient, strictly typed, and incredibly fast communication between our isolated software services. Finding the right way to manage that constant server-to-server chatter is exactly what solves our biggest performance bottlenecks today.

In this guide, we are going to embark on a deep dive into the world of gRPC. My goal is that by the end of this read, you will not just know what the acronym stands for, but you will know exactly how to architect and build high-performance APIs with it.

Here is our roadmap:

Just to give you a bit of context on who is taking you on this journey: I am Cem, a Computer Engineering senior at Çukurova University. My daily focus is heavily rooted in backend development and system architecture. I spend a lot of my time working on internal automation tools, primarily utilizing Go and Node.js.

Beyond writing code and exploring cloud native tools, I am incredibly passionate about community building. I serve as the founder and leader of the Yazılım Çukurova community because I firmly believe that the absolute best way to learn is to teach and build things together.

Now that the introductions are out of the way, let us jump right into the basics.

My goal is that by the time you finish reading this, you will not just have heard of gRPC. You will understand why it is the preferred framework for modern cloud-native applications. You will know how to define strict interfaces, how to choose between gRPC and REST, and you will understand the power of bidirectional streaming. We are aiming for practical, production ready knowledge.

Let us start with the absolute basics. What exactly is RPC?

It stands for Remote Procedure Call. The concept is beautifully simple: I want to write code on my machine that calls a function on your machine, but I want it to feel exactly like I am calling a local function in my own memory space. I want to tell my code to “calculate the result” and have the magic happen somewhere else on the network without me having to manually open sockets, parse TCP packets, or serialize data. The ultimate goal is transparency.

The diagram from the presentation represents the heart of RPC. When your client code calls a remote function, it is actually talking to a local piece of code called a Client Stub. Think of this stub as a packer. It takes your parameters, say the numbers 5 and 10, and marshals them into a network message. The RPC Runtime then sends this message across the wire.

On the receiving end, the server has a similar stub that unpacks the message, finds the actual function, runs it, and then reverses the whole process for the return value. To your code, it looked like a single, simple function call. To the system, it was a complex round-trip journey.

One of the biggest hidden heavy lifters in this process is Marshalling. Your computer stores objects in a very specific, complex way in its memory. Network wires, however, only understand flat streams of bytes. Marshalling is the translation process of flattening that complex in-memory object into a byte stream that can travel. If your client is written in Python and your server is in Java, this translation gets incredibly complex. This exact complexity is where many older RPC systems stumbled.

The Ghosts of Architectures Past

Traditionally, RPC was designed to mimic a standard function call. Standard function calls are synchronous. You call a function, and your thread freezes until the answer comes back. This is perfectly fine for a simple desktop app. However, in a massive microservices architecture, if Service A waits for Service B, and Service B is waiting for Service C, we suddenly have a cascading latency nightmare.

We did not arrive at our current solutions overnight. In the 90s, the industry tried CORBA. It attempted to solve everything but was famously painful to configure. Then came SOAP, which provided great structure but drowned developers in heavy XML tags. For the last decade or so, REST has been the undisputed king. It leveraged the native language of the web using HTTP and JSON. It was incredibly easy to use. But as our systems grew to massive scales, easy was no longer enough. We needed fast and efficient.

Remember earlier when I said RPC tries to make remote calls look local? That is actually its biggest trap. It is known as the Local Call Fallacy. When you call a local function, it almost never fails. When you call a function over a network, a router might crash, the server might be rebooting, or the Wi-Fi might drop. Traditional RPC frameworks often tried to hide these network errors to maintain that illusion of a local call, which inevitably led to catastrophic application crashes. A truly modern framework needs to acknowledge that the network is a chaotic, unpredictable place.

If REST works, why change?

At this point, you might be asking yourself: If REST is so incredibly popular, why change anything?

Let me be clear, REST is amazing for public APIs where you have no idea who the client is or what language they are using. But for internal microservices? It is horribly inefficient.

Sending JSON means sending repetitive, heavy text over the wire over and over again. Your expensive cloud servers burn valuable CPU cycles just turning plain text into numbers. Furthermore, REST is loosely typed. If I change a field name on the server, the client will not know until it crashes at runtime in production. We desperately need something stricter and lighter.

Another massive challenge is maintenance in a polyglot company. Today, your backend might be in Go, your data science team uses Python, and your frontend is in React. If you update a REST API, you often have to manually rewrite and update the client libraries for all those different languages. This creates an integration hell that severely slows down development cycles.

So, as an industry, we created a wishlist for a modern solution. We realized we needed the strict structural contracts of the old SOAP days, the ease of use of REST, and the raw performance of binary protocols. We needed it to work seamlessly whether we were coding in C++, Go, or Ruby. Critically, we needed it to handle streaming so we could send continuous data without constantly opening and closing network connections.

This was the massive gap that existed in the market around 2015.

This brings us to the star of the show. You see, Google was experiencing these exact scaling and performance problems over a decade ago. To connect their massive data centers, they built an internal tool called Stubby. It worked brilliantly, and in 2015, they rewrote it and open-sourced it to the world as gRPC.

What does the ‘g’ stand for? It originally stood for Google, but today the ‘g’ stands for something different in every single release version. What truly matters is what it represents: the next generation of RPC, designed specifically from the ground up for the incredible scale and speed required by the cloud-native world.

Let us peel back the layers and look at the architecture. gRPC is not just a simple library; it is an entire stack. At the very bottom, doing all the heavy lifting, is HTTP/2. Sitting directly on top of that is the ‘Core’, which is often written in C or C++ to provide raw, uncompromised speed. Finally, at the top, we have the language bindings. This is the part you interact with. Whether you are writing your backend in Python, Go, or Java, you are ultimately driving the exact same high-performance C-core engine underneath. This architecture guarantees consistency and blazing speed across every platform.

The Engine: Why HTTP/2 Changes Everything

If gRPC is a high-performance sports car, HTTP/2 is its engine.

Most traditional REST APIs still run on HTTP/1.1. In the HTTP/1.1 world, if you want to send ten concurrent requests, you often need to open multiple TCP connections or wait in line for each to finish. It is essentially a single-lane road.

HTTP/2 introduces a concept called Multiplexing. It takes your data, breaks it into tiny binary frames, and sends them all at once over a single, long-lived connection. It allows gRPC to handle thousands of concurrent calls without the heavy overhead of constantly opening and closing connections.

This is an absolute killer feature for microservices. Imagine your application needs to fetch a user profile, their recent orders, and their recommendations. In gRPC, these are three separate API calls, but they travel over the exact same network wire at the exact same time. If the ‘orders’ database query is running slow, the profile data is not blocked. It just zips right past it on the multiplexed highway. This efficiency is exactly why gRPC dominates in environments where services chatter constantly.

Now, let us talk about the data payload itself. By default, gRPC uses Protocol Buffers, commonly known as Protobuf. You can think of Protobuf as two distinct things: First, it is a language used to strictly define your API contracts. Second, it is a mechanism to serialize your data into bytes.

People always ask, “Why not just use JSON?” JSON is fantastic for human readability, but it is terrible for machine efficiency. Every time you send a payload like {"name": "Cem"}, you are sending the actual characters 'n', 'a', 'm', 'e' over the network.

In Protobuf, the field ‘name’ is assigned a numeric tag, like ‘1’. This makes the payload significantly smaller on the wire. More importantly, computers can parse binary data drastically faster than they can parse text. When your company is processing billions of internal requests, this efficiency translates directly to saved money and lower CPU usage.

This is what a .proto file actually looks like. It is highly readable but incredibly strict. We define the syntax version, a package name to prevent naming conflicts, and our Messages, which are simply data structures. Notice the = 1 and = 2? Those are the unique numeric tags that replace your field names on the network wire. Finally, we define the Service. We state exactly what methods exist, what inputs they take, and what they return. This file becomes your ironclad contract.

Here is the absolute best part of this entire system: You write that .proto file exactly once. Then, you hand it over to a tool called the protoc compiler. If your backend team uses Go, it generates Go code. If the mobile team uses Swift, it generates native Swift code. It creates all the data classes, the complex networking logic, and the stubs for you automatically. You never write manual HTTP requests or JSON parsers again. You just call methods on these auto-generated objects, which massively speeds up your development cycle.

Because gRPC enforces a Contract First approach, you get compile-time safety. If a developer tries to pass a string into a field that the contract defines as an integer, the code simply will not compile. You catch your errors before you deploy, not at 3 AM when production goes down.

Traditional APIs limit you to a simple request and response. You ask for something, and you wait for the answer. gRPC shatters this limitation by supporting four distinct modes of communication.

The first is Unary, which is your classic request and response. But then it gets incredibly interesting with Streaming.

With Server Streaming, the client sends a single request, such as search for logs, and the server pushes back a continuous stream of results over time.

With Client Streaming, the client uploads a massive amount of continuous data, and the server replies just once at the end. This is absolutely perfect for large file uploads or sensor telemetry.

Finally, we have the holy grail: Bi-directional Streaming. Both sides can send messages whenever they want, entirely independently. The server can send a message while it is still reading requests from the client. Imagine building a live multiplayer video game server or a real-time chat application. You cannot easily do this with standard REST. This unmatched flexibility is what makes gRPC an absolute powerhouse.

Now, let us address the elephant in the room. If REST works so well, why should anyone switch?

It is crucial to understand that this is not about one technology being universally better than the other. It is about choosing the right tool for the job. REST has been the undisputed champion of the web for over a decade because it is flexible and runs absolutely everywhere. gRPC is the modern challenger, built specifically for speed, scale, and strict structure.

Let us compare them head to head across a few key categories to see exactly where each one shines.

The first major difference is entirely philosophical. REST is resource oriented. You are forced to think in terms of Nouns like Books, Users, or Orders, and you manipulate them with standard HTTP verbs like GET or POST. This is very elegant for simple data management. gRPC, on the other hand, is action oriented. You think in Verbs. You define exact methods like GetBook or TriggerWorkflow. If your backend performs complex operations that do not fit neatly into a simple PUT or DELETE, gRPC will feel much more natural to your engineering team.

We touched on the network differences earlier, but it bears repeating. REST typically rides on HTTP/1.1 and sends heavy text payloads. Even if you compress it, it is still text. gRPC is binary all the way down. It uses HTTP/2 advanced features like header compression and binary framing by default. You do not have to spend days configuring these optimizations; they come straight out of the box.

However, here is where REST wins hands down: Browser Support. Every single web browser in the world speaks REST and JSON natively. You can open your developer console right now and type a fetch request. gRPC is much stricter. Because modern browsers do not give developers fine grained control over HTTP/2 frames, you cannot call a gRPC service directly from Chrome or Safari today. You need a translation layer, a proxy, and a special library called gRPC-Web. If you are building a public website, this definitely adds a layer of complexity.

Similarly, debugging REST is easy. You can literally read the network traffic with your own eyes. Debugging gRPC requires a slight mindset shift. Since the wire data is binary, it looks like absolute garbage to human eyes. You need specialized tools that have access to your .proto files to decode the messages back into something readable.

But when we talk about pure performance, the numbers are striking. For internal microservices communication, benchmarks consistently show gRPC being 7 to 10 times faster than REST with JSON. This is not just network speed; it is CPU speed. Your servers spend significantly less time parsing text and more time processing actual business logic. If you are paying for cloud compute by the millisecond, gRPC effectively lowers your infrastructure bill.

So, what is the final verdict?

Stick with REST for your Public APIs. If you are building the next Stripe or Twitter API for the entire world to consume, stick to REST and JSON because it is universal. Use it for browser heavy applications or quick prototypes where you do not want to manage strict contracts.

Choose gRPC for your Internal Microservices. It is the de facto standard for a reason. If you have Service A talking to Service B inside your Kubernetes cluster, use gRPC. It is perfect for polyglot environments and fantastic for mobile apps where saving battery and bandwidth is crucial.

And remember, you do not always have to choose just one. The industry standard is the Hybrid Approach. You expose a friendly REST API to the outside world for browsers and public clients. But as soon as that request hits your API Gateway, it is instantly translated into lightning fast gRPC for all internal server communication.

Enough theory. Let us write some actual code. In this section, we are going to build a real gRPC service from scratch.

We will build a Route Guide system, which is a classic example where clients can send their coordinates and get information about points of interest.

It all starts with the contract. You open a simple text file and name it route_guide.proto. Here, we define our RouteGuide service. We will define a simple Unary method called GetFeature. It takes a Point containing latitude and longitude, and it returns a Feature containing a name and a location.

Notice how incredibly clean this is? We are not worrying about JSON structures or URL paths. We are just defining clear data and behavior.

Next, we run the magic command: protoc. This compiler tool reads our proto file and generates all the heavy lifting code for us automatically. If we are using Python, it creates two files. One contains our data structures, and the other contains the complex networking logic.

There is a golden rule in gRPC development: You never touch these generated files. If you need to change your API, you change the .proto file and simply regenerate them.

Now we switch over to our own Python file to write the server. The generator provided a base class called RouteGuideServicer. All we have to do is inherit from it and write the business logic for GetFeature.

Look how beautifully simple the implementation is. The framework hands us the request object ready to use. We do our business logic, like looking up a database, and then we just return a Feature object. We do not have to serialize anything to JSON. We do not have to set HTTP status codes manually. We just return the Python object, and gRPC handles the rest.

To actually start the server, we create a gRPC server object, define a thread pool to handle concurrent requests, register our class, bind it to a port like 50051, and hit start. That is it. Our high performance binary server is officially running.

Building the client is just as easy. We need two things: a Channel and a Stub. The Channel is the active connection to the server. It handles the TCP connection and security. The Stub is the object we actually interact with.

We open a channel to localhost on port 50051. Then, we just call feature = stub.GetFeature(my_point). This is the true magic of RPC. It looks exactly like a local Python function call. But behind the scenes, gRPC serialized that point, fired it over HTTP/2, waited for the server, and unpacked the resulting Feature. All of that network complexity is completely hidden from you.

What happens if the server is down? In REST, you check for an HTTP 404 or 500 status code. In gRPC, we catch exceptions. If the call fails, the client raises an error, and you can inspect the canonical status codes to see if it was a timeout, a permission issue, or a missing record.

The development loop summary:

We have built a simple service together. That is a great start, but the real world is rarely simple. Sometimes data does not come in a single chunk; it flows continuously like water. Sometimes we need to secure that data against prying eyes. And eventually, we need to scale our application to handle millions of concurrent users.

In this section, we are going to unlock the advanced capabilities that make gRPC a true superhero in the microservices world.

Let us start with Server-Side Streaming. Imagine you want to show a live feed of stock prices or a real time server log. In the REST world, you would have to constantly poll the server every single second, asking if there is new data. It is incredibly wasteful. With gRPC, the client sends a single request saying “I want to subscribe.” The server then keeps the channel open and pushes data continuously whenever an event occurs. You simply add the stream keyword to the return type in your proto file.

Implementing this is deceptively simple. On the server side, instead of returning a static list, we use the Python yield keyword. Every time we yield, a message is flushed to the network immediately. On the client side, it looks exactly like iterating over a list in memory. The loop just blocks and waits for the next item to arrive. It feels entirely intuitive.

Now let us flip that scenario around. What if the client is generating the massive flood of data? Maybe you are uploading a 1GB video file or you have a temperature sensor sending readings every millisecond. You absolutely do not want to open a new HTTP connection for every single reading. With Client-Side streaming, the client writes to the stream continuously. The server listens, aggregates the data, and when the client finally says it is done, the server sends back a single summary response.

Then we have the crown jewel: Bi-directional streaming. In this mode, both the client and the server can send messages whenever they want. They do not have to take turns. The server can send a message while it is still actively reading requests from the client. This is essential for things like a live chat application. I can type a message to you, but I also need to receive messages from others at the exact same time. It enables truly reactive architectures.

Let us switch gears to Security. By default, when we develop locally on our machines, we use insecure channels. But in a production environment, you cannot send unencrypted data. gRPC makes enabling encryption trivial. It uses standard SSL and TLS. You literally change one line of code: swap insecure_channel for secure_channel and provide your SSL certificates. Now your entire connection is encrypted.

Encryption protects the wire itself, but how do we know who is actually calling our API? In REST, we use HTTP Headers for authentication tokens. In gRPC, we call this concept Metadata. Metadata is just key and value pairs that travel alongside your request. You can attach things like Authorization Tokens, Trace IDs, or User IDs. The server can then inspect this metadata to decide whether to allow the request or return a Permission Denied error.

You definitely do not want to write “Check Authentication” code inside every single function you write. That gets messy fast. In web frameworks like Express or Django, we use Middleware. In gRPC, we use Interceptors. An interceptor sits right in front of your service. You can use it to log traffic, validate tokens, or measure performance metrics globally.

Finally, we need to talk about scaling. This is historically the trickiest part of gRPC. In the old HTTP/1.1 world, you make a request, get a response, and close the connection. A standard Load Balancer simply distributes these new connections. But remember that gRPC uses HTTP/2, which keeps a single connection open forever. If you start a client, it connects to Server A and stays there. Even if you spin up Server B and C to help with the load, the client completely ignores them. This is known as the Sticky Connection problem.

How do we fix this? We have two main strategies. First is Client-Side Load Balancing, where the client becomes smart, queries a registry, and rotates its own requests. The second and much more popular approach in Kubernetes environments is using a Layer 7 Proxy like Envoy or Nginx. The proxy sits in the middle, terminates the long lived connection, and distributes the individual internal requests fairly across your backend servers.

We know how it works. Now let us talk about where it works and how to avoid shooting yourself in the foot.

gRPC is the backbone of companies like Netflix, Uber, and Cisco. It is the ultimate Microservices Backbone.

It is also perfect for IoT and Mobile devices because the tiny binary payloads save crucial bandwidth and battery life.

It is the ultimate Polyglot Bridge, allowing your Python Data Science team to talk flawlessly to your Java backend team.

If you are going to use it, you need to follow the best practices. I call these the Golden Rules.

Rule number one: Always set a deadline. Default gRPC calls can wait forever. If a server hangs, your client hangs. You must set a timeout on every call to force the system to fail fast and recover.

Rule number two: Respect the schema. The true power of Protobuf is backward compatibility. You can add new fields, but you must never change the numeric tag of an existing field. If ‘Name’ is field number 1, it stays field number 1 forever.

Rule number three: Centralize your Protos. Do not copy and paste your proto files into every single project. Keep them in a Central Repository, use a CI/CD pipeline to generate the code, and publish them as versioned libraries.

Rule number four: Use Rich Error Handling. Standard error codes are rarely enough. Attach detailed metadata to your errors so the client developer knows exactly which field failed validation.

Rule number five: Mind the size. gRPC is heavily optimized for small and incredibly fast messages. By default, it will not let you send a message larger than 4 megabytes. If you hit this limit, do not just increase the configuration. Use streaming to break your large object into chunks.

Working with binary protocols can be intimidating at first because you cannot just read the network traffic like you do with JSON. Fortunately, the ecosystem has exploded with incredible tools.

If you love the command line, you need grpcurl. It allows you to talk to a server right from your terminal, automatically translating your JSON input into binary Protobuf behind the scenes.

If you prefer a visual interface, Postman now supports gRPC natively. For heavy duty streaming debugging, tools like Kreya or BloomRPC are absolutely fantastic.

The technology is not standing still either. The next frontier is HTTP/3, moving to UDP with the QUIC protocol to handle packet loss on unreliable mobile networks even better. By investing time in gRPC today, you are learning a technology that is heavily future proofed.

We have covered a massive amount of ground today.

If you want to dive deeper, I highly recommend bookmarking the official docs at grpc.io. The Awesome gRPC repository on GitHub is a goldmine, and O’Reilly’s ‘gRPC: Up and Running’ is the standard textbook for mastering this stack.

Also, if you want to revisit any of the topics we discussed today or see the live Q&A session, you can catch the full replay of the stream below:

Thank you so much for joining me on this deep dive. Writing this out after my session with the Cloud Native Addis Ababa community has reminded me just how powerful our modern tooling has become. I hope you feel empowered to go open your code editor and build something significantly faster and stronger using gRPC.

If you build something cool, or if you just want to talk about system architecture, please connect with me on LinkedIn or Twitter. I absolutely love seeing what the community builds.

Happy coding ❤

Rethinking Smart Parking: A Dynamic Line and Box Approach to Computer Vision

Cem AKAN — Fri, 29 May 2026 19:30:06 +0000

In the world of computer vision, there is a dirty secret. Most smart systems are actually quite rigid. If you want to track a parking lot, the standard industry practice involves a developer sitting in front of a monitor for hours, manually clicking on every single corner of every single parking spot. They draw hundreds of static polygons. It is a fragile, exhausting process. If the camera angle shifts by a few degrees or a maintenance crew repaints the lines, the whole system becomes blind.

We knew we needed a system that could think for itself. Instead of drawing a map and telling the machine where to look, why not build a system that understands the environment by observing the cars? This is how Solovision was born. We moved away from hardcoded coordinates and toward a methodology we call the Line and Box approach.

We are all too familiar with the frustration of circling a parking lot for twenty minutes. It is a waste of fuel, time, and sanity. But fixing this should not require a human to manually draw every single spot in a database.

[other]A quick look at the daily struggle of finding a parking spot and how automated detection can change the experience.[/other]

Here is a deep dive into the logic, the math, and the chaotic reality of making a machine see like a human.

The Core Concept: Let the Cars Define the Spots

The fundamental idea behind this new approach is simple. Instead of explicitly defining where the parking spots are, we let the computer vision algorithm figure it out based on where cars are currently parked.

If you see a row of five cars parked next to each other, human logic immediately tells you that they are sitting in a designated parking row. If there is a large gap between the second and third car, you intuitively know that gap is an empty parking space. Our goal was to translate this human intuition into algorithmic logic.

To do this, the system processes a video feed through a specific pipeline built on Python, OpenCV, and the YOLOv8 object detection model.

Step 1- Vehicle Detection The Red Boxes:

The first step is standard object detection. The system takes the video feed and processes it frame by frame using the YOLOv8 model.

YOLOv8 is incredibly fast and accurate at identifying vehicles. For every car it detects it draws a bounding box and returns the coordinates. In our visualization we represent these occupied spaces with red boxes. This granular isolation is the foundation of everything that follows because you cannot connect the dots until you find them.

Step 2- Dynamic Parking Line Inference The Blue Line:

This is where the methodology departs from traditional static mapping. We take the coordinates of all those red boxes and try to find geometric relationships between them.

The algorithm looks for cars that are aligned with one another. It searches for collinearity among the bounding boxes. When it finds a group of cars sitting in a line it calculates a dominant axis or a regression line through them. This line represents the center of that specific parking row. We visualize this as a blue line running through the red boxes.

Step 3- Free Spot Generation The Green Boxes:

Once the system has successfully established a parking line it starts looking for gaps. It measures the distance between the red boxes along that specific blue line.

Of course not every gap is a parking space. Sometimes cars are just parked a bit far apart. To solve this the algorithm compares the gap size to a dynamic threshold typically calculated as roughly one point five times the average width of the detected cars in that row. If the gap is large enough to fit a vehicle the system infers that this empty space is an available parking spot. It then generates a green box to represent it.

Because the system calculates this on the fly it is incredibly resilient. If a camera angle changes slightly the algorithm just recalculates the lines based on the new visual data.

The User Experience

To make this technology easy to use we built a clean web interface. Users do not need to be developers to run it. They can simply upload a pre recorded video file or paste a live camera stream URL directly into the dashboard.

Once the stream is connected the system instantly goes to work. The user is taken to the Live Detection screen where they can watch the algorithm process the environment in real time.

When Logic Meets the Real World

In clean diagrams this methodology looks great. However applying computer vision to a real parking lot introduces plenty of edge cases. The algorithm does not see the world in three dimensions like we do it just sees a flat two dimensional grid of pixels.

When we first tested the dynamic line logic without strict constraints the output was incredibly noisy.

Look closely at the image above. This raw debugging state perfectly illustrates the challenge of dynamic inference. The system detects the cars with red boxes just fine but when it tries to draw the blue lines to establish parking rows it struggles.

Because of the camera perspective cars in the back rows look like they are sitting right on top of cars in the front. The algorithm tries to connect a car from row one to a car from row three generating a web of overlapping lines. When the lines are wrong the gap measurement logic fails. It sees a false gap between two incorrectly connected cars and starts placing green boxes right in the middle of driving lanes.

This false line merging is our biggest hurdle. Sometimes the algorithm figures out the general direction but is just slightly off connecting cars that have nothing to do with each other.

Now contrast that noise with the True state we are actively building towards.

In a successful detection the algorithm isolates each parallel row. The blue lines stay strictly within their designated lanes allowing the gap measurement to work perfectly and place green boxes exactly where real empty spots exist.

Improving the Logic

To move from this noisy debugging state to a stable release we are implementing several backend improvements. Simple dot to dot connections are not enough.

First we are enhancing the tracking stability. By integrating an object tracker like DeepSORT or BYTETrack we can maintain a consistent identification for each vehicle across frames. This stops the bounding boxes from flickering which in turn prevents the green boxes from disappearing and reappearing randomly.

Second we are overhauling the line logic itself. Instead of simple alignment checks we are moving toward robust mathematical algorithms like RANSAC or a Hough Transform. These algorithms can find the true dominant axis of parked cars while ignoring visual outliers caused by camera perspective. We are also adding a post processing step to strictly enforce parallel lines and merge short adjacent segments that belong to the same axis.

Data Logging and Analytics

Once the real time detection is stabilized the final piece of the puzzle is data. The Flask backend sends the status of every spot to the frontend for live monitoring while simultaneously logging the data to a PostgreSQL database. A CSV fallback is used if the database is unavailable.

This historical data is where the real value lies. It allows parking operators to see overall statistics analyze trends and identify peak traffic hours. For instance the system can flag that peak congestion happens between eight and nine in the evening and recommend alternative times for visitors.

Moving Forward

The Line and Box methodology is our attempt to shift away from rigid manual setups toward dynamic intelligent inference. Sure wrestling with real world camera angles and two dimensional perspective is a headache but the payoff is a highly scalable system. We are building something that can look at a parking lot figure out the geometry on its own and just work.

No more drawing fifty manual polygons every time a camera shifts :3

If you want to see how we are tackling these

perspective challenges check out the source code and explore the repository on GitHub at https://github.com/solovision/Solovision to see the progress for yourself.

Goodbye static coordinates. You will not be missed :D

Understanding Kubernetes Before You Lose Your Mind

Cem AKAN — Fri, 29 May 2026 19:23:25 +0000

Hey everyone. If you are tired of reading boring technical docs and want to understand Kubernetes without losing your mind you are exactly where you need to be :)

Grab a coffee and get comfortable. A while ago I gave a detailed presentation on Kubernetes 101 for the UN SDG AI Lab and I realized it would make a highly beneficial Medium article for anyone trying to learn this technology.

Today we are going deep into the architecture and concepts. We will keep it conversational but stay focused on the technical details.

Let us look at our roadmap for today. We are going to talk about the why first. You need to thoroughly understand the fundamental need and the pain points before we touch any new technology. Then we move to the what by actually defining Kubernetes. After that we will explore the how by breaking down the complex architecture into simple mental models. We will also do a live demonstration to prove it all works and map out your path forward.

Before we dive into the deep end let me give you a quick background about myself. I am Cem Akan. I study Computer Engineering at Cukurova University. Right now I am heavily involved in developing an internal automation tool using Go and Node js. On the community side I am the Founder and Leader of Yazilim Cukurova. My core technical interests revolve around Back End Development, DevOps Culture and System Architecture.

Here is what we are going to achieve together today. We will understand the challenges of modern application deployment, define what Kubernetes is and the specific problems it solves, identify its core components and finally witness it in action.

To truly appreciate the peace we have now we must revisit the dark ages. We are talking about the evolution of application deployment.

We started in the traditional era. Back then people deployed applications directly on bare metal servers. It was incredibly expensive and scaling was a massive headache. If you needed more computing power you had to physically buy a new server and set it up manually.

Then the tech industry evolved into the Virtualization era. This let us run multiple virtual computers on one single physical machine. But virtual machines are incredibly heavy because each one needs a full operating system to run.

Finally we reached a new era called containerization.

Let us take a quick look at containers and define what they actually are.

Containerization is a software deployment process. It packages an applications code together with all the files and libraries it needs to run on any infrastructure. This beautiful process creates a single lightweight executable unit that we call a container. You build it once and it just works anywhere without giving you endless configuration headaches.

So life is perfect right. Having one or two containers running on your personal laptop is super easy.

But in the real world you do not just have one container. The true challenge is managing containers at scale. Managing hundreds or thousands of them in a live production environment is absolute chaos.

Picture this scenario. You are fast asleep in your bed. Suddenly a crucial server catches fire and crashes. All your containers on that server die instantly. You wake up to a terrifying 404 error nightmare.

Trying to fix that manually while thousands of users are getting errors is a terrible experience. We definitely need a moment of silence for all the developers who lived through this pain before modern orchestrators existed.

This kind of sudden disaster is exactly why we need automation. But imagine you are having a normal day. Everything is running fine but you need to push a new feature. You need to update your application from version one to version two without stopping service. If you have hundreds of containers managing that traffic and ensuring zero downtime manually is another level of difficulty altogether. This brings us directly to the next huge challenge in application deployment.

Or think about doing a live update. You need to push a new version of your application without dropping any user connections. Trying to handle this update manually across hundreds of containers is a complete nightmare. You are just a developer and not a traffic cop.

Imagine staring at that broken server and thinking there has to be a better way to handle these live deployments and sudden crashes.

But look up in the sky. It is a bird. It is a plane. It is Kubernetes.

When you have hundreds of these containers running wild you need a master conductor to organize the chaos.

What exactly is Kubernetes anyway.

Kubernetes acts exactly like that conductor in an orchestra. It takes all your separate containers and makes them work together in perfect harmony. It is an open source container orchestration system and it completely automates deploying scaling and managing your applications.

So how does it actually solve our 3 AM nightmare. Let us look at the three main superpowers it brings to the table.

First we have self healing. If a container crashes or a node dies Kubernetes instantly notices the exact problem. It does not wait for you to wake up. It automatically restarts or replaces that container to bring your system back to the desired healthy state.

Then we have smart scaling. Imagine your application suddenly goes viral and traffic spikes by ten times. Kubernetes monitors your resource usage and automatically scales your application up by adding more containers. When the traffic drops it scales them back down to save you money.

And remember that live update nightmare. Kubernetes handles auto updates smoothly. It gradually rolls out new versions of your application while taking down the old ones so your users never experience any downtime at all.

Because of these massive benefits it became the undeniable industry standard. It gives you high availability so your app is always online. It provides insane scalability. It gives you infrastructure freedom meaning you can run it on AWS Google Cloud Azure or your own bare metal servers without changing your code. And obviously it leads to massively increased productivity for your developer teams.

Now Kubernetes architecture is famously complex and can be really hard to grasp at first glance. So let us use a mental model.

Analogy time. We are going to look at the maritime shipping industry to understand how a Kubernetes cluster actually operates.

Think of a massive cargo ship that carries physical shipping containers across the ocean.

In our Kubernetes world this cargo ship represents a Worker Node. The worker node is the absolute workhorse of your cluster. It does the actual heavy lifting of running your application containers. A cluster is made up of multiple worker nodes basically a whole fleet of these cargo ships working together.

But a fleet of ships cannot just sail blindly into the ocean. They need direction. Enter the Control Ship.

The control ship represents the Master Node. The master node is the absolute brain of the entire operation. It manages everything plans schedules monitors and tells the cargo ships exactly what to do. The worker nodes just follow the orders given by the master node blindly.

Let us zoom in and look at the specialized crew working inside this Master Node brain.

So we have this massive control ship making all the big decisions but it needs specialized crew members to actually handle specific tasks. First up we have the ship cranes. In the Kubernetes world we call this the Kube Scheduler.

Think about how a real port works. When a brand new shipping container arrives someone has to decide exactly where it goes. You cannot just drop it anywhere and hope for the best. The Kube Scheduler is a core component of the control plane that does exactly this job.

Its main function is to assign newly created pods to specific worker nodes. It does not just throw them randomly. It makes this placement decision based on strict resource requirements policies and other constraints you define. It checks which cargo ship has enough CPU and memory space and assigns the cargo there smoothly. If a ship is full the scheduler is smart enough to find another one.

Now imagine having thousands of containers spread across hundreds of ships. You absolutely need a highly reliable way to track them all. You need to know which containers are on which ships and exactly when they were loaded.

This is where our highly available database comes in. We call it the ETCD cluster.

ETCD is essentially a consistent and highly available key value store. It acts as the primary data store for all cluster data. You can think of it as the ultimate source of truth because it stores and replicates the entire Kubernetes cluster state. If this database goes down your control ship basically loses its memory completely. That is why keeping it healthy and backed up is one of the most critical things in cluster administration.

Moving on we have the offices in the dock. Picture an operation team handling ship control and a cargo team verifying if containers are damaged or need to be rebuilt. In our cluster this is known as the Controller Manager.

The Controller Manager handles various controllers that keep the system running automatically.

These controllers are basically continuous control loops that constantly watch the state of your cluster. When they notice something is wrong they make or request changes immediately. Every single controller tries to move the current cluster state closer to the desired state you originally defined. For example if a node goes down the node controller notices this failure and takes action to handle the onboarding of new nodes or rescheduling the lost workload.

But how do all these different services and teams actually communicate with each other. They need a central IT and communication office. Enter the Kube API Server.

The API Server is the primary management component responsible for orchestrating all operations within a cluster. It exposes the Kubernetes API which is used by external users to perform management operations and by internal controllers to monitor the state of the cluster.

It is literally the front end for the control plane and the central point of communication for all components. Whenever you type a kubectl command in your terminal you are talking directly to this API server.

It does not just blindly accept commands though. It goes through a strict pipeline. First it uses authentication to check who you are. Then it uses authorization to see if you actually have the right permissions. Finally it uses admission control to validate the request before saving the new state to ETCD.

Alright we covered the control ship. Now let us talk about the worker components down in the actual cargo ships. Every good ship needs a captain to manage all sorts of activity on board.

The captain lets the master ship know they are ready to join the fleet and sends regular reports back about the overall status of the ship and its containers. We call this captain the Kubelet.

The Kubelet is an agent that runs on every single worker node in a cluster. Its main job is to watch for pod specifications and ensure the containers described in those specs are running correctly and are perfectly healthy on its node. It is the core component making sure your cargo does not sink into the ocean.

But we still have a networking issue to solve. How will a web server running on one worker node reach out to a database server running on another worker node. Basically how do two separate cargo ships communicate with each other over the network. They use the Kube Proxy service.

Kube Proxy is a network proxy running on each node that manages all the necessary network rules.

These rules enable network communication to your pods from both inside and outside the cluster. It basically handles all the complex routing making the whole Kubernetes service concept actually work without you having to configure routing tables manually on every single machine.

You might be wondering what exactly a pod is and why it is so important. A pod is the smallest deployable unit you can possibly create and manage in Kubernetes. It is the atomic unit of scheduling.

When you tell the master node to run something you do not ask it to run a container. You ask it to run a pod. A pod represents a single running process in your cluster and it can hold one or more containers inside it.

Now a lot of developers ask a very valid question here. They look at this and say why do we even need this extra layer. Why can we not just deploy a basic raw Docker container directly onto the worker node. Why did the engineers invent this whole pod concept.

To understand this you need to think of a pod as a special house. We can call it a pod house.

If you just deploy a raw Docker container it is completely isolated. But in modern architecture your main application often needs sidekick processes to function properly. You might have your main program container but you also need a proxy container to handle network traffic or a log container to collect error messages or a helper container to sync files.

If these were just separate standard containers scattered on a massive server they would have a hard time finding each other and sharing resources securely. But when you put them together inside the same pod house magical things happen. First of all they get a shared network.

Because they are in the same pod they literally share the exact same network namespace and IP address. This means they are speaking the exact same language. They can communicate with each other simply by using localhost.

They just use different ports to talk to one another. It is incredibly fast and efficient. Second they get shared space.

They can mount the exact same storage volumes. So your main application can write a log file to a folder and your helper container can instantly read that exact same file and send it to your monitoring dashboard. The pod creates this perfect cooperative environment for containers that need to be tightly coupled.

But a pod is not immortal. It has a very specific lifecycle from the moment you create it until it dies.

When you first tell the API server to create a pod it enters a pending state while the scheduler looks for a good worker node. Once it is assigned and the containers start it moves to a running state. Eventually it will either finish its job and reach a succeeded state or something will break and it will hit a failed state.

To create a pod you do not click buttons in a user interface. You write a configuration file called a manifest.

This manifest is usually a simple YAML file. You tell it the api version the kind of resource which is Pod in this case and give it metadata like a name. Then in the spec section you define exactly which containers you want inside this pod and what container ports they should expose. You hand this file to the API server and Kubernetes builds the exact house you asked for.

So running one pod is great. But what happens when your application goes viral.

What if you suddenly need one hundred identical pods running at the same time. What if one of those pods randomly crashes at 3 AM. Or what if you need to update the application image inside all one hundred pods without causing any downtime. You absolutely cannot sit there and manage them one by one. That would defeat the entire purpose of automation.

This is where we introduce the ReplicaSet.

The sole purpose of a ReplicaSet is to maintain a stable set of replica pods running at any given time. It acts like a strict manager.

If you define a ReplicaSet and scream give me exactly 3 pods it will constantly monitor the cluster to guarantee the availability of those 3 identical pods. If one pod accidentally dies the ReplicaSet instantly notices the count dropped to 2 and it immediately spins up a brand new pod to replace the dead one.

But we can evolve even further. Managing ReplicaSets directly is a bit outdated because we have an even bigger boss now. We call it a Deployment.

A deployment is a higher level concept that manages both pods and replicasets for you. It allows you to describe the ultimate desired state for your application. The true power of a deployment is that it automates updates scaling and rollbacks in a completely controlled way. It ensures your application is always running exactly as you intended even when you are pushing massive version changes.

When you are ready to release a brand new version of your application a deployment performs what we call a rolling update.

Let us say you are moving from version 1 to version 2 and eventually to version 3. If you just killed all your old pods at once your users would experience a massive outage. Instead a deployment creates a new pod with version 2 waits for it to become completely healthy and then gracefully shuts down one of the old version 1 pods. It repeats this process one by one until your entire application is updated. If something goes terribly wrong with the new code you can just tell the deployment to roll back and it will automatically revert to the previous stable state. It is pure magic for developers.

But there is one final piece to this massive architectural puzzle. We already established that pods are completely mortal. They die they get replaced and when they do their IP addresses change constantly.

So think about this problem. If your backend database pod crashes and gets replaced with a brand new pod it will inevitably have a brand new IP address. How does your frontend web server consistently find that backend database if the address keeps changing every single day.

This is exactly why you use a Service. A service provides a stable permanent IP address and a reliable DNS name for a specific group of pods. It basically acts as an internal load balancer. Instead of your frontend trying to memorize the individual IP addresses of your backend pods it just sends traffic directly to the backend service. The service then routes that traffic to the correct healthy pods automatically. This allows all your different application components to communicate reliably even if the underlying pod IPs are changing a hundred times a day.

All of this theory is amazing but nothing beats seeing it run on your own machine. In my original presentation I did a live demo to prove that this architecture is not just a fairy tale.

If you want to practice all of this yourself I highly recommend installing minikube. It is a fantastic lightweight tool that lets you run a complete single node Kubernetes cluster right on your local laptop. You can create deployments break them fix them and learn the entire system without spending a single dollar on expensive cloud servers.

We covered an insane amount of ground today. We went from the absolute dark ages of bare metal servers to the futuristic automated world of Kubernetes container orchestration. It might seem overwhelming at first but once you understand the cargo ship analogy everything just clicks into place.

I want to give a massive thank you to everyone who stuck around for this deep dive. Also a big shoutout to the UN SDG AI Lab for hosting the original presentation that inspired this guide.

If you want to talk about tech complain about buggy code or just connect with me you can find me on social media. You can also shoot me an email or visit my personal website to see what else I am working on.

Thank you so much for reading and I will catch you all in the next article. Bye for now.

Why Golang?

Cem AKAN — Fri, 29 May 2026 19:19:23 +0000

Hi, if you are reading this sentence, you probably want to switch your language with better alternative.

For example, in my case i started to use Golang(Go) after using Node.js on server side. I learned Node.js a bad option for server side after many crashes and slow speed problems. So, i started to search a better option for my project, after doing a lot of research i found Golang and started to my Golang journey. Now it’s time to share knowledge and experience. So i want to make article series for about to prepare a guide for newies can adapting Golang easier. And this article the first step of the series.

Okay, we chose Golang and we want to learn it. But why? Is it faster or for a cute mascot? Certainly for both 😊. Maybe you can easily understood from the beginning that i am a back-end developer because of it i mentioned servers at above. So speed, safety and simplicity (we don’t want to make a extra challenge with our language’s syntax) are important for me when choose a language for my projects. Especially for huge projects. In this situation, Gopher blinks us. So we have a three criteria. Let’s take a closer look at them.

1- Speed:

None of the users wants a slow app experience, they naturally choose faster one . Because of it, developers which want to more user attraction in their project, pay more attention to speed. You as a developer try to choose a bank which faster when you want to get your app’s income. We understood the speed’s importance for our project’s success. Okay, but Golang is it fast enough? I can clearly say yes. But “yes” isn’t enough for us, so lets compare it with other popular languages.

For server side apps http-server speed of language has a very importance.

In these pictures we can see the http-server speed comparison in higher and lower input situations. So, we can say that Golang has proven itself in server side speed.

2- Safety:

Our second criterion is safety. Especially, nowadays we can see a lot of hack news because of lack of Safety. No matter how hard you strive for your project’s safety, if the language you’re using has vulnerabilities, all efforts might go in vain. Golang is a type safe and memory safe language. For example instead of the other C based languages Golang use garbage collector for being memory safe. So we can give a plus to Golang for safety.

3- Simplicity:

Simplicity is crucial, especially in programming languages, because a simple and understandable language allows developers to write code quickly and debug errors more easily. Golang stands out in this regard by minimizing keywords and having user friendly syntax to achieve these goals. This approach simplifies the understanding of code written in Golang, which is invaluable especially for team projects.

In short, Golang offers speed, security, and simplicity, making it an ideal choice for your large projects. I hope this article has been helpful to you. Wishing you success in your new journey with Golang 🚀

NeoVim From Scratch

Cem AKAN — Fri, 29 May 2026 19:18:14 +0000

Hi, today i will talk about my favorite text editor NeoVim. I will try to cover the installation, modes, usage, shortcuts, configuration and plugins. Alright, hold tight because we’re starting.

1. What is NeoVim?

NeoVim is a modern fork of the terminal-based text editor Vim, retaining Vim’s speed and flexibility while introducing modern enhancements for better performance and extensibility. Primarily used for coding and text manipulation, NeoVim inherits many features from Vim and is interacted with primarily through keyboard commands and shortcuts, minimizing reliance on mouse input.

2. Installation:

NeoVim can be installed in multiple ways on Linux. (It also supports Windows and MacOS, but in this guide, I will only cover Linux.)

The easiest installation option for beginners is the default package manager.

For installation, open your terminal and execute the following command to install NeoVim from your default package manager:

$ sudo apt install neovim     #For Debian, Ubuntu, Linux Mint, etc.
$ sudo dnf install neovim     #For RHEL, Fedora, Alma Linux, etc.
$ sudo pacman -S neovim       #For Arch, Manjaro, EndeavourOS, etc.

After the installation, you can execute the following command to checking the current version of NeoVim.

$ nvim -v

You should see a output like this:

Congratulations, you have successfully installed NeoVim 🎉

3. Modes and Keyboard Shortcuts:

A- Modes:

NeoVim has 13 modes, In this guide, we will only cover the basic 4 modes: Normal, Insert, Visual, Command-line.

a- Normal Mode:

It is NeoVim’s default mode, used for navigation. In normal mode, you can move the cursor, delete, copy, paste, and perform various editing operations using keyboard shortcuts. This mode is ideal for quick navigation and basic file management tasks.For switching your mode to normal mode, you can use the**<ESC>**key.

b- Insert Mode:

Insert mode is NeoVim’s editing mode used for writing and deleting. However, unlike normal mode, you can’t use the cursor because if you try to use it, your mode will switch to visual mode. For switching your mode to insert mode, you can use the ‘**i**’,‘**a**’ or**<insert>**key.

c- Visual Mode:

Visual mode allows users to select blocks of text for manipulation. It is particularly useful for tasks like copying, cutting, or applying operations to selected text. For entering to visual mode, you can use the ‘ v ’ key in normal mode.

d- Command-Line Mode:

NeoVim also has a command-line mode. This mode used to write NeoVim’s base shortcuts like: save, quit, find, replace etc. Also it used for access embedded terminal and mange your plugins’ settings. For switching your mode to command-line mode, you can use the ‘**:**’ key. But ‘ : ’ key can not work on insert mode.

B- Keyboard Shortcuts:

a- Navigation: (For Normal Mode)

h, j, k, l: Move left, down, up, right respectively.
w, b: Move forward by word, backward by word.
gg: Move to the beginning of the file.
G: Move to the end of the file.

b- Editing: (For Normal Mode)

o, O = Open a new line below, above the current line and enter insert mode.
x =Delete character under the cursor.
dd = Delete the current line.
yy = Copy the current line.
p = Paste after the cursor.

c. Saving and Quitting: (For Command-Line Mode)

:w = Save the current file.
:q = Quit NeoVim.
:wq = Save and quit NeoVim.
:q! = Quit without saving (force quit).

d- Search and Replace: (For Command-Line Mode)

/pattern = Search forward for ‘pattern’.
:%s/pattern/replacement = Replace ‘pattern’ with ‘replacement’ on the current line.
:%s/pattern/replacement/g = Replace ‘pattern’ with ‘replacement’ globally in the file.

e- Tabs and Windows: (For Normal Mode)

Ctrl + w + v = Split the window vertically.
Ctrl + w + s = Split the window horizontally.
Ctrl + w + Arrow keys = Navigate between split windows.

4.Configuration:

Nearly all software has a configuration file, or simply a config file. We can make changes to the software by editing its config file. In this part, we will learn how to edit our NeoVim config file.

NeoVim has three different layers:

Vim API: This is inherited from Vim and uses Vimscript.
Nvim API: Written in C, this API is primarily used for remote plugins and GUIs.
Lua API: Written in Lua, this API allows for powerful and flexible configuration using the Lua scripting language.

Therefore, we can divide NeoVim’s configuration system into two main categories: one for Vimscript and one for Lua scripts.

For basic configurations, you can choose either Lua or Vimscript. However, you should only use one of them to avoid configuration conflicts.

A- Classic Vimscript File Configuration:

To open NeoVim’s config file, open your terminal and execute the following command:

nvim ~/.config/nvim/init.vim

Then, select following settings which you want and add them to your config file.

Tab Settings:

set tabstop=4           " Number of spaces that a <Tab> in the file counts for
set shiftwidth=4        " Number of spaces to use for each step of (auto)indent
set expandtab           " Use spaces instead of tabs

UI Settings:

syntax on               " Enable syntax highlighting
set cursorline          " Highlight to current cursorline
set number              " Show line numbers
set showmatch           " Highlights matching parentheses, brackets, or braces when the cursor is on one of them.

Searching Settings:

set ignorecase         " Makes search operations case insensitive.
set hlsearch           " Highlights all occurrences of the search pattern.
set incsearch          " Updates search results incrementally as you type.

Other Important Settings:

set mouse=v                " Enable pasting the copied text with mouse' middle-click.
set clipboard=unnamedplus  " For using the system's clipboard.

B- Basic Lua Configuration:

( Writer Note: In this guide, I will cover the basic Lua configurations to make it more beginner friendly. In the coming days, I will share an advanced and detailed Lua configuration guide. )

To open NeoVim’s second config file, open your terminal and execute the following command:

nvim .config/nvim/init.lua

If the file doesn’t exist, this command will create it.

Then, select following settings which you want and add them to your config file.

Tab Settings:

vim.opt.tabstop = 4           -- Number of spaces that a <Tab> in the file counts for
vim.opt.shiftwidth = 4        -- Number of spaces to use for each step of (auto)indent
vim.opt.expandtab = true      -- Use spaces instead of tabs

UI Settings:

vim.cmd('syntax on')          -- Enable syntax highlighting
vim.opt.cursorline = true     -- Highlight the current cursorline
vim.opt.number = true         -- Show line numbers
vim.opt.showmatch = true      -- Highlight matching parentheses, brackets, or braces when the cursor is on one of them

Searching Settings:

vim.opt.ignorecase = true     -- Make search operations case insensitive
vim.opt.hlsearch = true       -- Highlight all occurrences of the search pattern
vim.opt.incsearch = true      -- Update search results incrementally as you type

Other Important Settings:

vim.opt.mouse = 'v'                -- Enable pasting the copied text with mouse' middle-click
vim.opt.clipboard = 'unnamedplus'  -- Use the system's clipboard

Saving and Exiting

After editing your configuration file, don’t forget to save your changes. Follow these steps:

Press **<Esc>** to switch from Insert mode to Normal mode.
Type ‘**:**’ to enter command-line mode.
Type **w** and press **<Enter>** to save your edits.

5. Plugins:

Using a plugin manager !?

Thanks to plugin managers, we can easily manage our plugins. We can install, update or delete our plugins with single command. There are multiple plugin managers available, but I will talk about vim-plug.

a- Installation:

For installation, open your terminal and execute the following command.

curl -fLo ~/.vim/autoload/plug.vim --create-dirs https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vimsu

b- Usage:

After the installation we should add the vim-plug section in to the NeoVim configuration file.

For opening NeoVim configuration file, you should open your terminal and execute the following command.

nvim ~/.config/nvim/init.vim

Press ‘ i ’ or ‘ a ’ key to entering insert mode to edit configuration file.

Vim-plug section has some rules:

Begin the section should start with =**call plug#begin()**
You can list the plugins with **Plug** commands between call plug sections.
End the section should end with = **call plug#end()**

True vim-plug section example:

call plug#begin()
" List your plugins here
Plug 'tpope/vim-sensible'
call plug#end()

After editing the configuration file, don’t forget to save your changes. For saving you can follow these steps:

Press the **<Esc>** key to switch from insert mode to normal mode.
After entering normal mode, press ‘**:**’ to enter command-line mode.
Type **w** and then press **<Enter>** to save your edits.

c- Vim-plug Commands:

Vim-plug has also some commands for management the plugins easily. We use these commands on command-line mode.

**:PlugInstall** =to install the plugins
**:PlugUpdate** =to install or update the plugins
**:PlugDiff** =to review the changes from the last update
**:PlugClean**= to remove plugins no longer in the list

d- Plugins:

I will introduce the most popular plugin, NERDTree. I am only showing one plugin because the installation process is almost the same for all plugins. If you understand the installation of NERDTree, you will be able to download and install other plugins for your NeoVim.

NERDTree:

This plugin is a file system explorer for our editor. With it, you can visually browse directories and open files.

Installation:

Firstly we should open the NeoVim config. For opening it, you should open your terminal and execute the following command.

nvim ~/.config/nvim/init.vim

After the opening configuration file, we add following text between the vim-plug sections. Save your changes and restart NeoVim.

Plug 'preservim/nerdtree'

In the end, you enter the command-line mode and write :PlugInstall command to install the new plugin.

Usage:

After the installation, NERDTree appear the left side of NeoVim. And now you can easily select your files.

Shortcut:

You can change NERDTree’s key mapping from NeoVim’s config file. By default, the shortcut for opening and closing NERDTree is the ‘ CTRL + k ’ combination.

Change the default key mapping to something that suits your preference. For instance, you might prefer using ‘ CTRL + n ’ for opening and closing NERDTree.

nnoremap <C-n> :NERDTreeToggle<CR>   " Opening and closing NERDTree with Ctrl+n

Congratulations on learning the basics of NeoVim 🎉 You’ve unlocked a powerful tool that will supercharge your text editing and coding workflow. Remember, “To use NeoVim or not to use NeoVim” is no longer a question you’re already on the right path. Keep exploring, keep coding, and enjoy the journey. See you in the next articles 👋

DEV Community: Cem AKAN

Golang Design Patterns: Behavioral Patterns

The Roadmap for Part 3

Why Behavioral Patterns in Go?

Before We Dive In…

1. Strategy Pattern:

A) The Architecture:

B) Go Implementation: The Shopping Cart

C) The Architect’s Perspective:

2. State Pattern:

A) The Architecture:

B) Go Implementation: The Vending Machine

C) The Engineering Edge:

3. Observer Pattern:

A) The Architecture:

B) Go Implementation: The Order Notification System

C) Gopher Wisdom:

4. Mediator Pattern:

A) The Architecture:

B)Go Implementation: Air Traffic Control

C) Why This Wins at Scale:

5. Command Pattern:

A) The Architecture:

B) Go Implementation: The Universal Remote

C) The Clean Code Advantage:

6. Chain of Responsibility Pattern:

A) The Architecture:

B) Go Implementation: The Middleware Chain

C) Beyond the Syntax:

7. Iterator Pattern:

A) The Architecture:

B) Go Implementation: The User Collection

C) Architectural Mastery:

8. Visitor Pattern:

A) The Architecture:

B) Go Implementation: The Project Exporter

C) Why Seasoned Gophers Prefer This:

9. Template Pattern:

A) The Architecture:

B) Go Implementation: The Data Miner

C) Future-Proofing Your Logic:

10. Memento Pattern:

A)The Architecture:

B)Go Implementation: The Undo System

C) The Maintainability Factor:

Behavioral Cheat Sheet

Golang Design Patterns: Structural Patterns.

2- Structural Patterns

Adapter Pattern:

Bridge Pattern:

Composite Pattern:

Facade Pattern:

Proxy Pattern:

Decorator Pattern:

Flyweight Pattern:

Golang Design Patterns: Creational Patterns

First of all, what is the design patterns?

1- Creational Patterns:

Singleton Pattern:

Factory Pattern:

Abstract Factory Pattern*:*

Builder Pattern:

Prototype Pattern:

I Built a Chaos Engine That Goes Where No Tool Has Gone Before

1. Why This Exists

2. System Architecture

3. The Policy Engine

3.1 O(1) Lookup Without a Single Heap Allocation

3.2 Stable Hashing for Policy Identity

3.3 SQL Command Normalization

4. The Config Manager

4.1 Atomic Pointer Swap: How Policy Updates Don’t Block Requests

5. The Hot Reload Watcher

5.1 Why File Watching Is Harder Than You Think

6. The Interceptor Pattern

6.1 HTTP: The Reference Implementation

6.2 The Wildcard Matching Problem

6.3 gRPC: Streaming vs Unary

7. The SQL Driver Wrapper

7.1 Intercepting database/sql at the Driver Level

Abstract Factory Pattern: