DEV Community: Elias Alrgeai

The Hidden Race Condition Inside firstOrCreate()

Elias Alrgeai — Sat, 12 Sep 2026 05:37:00 +0000

A user accidentally double clicks 'add to cart' before the button disables, firing 2 requests to your server. The requests arrive within milliseconds of each other, both calling Cart::firstOrCreate(['user_id' => $userId]) for the same customer.

Both requests check to see if a cart exists, and since neither one has created it yet, neither finds a cart, and both requests proceed to create one, resulting in two for the same user.

This is a massive deal, since it could result in breaking the user experience or even double charging.

How `firstOrCreate()` Can Create a Race Condition

firstOrCreate() seems like an atomic process, but it isn't. Behind the scenes, calling firstOrCreate() runs two separate queries, with a gap between them:

SELECT * FROM carts WHERE user_id = ? LIMIT 1;
-- if nothing found:
INSERT INTO carts (user_id) VALUES (?);

Here is how that gap causes a race condition:

Let's say Request A arrives milliseconds before Request B, and runs the SELECT query first. Request A finds nothing that matches the SELECT. Right before Request A fires its INSERT query, Request B runs its SELECT query, finding nothing either. Now, both requests send an INSERT query, creating duplicate carts.

The Naive Approach

A common assumption is that wrapping firstOrCreate() inside of DB::transaction() makes it atomic:

DB::transaction(function () use ($userId) {
    return Cart::firstOrCreate(['user_id' => $userId]);
});

However, this doesn't actually fix anything. DB::transaction() only creates an atomic environment for requests nested inside of it, and has zero control over a completely separate request out of its scope. Request A and Request B don't know each other, and therefore they can't be wrapped together in a transaction.

The Correct Fix

The correct fix to this issue isn't relying on more application code. Instead, it's enforcing a database-level unique constraint on the column being checked:

$table->unique('user_id');

This way, if two requests both attempt the same INSERT query, the database will reject the duplicate creation attempt, making it impossible for more than one of the queries to succeed. To prevent an unhandled exception, the database rejection must be managed:

use Illuminate\Database\QueryException;

try {
    $cart = Cart::create(['user_id' => $userId]);
} catch (QueryException $e) {
    $cart = Cart::where('user_id', $userId)->first();
}

Implementing a unique constraint makes it structurally impossible for duplicates to occur, since it is forced at the database level where the data exists, not on the application side.

Summary

firstOrCreate() seems like a single operation, but behind the scenes, it's a SELECT query followed by an INSERT query, with a gap between them. If two identical requests arrive within milliseconds of each other, there is a genuine chance that they both fall through, causing duplicate rows in the database.

Wrapping firstOrCreate() inside of the DB::transaction() method doesn't actually fix anything, since DB::transaction() only creates an atomic environment for requests nested inside of it, not completely separate requests it doesn't even know exist.

The correct fix is enforcing a unique constraint at the database level, which makes it structurally impossible for duplicates to happen no matter what.

The Soft Delete Bug That Lets Duplicate Accounts Slip Through (And the Fix in Laravel)

Elias Alrgeai — Sun, 06 Sep 2026 20:30:51 +0000

A client creates an account using the email elias@example.com. Later, they delete the account. A few weeks later, they register again, using the same email they used in their former account.

The registration fails with 'email already taken'.

Why? Because Laravel's soft delete doesn't literally remove the row from the database. It is only a filter on Laravel's side. To your database, the email is still a duplicate.

What Soft Delete Actually Does

When a model uses the SoftDeletes trait, delete() doesn't actually run a DELETE query. Instead, it runs an UPDATE query, changing the deleted_at column to the timestamp it was deleted at. The rest of the row remains completely intact.

Behind the scenes, Laravel adds WHERE deleted_at IS NULL to queries such as User::find() or User::all(), filtering out soft deleted rows. The rows aren't gone, they only get filtered out. Using a command such as User::withTrashed() can still retrieve them.

The database doesn't know 'soft deleted'. It only sees deleted_at with a timestamp.

Where the unique constraint actually lives

A unique constraint on email isn't enforced by Laravel. Instead, it's enforced by the database. When a new row is inserted, the DB checks: 'does any existing row in this table have the same email?'

The check is never enforced by Laravel, and the DB isn't aware that deleted_at with a timestamp means soft deleted, so every single row is checked, including soft deleted ones. If a soft deleted row has the same email as the new row, it will reject it.

