Queues look simple until your system is under real load.

At small scale, you can usually get away with:

• “Just retry it”
• “It probably won’t run twice”
• “We’ll check logs if something breaks”

At scale, that mindset turns into:

• Duplicate emails sent to customers
• Orders processed twice
• Infinite retry loops burning CPU and money
• Poison messages blocking entire queues

This post is a practical guide to three concepts that make or break queue-based systems in production:

• Idempotency (doing things safely more than once)
• Retries (when and how to retry without making things worse)
• Dead-letter queues (what to do when a message is truly broken)

Examples are generic, but this applies directly to Laravel queues, SQS, RabbitMQ, Kafka consumers, etc.

1. First: assume your job WILL run more than once

If you take only one thing from this article, take this:

At scale, every job must be safe to run multiple times.

Why?

• Workers crash mid-job
• Timeouts happen
• Network calls fail after the remote side already processed the request
• The queue system may redeliver the same message
• You may manually retry jobs

So you must design jobs to be idempotent.

2. Idempotency: making “run twice” safe

Idempotent means:

Running the same job 1 time or 10 times produces the same final result.

❌ Bad example (not idempotent)

public function handle()
{
    Order::find($this->orderId)->markAsPaid();
    Invoice::createForOrder($this->orderId);
    Mail::to($user)->send(new OrderPaidMail());
}

If this runs twice:

• You may mark the order paid twice
• You may create two invoices
• You may send two emails 😬

✅ Better: guard with state

public function handle()
{
    $order = Order::find($this->orderId);

    if ($order->status === 'paid') {
        return; // already processed, safe exit
    }

    DB::transaction(function () use ($order) {
        $order->markAsPaid();

        Invoice::firstOrCreate([
            'order_id' => $order->id,
        ]);

        Mail::to($order->user)->send(new OrderPaidMail());
    });
}

Key ideas:

• Check current state first
• Use unique constraints / firstOrCreate
• Wrap critical changes in transactions
• Design side effects to be deduplicated

Even better: idempotency keys

For external APIs or critical operations:

• Store a unique idempotency key (e.g. event_id, message_id)
• Before processing, check if it was already handled
• If yes → exit safely

This is mandatory when dealing with:

• Payments
• Webhooks
• Inventory changes
• Email/SMS sending

3. Retries: when “just retry” becomes dangerous

Retries are good. Blind retries are not.

The 3 types of failures

Transient (good for retries)

• Network timeout
• Temporary DB overload
• 3rd-party API hiccup

Persistent (retries will never fix it)

• Invalid payload
• Missing database record
• Business rule violation

Poison (breaks your worker every time)

• Bug in code
• Unexpected data shape
• Serialization issues

If you retry everything blindly:

• You waste resources
• You block queues
• You hide real bugs
• You create retry storms under load

4. Smart retry strategy

1) Limit retries

Always cap retries:

• Laravel: $tries = 5
• SQS / RabbitMQ: max receive count
• Kafka: max attempts or backoff strategy

After N attempts → stop and move to DLQ.

2) Use backoff (very important)

Instead of retrying immediately:

• 10s → 30s → 2m → 10m → 1h

This:

• Reduces pressure on dependencies
• Avoids retry storms
• Gives time for transient issues to recover

In Laravel:

public function backoff()
{
    return [10, 30, 120, 600];
}

3) Classify errors

Inside your job:

try {
    $this->callExternalApi();
} catch (TemporaryNetworkException $e) {
    throw $e; // retry
} catch (InvalidPayloadException $e) {
    $this->fail($e); // do NOT retry
}

Rule of thumb:

• Transient error → retry
• Logic/data error → fail fast → DLQ

5. Dead-letter queues: your safety net

A Dead-Letter Queue (DLQ) is where messages go when:

• They exceeded max retries
• They are explicitly marked as failed
• They keep crashing workers

This is not a graveyard. It’s a debugging tool.

What should you do with DLQ messages?

• Log them with full context
• Alert when DLQ rate increases

Build a small admin tool to:

• Inspect payload
• See error reason
• Replay the job after fixing the issue

Common DLQ causes in real systems

• Code deployed that can’t handle older messages
• Data shape changed
• Missing foreign keys
• Assumptions that were never true in production

If you don’t have DLQs:

You’re either losing data silently or blocking your queues without knowing.

6. The “production-grade” checklist

If your queue system does all of this, you’re in good shape:

