Laravel Architecture Patterns for Production

Most Laravel applications work. Routes respond, data gets saved, users can log in. The framework handles it.

Then the hard questions arrive. Can you prove that transaction wasn't tampered with? Or: what happens when a bulk operation dispatches 5,000 jobs overnight? Or: what happens to our users when that third-party API goes down?

These are the questions that separate a Laravel application that works from one that holds up.

This series is built from real production code — written after those questions were asked, after something went wrong, after a requirement changed in a way the original architecture couldn't handle. Every pattern came from a real system under real pressure: fintech, regulated environments, places where "it works" is not a sufficient answer.

Who this is for: You have shipped Laravel to production. You know the framework. Now you are being asked to make the system serious — audit-ready, reliable under load, and defensible under scrutiny. You want the reasoning behind the patterns so you can adapt them, not just the code to copy.

Requirements: PHP 8.0+ and Laravel 9+ for all four parts. Part 4 uses Illuminate\Support\Facades\Context, which requires Laravel 11 — a compatible fallback for earlier versions is shown in that article.

On scope: These patterns came from specific production environments and reflect specific tradeoffs. They are documented decisions, not universal prescriptions. Each article names the tradeoffs and labels the common mistakes so you can make an informed choice for your own context.

The Four Parts

Part 1 — The Audit Trail: Building a System That Remembers

~10 min read · Compliance · Model logging · Request tracing

A request ID generated in middleware that automatically appears in every log line for that request. Field-level model diffs that capture what changed from what value to what — not just that a record was updated. Append-only log files segmented to stay fast at scale. A Gate hook that logs failed permission checks before they become incidents.

A database audit table is mutable. Append-only files are not. That one sentence shapes the entire architecture.

Part 2 — Queue Architecture: Designing Background Work That Holds Up

~9 min read · Queue design · Job architecture · Background processing

Why passing an Eloquent model to a job constructor is the wrong call, and what to pass instead. How to design a queue topology before you are forced to by a problem. Retry strategies matched to transient, rate-limited, and permanent failures. File operations written to survive a crash mid-write.

A password reset email stuck behind a video compression job is not a queue problem. It is a topology problem.

Part 3 — Secure File Uploads: Seven Checks and Why Each One Exists

~9 min read · Security · Middleware · File handling

A middleware that validates seven independent properties of every uploaded file, each one named and explained. Server-side MIME detection using finfo — not the browser's claim. A unique name strategy that removes user-controlled strings from filesystem paths entirely. A storage pattern where no uploaded file is ever directly reachable via HTTP.

getClientMimeType() returns whatever the browser sent. finfo reads the actual bytes. Only one of those is a security check.

Part 4 — External API Reliability: When Their System Goes Down

~9 min read · Integration architecture · Resilience · Fault tolerance

A trait that makes the fallback decision — fail loud or fail silent — explicit in the model, not buried in a catch block. A recovery path for operations that completed externally but failed locally. The idempotency question, and why it matters when the database write fails after the external API already accepted the request.

The 2am outage will still happen. The question is whether your system has a designed response or an improvised one.

Each article stands on its own. But if you are reading from the start, Part 1 establishes a request ID that runs as a thread through every subsequent part.