The Heavily Flawed Naive Approach

The logical fix seems to just compare both email and deleted_at, making sure they aren't identical. However, this actually introduces a bigger issue.

$table->unique(['email', 'deleted_at']);

You see, in standard SQL, NULL is never equal to another NULL, even inside a unique index. Rows that aren't soft deleted have deleted_at set to NULL by default. This means when the database compares the two 'identical' rows, it will see that both rows have deleted_at set to NULL, and since NULL ≠ NULL, it will allow the new account's creation, even if they are duplicates. This not only fails at fixing the main issue, but now allows for the creation of duplicate accounts.

The Correct Implementation

Never rely on deleted_at being NULL for active rows. Instead, add a column called deleted_at_unix, set its default to 0, and create a composite unique constraint spanning both email and deleted_at_unix:

$table->unsignedInteger('deleted_at_unix')->default(0);
$table->unique(['email', 'deleted_at_unix']);

Rows that have deleted_at_unix set to 0 are active, while soft deleted rows should have the deletion timestamp stored.

Make sure deleted_at_unix is always set correctly by hooking it straight into the model's deleting event:

protected static function booted()
{
    static::deleting(function ($model) {
        $model->deleted_at_unix = now()->timestamp;
        $model->saveQuietly();
    });
}

Since 0 is a real comparable value, MySQL would evaluate any two rows that have deleted_at_unix set to 0 as duplicates, and it won't allow the creation of the new row. A soft-deleted row has deleted_at_unix set to the row's deletion timestamp instead of 0, so a new signup that shares the same email as the soft-deleted row succeeds. Multiple soft-deleted rows sharing the same email also don't cause any issues since they have unique timestamps.

Why Not Just Default `deleted_at` to `0`?

Laravel's SoftDeletes trait identifies active rows as the ones with deleted_at set to NULL, so if anything else is stored, including 0, the row will be recognized as soft deleted.

This is why a separate deleted_at_unix column is used, to keep Laravel's SoftDeletes behaving as it should, while deleted_at_unix enforces a database level unique constraint to prevent duplicate active accounts from being created.

Summary

In other words, soft-delete is a filter that hides rows from Laravel's database queries. The row still exists and takes up storage in the database, and a unique constraint on a column such as email checks every single row, including 'soft-deleted' ones that have a timestamp on deleted_at.

It seems the obvious fix is to create a composite unique constraint across email and deleted_at, however, this introduces a bigger issue. Active rows have deleted_at set to NULL by default, and to MySQL, NULL is never equal to another NULL.

The correct implementation is to add a column called deleted_at_unix defaulted to 0, and setting a composite unique constraint spanning email and deleted_at_unix. When the row is deleted, the value of deleted_at_unix gets updated from 0 to the deletion timestamp.

Integrating this approach correctly ensures new accounts cannot get rejected for sharing the same email as a deleted account, and for duplicate accounts to never slip through.

The Webhook Bug That Gives Cancelled Users Free Access

Elias Alrgeai — Tue, 01 Sep 2026 10:01:48 +0000

A client pays for a subscription, then seconds later they decide to cancel it. Your payment provider sends two webhooks: "payment successful" then "subscription cancelled".

However, your server receives the webhooks in the opposite order, giving free unpaid access to the user.

Why This Happens

Webhooks aren't sent as a single sequence. They are sent separately, traveling at independent speeds and asynchronous times. This means one of the webhooks may get delayed without affecting the other one.

Delays can happen for several reasons such as a network congestion, server load, or the most common: a retry after a failure to respond.

The Naive Approach and Why It Fails

A common approach of handling webhooks is by processing them on arrival, updating the DB as soon as possible. This method has a fatal flaw.

public function handleWebhook(Request $request)
{
    $event = $request->input('type');
    $userId = $request->input('user_id');

    if ($event === 'payment_succeeded') {
        User::find($userId)->update(['active' => true]);
    }

    if ($event === 'subscription_cancelled') {
        User::find($userId)->update(['active' => false]);
    }
}

This naive implementation only works if the webhooks arrive in order. But if 'subscription cancelled' arrives first, it sets active to false, then when 'payment successful' arrives late, active is changed to true, giving free access to the user.

The Correct Implementation

A webhook should only be processed if its actually newer than the last one.

Webhook payloads include a timestamp of when the event actually occurred. The timestamp should be checked before applying any update and stored along with the user's status.