• ✅ Jobs are idempotent
• ✅ Side effects are deduplicated
• ✅ Retries are capped
• ✅ Retries use backoff
• ✅ Transient vs permanent errors are distinguished
• ✅ Dead-letter queue is enabled
• ✅ DLQ is monitored
• ✅ You can replay failed jobs safely

7. The uncomfortable truth

Most queue bugs only appear under load, partial failures, or bad data.

That’s why:

• Local tests pass
• Staging looks fine
• Production explodes at 10× traffic

Designing for retries, duplicates, and failures is not “over-engineering”.
It’s the difference between a system that degrades gracefully and one that wakes you up at 3am.

8. Final thought

Queues don’t make systems reliable.

Defensive design does.

If you want queues that scale:

• Assume duplication
• Expect failure
• Design for recovery, not perfection

Polymorphic relationships in relational databases offer flexibility in modeling various types of associations within a single framework. However, whether they are a good idea depends on the specific requirements of your application and the trade-offs you are willing to make. Here are some considerations:

Advantages

1. Flexibility: Polymorphic relationships allow a single foreign key to reference multiple types of entities, making it easier to associate a wide variety of objects with a single entity.
2. Simplification: They can simplify the schema by reducing the number of tables and relationships needed to represent complex associations between different entity types.

Disadvantages

1. Referential Integrity: Traditional relational databases like MySQL enforce referential integrity through foreign keys, which isn't directly possible with polymorphic relationships. This means you can't rely on the database to automatically ensure that all references are valid, leading to potential data integrity issues.
2. Query Complexity: Queries involving polymorphic associations can become more complex and less intuitive, especially when you need to join multiple tables based on the type of the associated entity.
3. Performance: The need to filter by an additional column (entity_type in many implementations) and potentially join multiple tables to retrieve all related entities can lead to performance issues, especially as the dataset grows.
4. Database Features Limitation: You might not be able to use some database features, such as cascading deletes, as straightforwardly as you would with standard foreign key relationships.

Best Practices

• Use Sparingly: Consider polymorphic relationships only when you have a clear use case that benefits significantly from this flexibility, and the disadvantages are manageable within the context of your application.
• Application-level Integrity: Implement checks and balances in your application code to ensure data integrity, given the database won't enforce referential integrity for polymorphic relationships.
• Documentation: Thoroughly document your database schema and the logic behind any polymorphic relationships to ensure that future developers can understand and maintain the system effectively.
• Alternative Approaches: Evaluate alternative data modeling techniques, such as table inheritance (using a separate table for each entity type but with a common structure) or entity-attribute-value (EAV) models, to see if they might meet your needs with fewer trade-offs.

In summary, while polymorphic relationships can be powerful for certain use cases, they come with significant considerations that might make them less suitable for traditional relational database systems, especially when data integrity and performance are top priorities.

Starting a new company or launching a new product can be exciting, but it also comes with a lot of decisions to make. One of the most important decisions you'll need to make is what tech stack to use. The tech stack refers to the combination of programming languages, frameworks, and tools you'll use to build your product. Choosing the right tech stack can have a significant impact on the success of your company or product, so it's essential to approach this decision with care.

Here are five strategies you can use to choose the right tech stack for your start-up:

1. Consider your target market: The first thing you need to consider when choosing a tech stack is your target market. For example, are you building a product for consumers or businesses? Will your product be used on mobile devices or desktop computers? The answers to these questions will help you narrow your options and choose a good-suited tech stack for your target market.
2. Look at the job market: The job market is another critical factor to consider when choosing a tech stack. You'll want to choose a tech stack that is in high demand so that you can find developers with the skills you need to build your product. Look at job postings in your area or online, and see which tech stacks are used most frequently.
3. Think about scalability: As your company or product grows, you'll need to be able to scale your tech stack to meet the increased demand. Consider the scalability of the different tech stacks you're considering, and choose one that can handle large amounts of traffic and data.
4. Consider the costs: Building a product or company can be expensive, so you'll want to be mindful of the costs associated with different tech stacks. For example, some tech stacks may require costly licenses, while others may be open-source and free to use. So make sure to factor in the costs when making your decision.
5. Look at the community: Finally, consider the community surrounding the tech stack you're considering. A strong community means that many people use and contribute to the stack, which can be a good indicator of its health and longevity and solutions to common problems already available and battle-tested. If you are developing a real product with strict deadlines, avoid novel tech stacks.

