Hey Dev.to, I'm a 16yo self-taught dev

Elias Alrgeai — Mon, 27 Jul 2026 10:30:02 +0000

Wsg everyone,

I’m a 16-year-old self-taught dev starting to write about my projects and what I’m learning. I’ve got my bio set up and my GitHub linked, but it looks like my account got accidentally blocked by the automatic spam filter because my posts and profile aren't showing up in search.

Just dropping this quick post to say hello and hopefully get a moderator to clear my account so I can start sharing my stuff. Appreciate it!

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