public function handleWebhook(Request $request)
{
    $event = $request->input('type');
    $userId = $request->input('user_id');
    $eventTime = $request->input('timestamp');

    $user = User::find($userId);

    if ($eventTime <= $user->last_event_timestamp) {
        return; // older event, ignore it
    }

    if ($event === 'payment_succeeded') {
        $user->update(['active' => true, 'last_event_timestamp' => $eventTime]);
    }

    if ($event === 'subscription_cancelled') {
        $user->update(['active' => false, 'last_event_timestamp' => $eventTime]);
    }
}

This way, even if 'payment successful' arrives late, it will be rejected before any update can be applied since its timestamp is older than the previous 'subscription cancelled' webhook.

Storing Raw Events First

For extra safety, it's critical to save every incoming webhook to the database immediately, no matter how old the webhook is or whether it was rejected by the timestamp check or not.

This preserves a permanent record of every event exactly the way it was received, so if anything goes wrong, the events are all preserved, untouched, and can be replayed safely at any time. Saving the webhook should happen before the webhook gets processed.

Wrapping Up

Webhooks aren't guaranteed to arrive in the correct order. Processing them on arrival holds the potential of giving the user free, unpaid access.

To prevent handing out free subscriptions, reject any webhook that arrives with a timestamp older than the previous webhook, and make sure to first store the webhook's response as-is in the database just in case you need the record later.

Integrating this system correctly ensures you don't have to worry about webhooks arriving late ever again.

How a Timeout Can Charge Your Customer Twice (And How to Stop It in Laravel)

Elias Alrgeai — Sat, 29 Aug 2026 04:45:30 +0000

A customer attempts a payment. The request safely reaches your server, and the transaction is performed successfully. Then, while the response is being sent back to the client, the connection drops. The client never receives a success message. Instead, they see a timeout.

The client has no possible way of knowing if the charge went through or not, so they logically retry. This is where problems happen. Your server receives a second POST request for attempting the same payment, with no idea if it was successfully charged before or not.

Without correctly handling this scenario, the client gets charged twice.

What an Idempotency Key is

In this context, an idempotency key, usually a UUID, represents a specific payment intent. The client generates the idempotency key, stores it, and sends it along with the request to the server.

Idempotency-Key: 8f14e45f-ceea-4e97-9e39-1b2f3a4c5d6e

The key is sent as a header on the request. If the client re-attempts the payment due to a timeout, it never creates a new one, it instead uses the same key. This way, the server can verify if a transaction has been processed before or not.

The Naive Approach and Why it Fails

Here is an example of a naive way of handling this scenario:

if (!IdempotencyKey::where('key', $key)->exists()) {
    $result = processCharge($request);
    IdempotencyKey::create(['key' => $key, 'response' => $result]);
}

This implementation may look correct, but it has a massive flaw.

A server can handle multiple requests simultaneously. If two requests arrive around the same time, which is more common than expected, both could run exists() before either one gets a chance to save the key. This results in both requests being processed at the same time, double charging the customer.

The Fix: Atomic Locking

The check and save must happen as one process, not two separate steps. That's what Laravel's Cache::lock() is for.

// Block for 5 seconds to let the first request finish processing, then reuse its result
Cache::lock('idempotency:' . $key, 10)->block(5, function () use ($key, $request) {
    $existing = IdempotencyKey::where('key', $key)->first();

    if ($existing) {
        return $existing->response;
    }

    $result = processCharge($request);

    IdempotencyKey::create(['key' => $key, 'response' => $result]);

    return $result;
});

Unlike in the naive implementation, Cache::lock() is used to ensure multiple requests cannot be processed simultaneously. Even if the difference is in milliseconds, whichever request comes first gets the lock, and the second request cannot be processed until the first one is complete, making double charging completely impossible.

Storing the Response, Not Just the Key

In the correct approach, notice that the response is stored along with the key. This is very critical because if the client retries, we want to give them the exact same response that was supposed to be sent back in the original request. From the client's view, the retry looks like a normal, successful request.

Expiration

Idempotency keys should never be stored forever. Once the retry window has passed, the key should be deleted to prevent unnecessary storage cluttering your database.

The majority of implementations store a TTL (time-to-live) with each key. For example, Stripe uses a TTL of 24 hours. Long enough for realistic retry scenarios, but short enough to ensure old keys don't pile up permanently.

A great way of implementing this system in Laravel is by using a scheduled job that scans the DB for old idempotency keys that aren't needed anymore and deletes them.

Wrapping Up