Adding to all the above and unless you have really strict requirements (e.g. financial or healthcare industries), choose a tech stack that allows you to get to market as quickly as possible.

Perfect products delivered past deadline kill companies faster than decent products delivered on-time.
Tim Ferris

In conclusion, choosing the right tech stack for your start-up is crucial. By considering your target market, job market, scalability, costs and community, you can make an informed decision and select the tech stack that will help you achieve your goals and build a successful company or product.

Exporting large datasets in Laravel can be challenging, as you need to be mindful of memory limits and processing time.

Have you seen this error message when exporting large datasets in Laravel?
Allowed memory size of 134217728 bytes exhausted (tried to allocate 20971520 bytes)

This was a problem I struggled with for a long time using the Laravel Excel package until I found spatie/simple-excel, which makes this very easy.

The example below will export a list of users into a CSV quickly and efficiently without exhausting the memory. I have used this method with over 200k records generating a CSV file of over 30MB in a few minutes.

<?php

namespace App\Http\Controllers;

use App\User;
use Illuminate\Http\Request;
use Maatwebsite\Excel\Facades\Excel;
use Spatie\SimpleExcel\SimpleExcelWriter;

class UserExportController extends Controller
{
    public function export()
    {
        $writer = SimpleExcelWriter::streamDownload('users.csv');
        $query = User::orderBy('created_at');
        
        $i = 0;
        foreach ($query->lazy(1000) as $user) 
        {
            $writer->addRow($user->toArray());

            if ($i % 1000 === 0) {
                flush(); // Flush the buffer every 1000 rows
            }
            $i++;
        }

        return $writer->toBrowser();
    }
}

Exporting  in Laravel Livewire

The method mentioned above does not work in Laravel Livewire. I attempted several methods suggested on GitHub that were supposed to work, but none of them worked for me.

To resolve this issue, I created a new endpoint using a controller that is not a Livewire component and implemented the method above. The download button in the Livewire component now links to this endpoint, passing any required parameters, and the download starts immediately.

Check sample code below!

<?php
// Route
Route::get('/campaigns/{campaignId}/recipients/download/{status?}', ['as' => 'uni.api.campaigns.recipients.download', 'uses' => 'Uni\Api\Campaigns\CampaignRecipientsDownloadController@index']);

<?php
// Controller

namespace Papillon\Http\Controllers\Uni\Api\Campaigns;

use Illuminate\Support\Str;
use Papillon\Campaigns\Campaign;
use Papillon\Campaigns\CampaignReporting;
use Spatie\SimpleExcel\SimpleExcelWriter;

class CampaignRecipientsDownloadController
{
	protected $campaign;
	protected $status = null;

	public function index($campaignId, $status = null)
	{
		$this->campaign = Campaign::findOrFail($campaignId);
		$this->status = $status;

		$fileName = Str::slug($this->campaign->name) . '-' . $this->status . '-' . now()->format('Ymd_His') . '.csv';
		$writer = SimpleExcelWriter::streamDownload($fileName);

		
		$i = 0;
		foreach ($this->getRecipientsList()->lazy(150) as $recipient) {
			$writer->addRow([
				'id' => $recipient->id,
				'email' => $recipient->email,
				'first_name' => $recipient->first_name,
				'last_name' => $recipient->last_name,
				'job_title' => $recipient->job_title,
				'company' => $recipient->company,
				'country' => $recipient->country,
				'status' => $recipient->status,
				'opened' => $recipient->opened ? 'Yes' : 'No',
				'clicked' => $recipient->click_count
			]);

			if ($i % 1000 === 0) {
				flush(); // Flush the buffer every 1000 rows
			}
			$i++;
		}


		return $writer->toBrowser();
	}

	private function getRecipientsList()
	{
		return resolve(CampaignReporting::class)->getRecipientsList($this->campaign, true, true);
	}
}

<!-- Download button -->
<x-wave-toolbar.link
    icon-set="material-symbols"
    icon="download"
    x-tooltip="`Export recipients`"
    :href="route('uni.api.campaigns.recipients.download', [$this->campaign->id, $this->recipientStatus])"
></x-wave-toolbar.link>

Every company relies on software to function effectively, whether a traditional business or a technology company. Code quality becomes increasingly crucial for a company's success as software continues to shape our world.

When I started programming 15 years ago, I thought the most important thing was that “it worked”. As I started working on projects for the long term, it was clear that was not the case.