Idempotency keys exist to tell the server if a transaction has already been processed before or not. However, that isn't enough. Two requests can arrive at approximately the same time, double charging a client.

The check and save must happen atomically (locking out simultaneous requests), using a method such as Cache::lock(). It is also crucial to store the response along with the idempotency key, so when the client retries, they receive the same response they would have received with the original request.

Integrating this system correctly ensures that a timeout never leaves you guessing whether a transaction was successful or not.

chunk() vs cursor() vs lazy() — I Benchmarked All 3 So You Don't Have To

Elias Alrgeai — Sat, 22 Aug 2026 10:28:02 +0000

I never truly understood the difference between chunk(), cursor(), and lazy(), so I ran a quick test: I seeded 100,000 rows into a table, then looped through all of them 3 times. Once with chunk(), once with cursor(), and once with lazy(), measuring memory usage, query count, and execution time for each one.

Here's what I learned from this test, and why the difference between these three isn't just syntax. It's a real architectural decision that affects your database connections and your app's stability under load.

The Root Problem

Here is what happens when you run something such as User::all() or User::get() on a big table:

The database runs the query: SELECT * FROM users, and hands back every matching row.
PHP turns each row into an Eloquent model: a full object, sitting in memory, for every single row (this is where the issues happen).

The database doesn't struggle with this. MySQL or Postgres can have millions of rows and still be fine. The issue happens in step 2, when PHP attempts to hold every single one of those rows as an object all at once in RAM.

A single hydrated Eloquent model takes up roughly 5 KB to 10 KB of RAM. On a small app with 1000 users, holding every single row from a table as an object in memory isn't an issue. But on an app with 10,000+ users, RAM usage can easily blow past 128 MB, causing a fatal error crashing the entire operation:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 32768 bytes) in /var/www/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Concerns/HasAttributes.php on line 512

Here is a diagram visualizing the issue:

This issue is exactly why chunk(), cursor(), and lazy() exist. The 3 functions are solutions to this problem, however they have different methods of solving it, and the difference matters significantly.

`chunk()` - Multiple Small Trips

chunk() works by breaking one big query into smaller ones, so your server doesn't have to hold all the rows in memory at once. Instead of hydrating all the rows at once and filling up the server's memory, it performs PHP hydration multiple times, each time with a different group of rows.

User::chunk(200, function ($users) {
    foreach ($users as $user) {
        // process each user
    }
});

Behind the scenes, Laravel actually runs something like SELECT * FROM users LIMIT 200 OFFSET 0, processes that batch, throws it away, then runs LIMIT 200 OFFSET 200. It keeps repeating the process like a loop, until all of the rows are hydrated.

The Twist

When deleting or updating rows while looping, the OFFSET shifts (let's say you're deleting 200 rows at a time, the first 200 rows get deleted, now index 0 has shifted). This causes some rows to get skipped and others processed twice.

The Fix: `chunkById()`

User::chunkById(200, function ($users) {
    // safe even if you delete rows inside the loop
});

Instead of paginating by offset (get the next 200 rows), chunkById() paginates by key (get rows where id > last id processed). This way, if rows get updated or deleted, it doesn't affect the process, since it's based on the row's actual identity.

Here is a clear side-by-side comparison between chunk() and chunkById() visualizing what happens when a record gets deleted:

`cursor()` - One Row at a Time

foreach (User::cursor() as $user) {
    // process each user
}

cursor() works like streaming a YouTube video. It sends one query to the database requesting all of the data, but gets each row one at a time, processes it, discards it, then moves to the next one. This way, cursor() uses up virtually zero memory from your server, no matter how significant the amount of data is. It sounds amazing at first, however, understanding when cursor() should not be used and when it can be useful is very critical.

When NOT to Use `cursor()`

Since it's one query for the entire dataset, the database connection remains busy. This matters a lot:

Slow work inside the loop: If you're doing heavy processing such as calling an external API per row, the connection stays reserved for as long as the loop takes. Let's say you have to process 2000 rows, and it takes 1 second of processing per row. That means the database connection remains completely unusable for 2000 seconds, which is about 33 minutes! If you have a large app with more than 10,000 rows to process, that's about 3 hours.
Limited database connections: During production, it is common for apps to use a limited connection pool. A cursor() loop holding open the connection for a long time can affect other parts of the app, limiting their DB connections.

When `cursor()` Can Be Useful:

cursor() can be very useful in specific situations, where you must prioritize your server's memory over speed. Here are examples where it would be a lifesaver:

Exporting massive data: Let's say you need to generate a CSV file with 500,000 rows. A standard query would crash your server due to memory overload. cursor() effortlessly processess all the rows one by one, while keeping memory usage at virtually zero.
Low traffic background jobs (queues): Running a loop in a background script (such as a Laravel Queue) late at night where not many users are around doesn't affect anything since there aren't actual users competing for DB connections.

`lazy()` - The Most Misunderstood One

User::lazy()->each(function ($user) {
    // process each user
});

Many developers share a very common misconception: lazy() behaves just like cursor(), using a single query.

In reality, lazy() uses the exact same mechanism as chunk(), processing multiple rows at a time. The only difference is on the PHP side. lazy() returns a LazyCollection, giving you access to methods such as map(), filter(), and each().

User::lazy()
    ->filter(fn ($user) => $user->isActive())
    ->each(fn ($user) => $user->sendNewsletter());

The Same Twist

Since lazy() follows the same architecture as chunk(), it comes with the same mutation issue. When updating or deleting rows, some could be skipped or processed twice. The fix to this is lazyById(), which paginates using row ID instead of offset, just like chunkById().

User::lazyById(200)->each(function ($user) {
    // safe even if you delete rows inside the loop
});

`chunk()` vs `cursor()` vs `lazy()` Summarized

Here is a clear summary of the comparison between the three methods:

Method	Query pattern	Description
`chunk()`	Many small queries	Offset-based pagination, batch by batch
`cursor()`	One query	PHP generator that streams one row at a time
`lazy()`	Many small queries	Same mechanism as `chunk()`, chainable on top

Benchmark: The Ultimate Plot Twist

To see the true differences between the three methods in action, I benchmarked them against 100,000 rows (used the same 100,000 rows for each method), measuring peak memory, number of queries, and execution time. If you want to test out this benchmark yourself or check out the setup, the full implementation is on GitHub: https://github.com/EliasAlrgeaiDev/laravel-chunk-cursor-lazy-benchmark

$startMemory = memory_get_usage();
$startTime = microtime(true);
$queryCount = 0;

DB::listen(function () use (&$queryCount) {
    $queryCount++;
});

// run the loop here

$peakMemory = memory_get_peak_usage() - $startMemory;
$executionTime = microtime(true) - $startTime;

Here is a table displaying the benchmark results:

Method	Peak memory	Query count	Execution time
`chunk()`	1.52 MB	501 queries	19.44s
`cursor()`	17.6 MB	1 query	19.86s
`lazy()`	1.52 MB	501 queries	19.39s

The Plot Twist

cursor() is supposed to be the one using the least memory, processing one row at a time, holding almost nothing in memory. But it completely caught me off guard when it used up more memory than chunk() and lazy() combined.

The cause: Laravel thinks it's doing the right thing. However, the query didn't actually hit the database. It was given to PHP's PDO (PHP data object), which by default fetches and holds the entire dataset into memory at once, then gives Laravel each row one at a time, defeating the entire purpose of using cursor().

**Note for non-MySQL devs:** This behavior only happens with MySQL databases, so if you use something else such as PostgreSQL or SQLite, you don't have to worry about any of this.

The fix is to tell PHP to stop hoarding all the data. This forces it to pull only one row at a time from the database, like how it's supposed to. To apply the fix, open config/database.php, go to the MySQL connection array, and update options to this:

// config/database.php, inside the mysql connection array
'options' => [
    PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false,
],

When I re-ran the benchmark, cursor() behaved just like expected, using the least memory:

cursor: 1.48 MB | 1 queries | 20.05s

Why use `chunk()`?

Since chunk() and lazy() performed almost exactly the same, then why does chunk() even exist if lazy() comes with nicer chainable methods while putting up the same numbers? lazy() is the latest one and the more ideal to use, however chunk() does come with 2 benefits in specific scenarios:

Batch level logic: chunk() lets you handle the entire batch as one group, like sending a notification every 200 rows processed, while lazy() only allows you to handle each row separately, so you need to write more syntax to mimic the same design.
Legacy code: lazy() was introduced in Laravel 8, so older projects heavily rely on chunk(). Continuing its use keeps things consistent.

Wrapping up

chunk(), cursor(), and lazy() all solve the same memory issue, but they have their own methods of solving it. chunk() and lazy() follow the same architectural idea, processing the dataset in small trips. The only difference is that lazy() comes with more chainable methods, while chunk() is better if you need batch-level logic or you're working with a legacy codebase. cursor() works completely different, sending one big query requesting the entire dataset, but recieving each row one at a time.

Here is a reference summarizing the differences between the 3 methods:

Situation	Use
Reading only, no chaining needed	`chunk()`
Mutating rows mid-loop	`chunkById()` or `lazyById()`
Need Collection methods (`map`, `filter`, etc.)	`lazy()`
Lowest memory usage	`cursor()`

None are wrong. It only depends on your need. Whether you prioritize saving memory, keeping old code consistent, or chainable methods, all three solve the same memory issue.

If you want to test out this benchmark yourself or check out the setup, the full implementation is on GitHub: https://github.com/EliasAlrgeaiDev/laravel-chunk-cursor-lazy-benchmark

I Made Cron and Queues Share the Work in Laravel — Here's My System

Elias Alrgeai — Sun, 26 Jul 2026 07:00:02 +0000

I used to think that cron jobs and queues are two different solutions, but now I realized they aren't competitors, they are meant to work together. I built a subscription system with automatic renewal billing called SubEngine, and found that integrating queues with cron jobs is highly efficient. Cron handles schedules. Queues handle events.

Here's how I split the work between the two, and why it remains resilient.

Cron vs Queues

Cron runs on a timer. "Every day at midnight, do X."
Queue runs on an event. "This just happened, go handle it."

Both seem like 2 different solutions to a problem, and that’s what it seems at first glance. But implementing the two together creates a highly efficient system, which I will explain why, and how I did it in SubEngine.

My System (SubEngine)

In SubEngine, every subscription with auto-renewal toggled gets a renewal attempt a day before it expires. Whether the renewal failed or succeeded, an email gets sent to the user. Here is how I split the work here:

The cron job's only task is to find who needs a renewal, and attempts
it. It doesn't send anything. Once the renewal attempt is
completed, that outcome, either success or failure, becomes an event. The event gets pushed to the queue, and the queue sends the email to the user.

Cron never touches email. Queue never touches renewal logic.
Two jobs, two responsibilities, no overlap.

Why This Split Makes a Difference

If cron sent the email directly, it must wait on your email provider to respond before moving to the next user. If the provider is slow or down, the entire renewal batch slows down or fails.

By pushing the email work to the queue, the cron remains fast and simple, while the queue can handle retries if the email fails, without ever touching renewal logic. Two systems that can fail independently without taking each other down.

A Quick Note on Scaling

This system works exceptionally on a moderate number of users, but if you've got thousands of subscriptions renewing at once, the cron begins to slow down, and your back to one process doing too much.

The fix: Don't renew inside the cron job itself. Let the cron find who needs renewing, then dispatch a job to the queue per user:

Subscription::dueTomorrow()->lazy()->each(function ($subscription) {
    ProcessRenewal::dispatch($subscription);
});

Now cron's only job is deciding who needs checking. The actual
renewal work happens in parallel, across your queue workers. Cron
gets faster, and your system scales without a rewrite.

Conclusion

Cron decides when. Queues decide what happens next. That split is what makes the system fast and reliable.

If you want to see a complete implementation, check out SubEngine. If you're solving this differently, I'd love to know your method.

Why Midnight Automated Billing Tasks Eventually Fail (And How to Fix It In Laravel 13)

Elias Alrgeai — Wed, 08 Jul 2026 14:15:51 +0000

It's 12:00 AM. Your cron job begins, like it does every night.

Except tonight, you have 40,000 active subscribers instead of 400.

The job begins charging every subscription that's due to expire that day, and in a few seconds, your database connections get maxed out. Stripe may begin returning 429 Too Many Requests errors. Then PHP times out. Now you don't know who actually got charged and who didn't.

This is the midnight cron nightmare. It's one of the most common yet avoidable flaws in subscription billing systems, and almost every self-built backend hits it at one point. Here's exactly why it happens, and how to build it correctly in Laravel 13.

The Straightforward Approach (And Why It Feels Fine at First)

Most subscription systems start out with something like this:

protected function schedule(Schedule $schedule): void
{
    $schedule->call(function () {
        Subscription::where('ends_at', '<=', now())
            ->where('status', 'active')
            ->get()
            ->each(function (Subscription $subscription) {
                $this->chargeSubscription($subscription);
            });
    })->dailyAt('00:00');
}