If you give me a program that works perfectly but is impossible to change, then it won’t work when the requirements change, and I won’t be able to make it work. Therefore the program will become useless.
If you give me a program that does not work but is easy to change, then I can make it work, and keep it working as requirements change. Therefore the program will remain continually useful.
Robert C. Martin

Maintainable code is critical to the success of a product. Code that is easy to change allows the team to move faster and ship features quickly, which is a massive advantage. Software keeps getting more sophisticated, so it is imperative to implement best practices from day one to keep code clean and easy to maintain and extend.

There are many ways in which “code quality”, or lack thereof, affects your company:

Improved maintainability

Well-written and easy-to-understand code is much easier to maintain and modify over time, saving time and resources in the long run.

Better collaboration

Code that is well-documented and follows established coding standards is easier for team members to work on together, improving collaboration and productivity.

Ability to retain talented programmers

Bad code frustrates programmers because it does not allow them to be productive. Good programmers like to move quickly and confidently; if code does not allow them to, they leave. Good code allows programmers to be productive and fulfilled and, in turn, less likely to leave.

Being able to change quickly

In software, as in life, the only constant is change.
Code has a short lifetime; even successful products are continually changing.
Being able to change quickly is critical. Companies able to adapt quickly are the most likely to succeed in the short and long run.

Reduced costs

Code that is of high quality is less likely to contain errors and defects, which can save time and resources that would be spent on fixing those issues.

Increased reliability

High-quality code is more reliable, improving the overall reliability of a business's products or services.

Enhanced security

Good code is less prone to bugs and more secure. Security breaches are very costly and damage the company’s brand. This is especially important for businesses that handle sensitive information.

Improved scalability

Code that is well-written and follows best practices is easier to scale and adapt to changing business needs, allowing businesses to grow and adapt more easily.

Writing good code is hard; that is why good programmers are expensive. Football teams with bad players and companies with bad programmers lose too.

Be a craftsman. You will be pleased in the future and so will your company.

If you don’t understand (yet) why accessibility is so important, please watch this video of a blind person navigating through a website using a screen reader, it will change the way you write and structure HTML.

285 million people are estimated to be visually impaired worldwide: 39 million are blind and 246 have low vision.” (see Visual impairment and blindness).
World Health Organization

When testing Laravel applications that use multiple domains tests get tricky. Imagine an application with the following structure:

• API: api.domain.com
• Backend: manage.domain.com
• Client domains: client1domain.com,client2domain.com, etc..

Route::domain(config('app.domains.api'))->group(function() {
  Route::get('/', 'Api\ApiIndexController@index')->as('api.index');
});

Route::domain(config('app.domains.backend'))->group(function() {
  Route::get('/', 'Backend\BackendIndexController@index')->as('backend.index');
});

// fallback to client domains
Route::group(function() {
  Route::get('/', 'Sites\SitesIndexController@index')->as('site.index');
});

Now let’s see how we would go about testing the routes within each domain.

namespace Tests\Feature\Api;

use Tests\TestCase;

class ApiDomainTest extends TestCase
{
    function setUp(): void
    {
        parent::setUp();
        config(['app.url' => "http://${config('app.domains.api')}"]);
    }

    public function testApiIndex()
    {
        $response = $this->json('GET', route('api.index'));
        $response->assertStatus(200)->assertSeeText('API index.');
    }
}

namespace Tests\Feature\Backend;

use Tests\TestCase;

class BackendDomainTest extends TestCase
{
    function setUp(): void
    {
        parent::setUp();
        config(['app.url' => "https://${config('app.domains.backend')}"]);
    }

    public function testBackendApiIndex()
    {
        $response = $this->json('GET', route('backend.index'));
        $response->assertStatus(200)->assertSeeText('Backend index.');
    }
}

namespace Tests\Feature\Site;

use Tests\TestCase;

class SiteDomainsTest extends TestCase
{
    public function testClient1SiteIndex()
    {
        config(['app.url' => "http://clientdomain1.com"]);
        $response = $this->json('GET', route('site.index'));
        $response->assertStatus(200)->assertSeeText('This is client site 1 index.');
    }

     public function testClient1SiteIndex()
    {
        config(['app.url' => "http://clientdomain2.com"]);
        $response = $this->json('GET', route('site.index'));
        $response->assertStatus(200)->assertSeeText('This is client site 2 index.');
    }
}