It's very simple, readable, and works perfectly fine in local dev with 10 test subscriptions. It'll probably survive your first few hundred users too. But this approach doesn't fail because it's wrong on day one. It fails because it's a ticking clock tied directly to your growth curve.

Why This Breaks at Scale

There are four massive issues hiding behind that simple loop:

1. The Chokepoint

If every subscription is set to renew "at expiration," and most of your users signed up around the same time (which happens naturally with growth spikes, promotions, or seasonal signups), you get a massive cluster of renewals landing on the exact same timestamp. This creates one enormous batch with zero distribution.

2. Synchronous Charging Inside a Loop

Calling a payment API synchronously inside a foreach, inside a scheduled command, means your total runtime is (number of subscriptions) × (Stripe API latency). At 40,000 subscriptions and ~300ms per charge, that's over three hours in a single PHP process. That process holds a database connection open the whole time, has a max_execution_time limit, and has no way to resume if it crashes.

3. Stripe (and your database) Will Rate-Limit You

Payment providers cap requests per second for a reason. Hit the API synchronously from one process and you'll get throttled. Throttled requests with no backoff just fail. And if you retry without idempotency, those failures can turn into duplicate charges.

4. No Idempotency = No Safety Net

If the job crashes at subscription #22,000 and you simply re-run it, you now risk re-charging the first 22,000 users who already succeeded. If you aren't tracking which renewals already ran, every retry risks double-charging your users.

None of these are edge cases. They're the default behavior of the naive cron approach once you cross a few thousand active subscriptions.

The Professional Fix: Space-out, Queue, and Track

The fix isn't a bigger server or a longer timeout. It's rethinking three things: when renewals happen, how they're executed, and what proof you keep that they happened. Here's the shape of it end to end:

1. Stagger Billing Windows — Don't Renew Everyone at Once

Instead of one giant midnight batch, spread renewal attempts across a window, and separate the renewal attempt from the actual expiration:

// Two distinct timestamps instead of one
renewal_due_at  // when we should attempt a renew
ends_at         // when access actually ends if renewal fails

Attempting renewal a day or two before ends_at rather than exactly at expiration gives you room to retry failed charges, notify the user, and smoothly kill access if the payment fails, without giving away free unpaid access or charging everyone at the same time.

2. Never Charge Synchronously Inside the Scheduler

The scheduler's only job should be to find who needs billing and dispatch work — not to do the billing itself:

protected function schedule(Schedule $schedule): void
{
    $schedule->call(function () {
        Subscription::query()
            ->where('renewal_due_at', '<=', now())
            ->where('auto_renew', true)
            ->chunkById(200, function ($subscriptions) {
                foreach ($subscriptions as $subscription) {
                    ProcessRenewal::dispatch($subscription);
                }
            });
    })->dailyAt("00:00");
}

Two important changes here:

chunkById() instead of get() — you never load 40,000 Eloquent models into memory at once.
Dispatch a queued job per subscription instead of charging inline — the scheduler's job finishes in milliseconds. The actual charging happens in the queue, where Laravel's worker pool naturally throttles concurrency, retries failed jobs, and won't take your whole app down if one charge hangs.

Notice there's no ->onQueue('billing') at the call site. Laravel 13 added Queue::route(), which lets you define the queue and connection in one place instead of repeating it every time you dispatch a job:

Queue::route(ProcessRenewal::class, connection: 'redis', queue: 'billing');

Running php artisan queue:work with a sane --tries and backoff strategy turns "one giant fragile loop" into "many small, retryable, independently-failing units of work", which is the more reliable and stable approach.

3. Make Every Renewal Attempt Idempotent

This is the piece most naive implementations skip entirely, and it's the one that actually saves you from double-charging customers on retry:

class ProcessRenewal implements ShouldQueue
{
    public function handle(): void
    {
        // Bail if this cycle already resolved — either the renewal
        // already succeeded (renewal_due_at moved forward) or it
        // already failed (auto_renew got turned off).
        if (!$this->subscription->auto_renew || $this->subscription->renewal_due_at->isFuture()) {
            return;
        }

        $result = $this->chargeCustomer($this->subscription);

        if ($result->successful()) {
            $this->subscription->update([
                'renewal_due_at' => now()->addMonth(),
                'ends_at' => now()->addMonth(),
            ]);
        } else {
            $this->subscription->update(['auto_renew' => false]);
            Mail::to($this->subscription->user)->queue(new RenewalFailed($this->subscription));
        }
    }
}

This checks real state, not a timestamp: if the renewal succeeded, renewal_due_at is already in the future. If it failed, auto_renew is already off. Either way, the job bails. If neither happened yet, it means the last attempt didn't reach an outcome, so a retry from Laravel's --tries/backoff mechanism can still fire and actually try the charge again. Pair this with treating the webhook as the real source of truth for a successful charge, and you've closed off the two biggest sources of billing bugs: duplicate charges and false-positive activations.

4. Keep Payment History, Don't Overwrite State

One more habit worth adopting: never delete or overwrite a payment record. Every attempt (successful, failed, or pending) should be its own row. When a customer emails asking "why was I charged twice" or "why did my renewal fail," you want a full audit trail, not a single status column that only remembers the most recent outcome.

Putting It Together

The shift is simple to state and easy to underestimate: stop treating billing as a loop, and start treating it as a distributed, idempotent, queue-driven sequence.

Stagger renewal windows so you're not billing everyone at once
Let the scheduler dispatch, not execute
Queue the actual charge with retries and backoff
Track idempotency so retries are always safe
Trust webhooks over synchronous responses
Keep full payment history for every attempt

None of this is exotic. Separating scheduling from doing, and attempting from confirming. But it's the difference between a billing system that quietly scales past 40,000 users and one that wakes you up at 3 AM.

A Reference Implementation

I ended up building this system in an open-source Laravel 13 backend called SubEngine — a webhook-driven subscription billing engine that implements strategic renewal timing, idempotent scheduler jobs, Stripe webhook verification, and full payment history preservation, with 31 passing tests covering the lifecycle end to end.

It's lightweight, focused on the backend billing logic that tends to break in the real world. If you're building (or rebuilding) subscription billing in Laravel, it's worth a look as a reference or a starting template.

If this saved you from a future midnight crash, a star on the repo goes a long way.

DEV Community: Elias Alrgeai

The Hidden Race Condition Inside firstOrCreate()

How firstOrCreate() Can Create a Race Condition

The Naive Approach

The Correct Fix

Summary

The Soft Delete Bug That Lets Duplicate Accounts Slip Through (And the Fix in Laravel)

What Soft Delete Actually Does

Where the unique constraint actually lives

The Heavily Flawed Naive Approach

The Correct Implementation

Why Not Just Default deleted_at to 0?

Summary

The Webhook Bug That Gives Cancelled Users Free Access

Why This Happens

The Naive Approach and Why It Fails

The Correct Implementation

Storing Raw Events First

Wrapping Up

How a Timeout Can Charge Your Customer Twice (And How to Stop It in Laravel)

What an Idempotency Key is

The Naive Approach and Why it Fails

The Fix: Atomic Locking

Storing the Response, Not Just the Key

Expiration

Wrapping Up

chunk() vs cursor() vs lazy() — I Benchmarked All 3 So You Don't Have To

The Root Problem

chunk() - Multiple Small Trips

The Twist

The Fix: chunkById()

cursor() - One Row at a Time

When NOT to Use cursor()

When cursor() Can Be Useful:

lazy() - The Most Misunderstood One

The Same Twist

chunk() vs cursor() vs lazy() Summarized

Benchmark: The Ultimate Plot Twist

The Plot Twist

Why use chunk()?

Wrapping up

I Made Cron and Queues Share the Work in Laravel — Here's My System

Cron vs Queues

My System (SubEngine)

Why This Split Makes a Difference

A Quick Note on Scaling

Conclusion

Why Midnight Automated Billing Tasks Eventually Fail (And How to Fix It In Laravel 13)

The Straightforward Approach (And Why It Feels Fine at First)

Why This Breaks at Scale

The Professional Fix: Space-out, Queue, and Track

1. Stagger Billing Windows — Don't Renew Everyone at Once

2. Never Charge Synchronously Inside the Scheduler

3. Make Every Renewal Attempt Idempotent

4. Keep Payment History, Don't Overwrite State

Putting It Together

A Reference Implementation

How `firstOrCreate()` Can Create a Race Condition

Why Not Just Default `deleted_at` to `0`?

`chunk()` - Multiple Small Trips

The Fix: `chunkById()`

`cursor()` - One Row at a Time

When NOT to Use `cursor()`

When `cursor()` Can Be Useful:

`lazy()` - The Most Misunderstood One

`chunk()` vs `cursor()` vs `lazy()` Summarized

Why use `chunk()`?