Anass Ez-zouaine — Backend, AI & Shopify Engineer

Trust is not a QA strategy: test AI code too

Sun, 09 Aug 2026 00:00:00 GMT

Trust is not a QA strategy.

It does not matter whether you are reviewing a pull request from a junior developer or accepting an entire feature an autonomous agent produced in ninety seconds. The engineering question is identical: does this code actually work, and how do you know?

Somewhere in the shift to agentic workflows, a lot of teams quietly stopped asking the second half of that question. LLMs emit code that compiles, lints clean, and reads better than most of what humans write under deadline. So the code looks reviewed. Teams merge it, ship it, and find out what it does in production.

Syntax is not semantics

This is the part that catches experienced engineers off guard, because our instincts were trained on human output.

Human code that looks sloppy usually is rough, and we review it accordingly. Human code that looks polished usually got there because someone iterated on it — which means someone thought about it. Polish was a proxy for scrutiny.

LLMs break that correlation completely. Veracode's Spring 2026 GenAI Code Security update measured a syntax correctness rate above 95% across the models it tested, against a security pass rate of 55%. The code is almost always well-formed. It is secure roughly half the time. Formatting stopped carrying any signal about correctness, and most review habits have not caught up.

// Generated in one shot. Clean names, correct types, zero lint warnings.
function calculateDiscount(user: User, cartTotal: number): number {
  if (user.isVip) {
    return cartTotal * 0.2;
  }
  return cartTotal * 0.05;
}

Nothing here is wrong, exactly. It is just unfinished in ways that only show up under real traffic: no guard against a negative cartTotal from a refund flow, no clamp on the maximum discount, no decision about what happens when user arrives undefined from a cache miss. The type signature says those cases cannot happen. The type signature is a claim about the code, not about production.

What the data actually says

Veracode's Spring 2026 report evaluated 80 coding tasks across Java, JavaScript, C#, and Python. The aggregate numbers are worth internalizing, because the failures are not evenly spread — they cluster hard around exactly the categories where a missing sanitizer is invisible in review.

CWE category	Security pass rate
Insecure cryptography (CWE-327)	86%
SQL injection (CWE-89)	82%
Cross-site scripting (CWE-80)	15%
Log injection (CWE-117)	13%

Parameterized queries and modern crypto defaults are baked into the training data — models get those right most of the time because the safe pattern is the common pattern. Output encoding is contextual. Whether a string needs HTML-escaping, attribute-escaping, or JS-escaping depends on where it lands in the template, and the model cannot see the template from inside the function it is writing. So it guesses, and it guesses wrong about six times out of seven.

Language matters too. The same report puts Python at a 62% security pass rate and Java at 29%. If your stack is JVM-heavy, the baseline you are working from is worse than the headline number suggests.

One genuinely encouraging data point: GPT-5 with extended reasoning hit 70–72%, the best pass rate Veracode has observed. That is real improvement. It is still a coin flip you would never accept from a human contributor.

The testing gap in agentic pull requests

Chat completions are one thing. Autonomous agents opening PRs are another, and this is where the accounting gets uncomfortable.

A July 2026 empirical study accepted at ICSME, Test Coverage Analysis of Agentic Pull Requests, analysed 4,882 agent-generated pull requests from the AIDev dataset — 532 Java, 4,350 Python, across five coding agents. Two findings should reshape how you gate merges:

Agents included test changes in only 49.6% of the PRs that touched code under test. Not greenfield repos with no test infrastructure — code that already sat inside a test suite, changed without the suite being touched.

Existing test suites did not pick up the slack. They executed 61.5% of the agents' changed executable lines in Java and just 27.0% in Python. In 64.8% of Python PRs, not one changed line was executed by any existing test. The safety net everyone assumes is there is mostly holes.

Agents optimize for satisfying the prompt. Ask for a checkout feature and you get a controller, a migration, and a view — because that is what "done" looks like from the prompt's perspective. Boundary conditions, negative assertions, and concurrency cases are not in the prompt, so they are not in the diff.

Coverage numbers are lying to you

Here is the failure mode I see most often: a team wires up a coverage gate, sees 90%, and concludes the AI-authored code is verified.

Line coverage measures execution, not verification. It tells you a line ran during the test suite. It says nothing about whether anything checked the result.

A separate 2026 study, All Smoke, No Alarm, looked specifically at what agent-written tests assert. Across 86,156 test-file patches from 33,596 agent-authored pull requests spanning 2,807 repositories — Codex, Copilot, Devin, Cursor, and Claude Code — 80.2% of those patches contained weak or no explicit oracle signals. An agent rewarded for a green build learns very quickly that the cheapest path to green is an assertion that cannot fail.

# 100% line coverage on process_payment. Verifies essentially nothing.
def test_process_payment():
    result = process_payment(100)
    assert result is not None

That test passes if process_payment charges the right amount. It also passes if it charges zero, double-charges, returns a stale object, or silently swallows a declined card. Coverage went up. Confidence should not have.

The fix is mutation testing, which measures the thing you actually care about: if I break the code, does a test go red? Stryker for JS/TS, Infection for PHP, mutmut for Python, PIT for Java. Mutation score is the only coverage-adjacent metric I have found that agents cannot game by writing more assertions of nothing.

Error handling that hides the failure

Back in the ICSME coverage study, there is a number that gets less attention than it deserves: existing tests miss 86.0% of the try/catch blocks agents touch in Java, and 81.0% of Python error-handling constructs. The recovery paths are the least-tested code in the diff.

This is the worst possible failure shape. A crash is loud, has a stack trace, and pages someone. A catch block that logs a generic string and returns a default value produces a system that keeps running while quietly returning wrong answers. You do not find those in staging. You find them in a reconciliation report three weeks later.

When you review agent output, read the catch blocks first. Ask what happens to the caller when the block executes, and whether the log line contains enough context to reconstruct the failure at 3am. That question is also the difference between logging and monitoring — a swallowed exception is logged, and monitored by nobody.

The throughput and stability trade

The 2025 DORA State of AI-assisted Software Development report is the macro version of everything above. Its central finding: higher AI adoption correlates with an increase in delivery throughput and an increase in delivery instability, at the same time.

That is not an argument against AI. It is a statement about where the bottleneck moved. When change volume goes up and the control systems — automated testing, version control discipline, fast feedback — stay where they were, instability is the arithmetic result. DORA's own ROI model puts a number on it: in their sample calculation, a change failure rate drifting from 5% to 6% after AI adoption costs $344,000 in downtime.

AI amplifies whatever your delivery process already was. That is the same trade-off I mapped out in AI vs traditional development, now with a large-scale dataset behind it instead of an argument.

What I actually measure

Coverage percentage is a vanity metric here. These four are not:

Change failure rate, segmented. Tag agent-authored PRs at open time and compute CFR separately from human-authored changes. If you cannot split the two, you cannot tell whether AI is helping.
Mutation score on the diff. Not the repo — the changed lines. It answers "would a test catch a regression here" directly.
Test-change ratio. What share of code-modifying PRs also modify tests. Industry baseline is roughly 50%. Yours should be visible on a dashboard.
Diff coverage, not total coverage. Total coverage hides new code behind a large tested legacy base. Diff coverage exposes exactly the lines that just arrived.

The verification pipeline

Manual review does not scale against agent output. A reviewer facing 800 lines of plausible-looking code per hour is not reviewing — they are skimming for style. The gate has to be automatic, and it has to run on the diff. I make the full case for giving up line-by-line reading separately; this is the tooling that has to exist first.

name: Agentic PR gate
on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  sast:
    runs-on: ubuntu-latest
    container:
      image: semgrep/semgrep
    steps:
      - uses: actions/checkout@v5
      - run: semgrep ci --config=p/owasp-top-ten

  diff-coverage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0
      - uses: shivammathur/setup-php@v2
        with:
          php-version: "8.4"
          coverage: pcov
      - run: composer install --no-interaction --prefer-dist
      - run: vendor/bin/phpunit --coverage-cobertura=coverage.xml
      - run: pipx install diff-cover
      # Fail on new lines that no test executes — total coverage is irrelevant here.
      - run: diff-cover coverage.xml --compare-branch=origin/${{ github.base_ref }} --fail-under=90

  mutation:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0
      - uses: shivammathur/setup-php@v2
        with:
          php-version: "8.4"
          coverage: pcov
      - run: composer install --no-interaction --prefer-dist
      # Mutate only the changed files, and require tests to actually kill the mutants.
      - run: |
          vendor/bin/infection \
            --git-diff-filter=AM \
            --git-diff-base=origin/${{ github.base_ref }} \
            --min-msi=70 \
            --threads=max

Three layers, each catching what the previous one cannot. Semgrep's OWASP ruleset catches the XSS and injection patterns that dominate the failure table above. diff-cover refuses the PR where new lines are unexecuted. Infection refuses the PR where new lines are executed but unasserted — the oracle problem, enforced by a machine rather than by a tired reviewer.

Two practices sit upstream of the pipeline and are worth more than any of it:

Write the spec first. Give the agent the test file, the OpenAPI schema, or the behavioral contract before it writes the implementation. It is much better at satisfying an explicit oracle than at inventing one, and you keep authorship of the definition of correct.

Give the agent real context. A large share of the XSS failures come from the model not being able to see the rendering context. Wiring your agent into the actual schema, actual codebase, and actual docs — the MCP tooling story — measurably reduces guessing. It reduces it. It does not remove the need to verify.

Takeaways

Polish stopped being a proxy for scrutiny. 95% syntax correctness against a 55% security pass rate means clean formatting now tells you nothing about whether the logic holds.
Failures cluster in context-dependent categories. Crypto and SQL injection pass 82–86% of the time. XSS and log injection pass 13–15%. Review output encoding first.
Half of agentic PRs touch code without touching tests, and existing suites execute as little as 27% of the changed lines. Gate on test presence, not good intentions.
Mutation score over line coverage. 80.2% of agent-written test patches carry weak or absent oracles. Only mutation testing catches an assertion that cannot fail.
Read the catch blocks first. Test suites miss over 80% of the error-handling paths agents touch, which means the likely production symptom is a wrong answer, not a crash.

None of this is an argument for writing code by hand. I ship agent-authored code every week. The argument is that verification is the part of the job that did not get automated, and pretending otherwise just moves the discovery of your bugs from CI to your customers.

What is currently standing between an agent-authored PR and production in your pipeline? If the honest answer is "a human skimming the diff," that is worth fixing this quarter — tell me what your stack looks like and I will tell you where I would put the first gate. 🤘

Building secure agentic commerce on Shopify in 2026

Fri, 07 Aug 2026 00:00:00 GMT

An AI agent can discover a product, build a cart, and reach checkout faster than a human. It can also make an expensive mistake in seconds.

Agentic commerce changes the security boundary of a Shopify store. A storefront is no longer only serving pages to people. It exposes product data, pricing, inventory, fulfillment options, checkout actions, and order state to autonomous software.

That creates a real problem. If an agent receives broad Shopify credentials, a prompt injection or an implementation bug can expose customer data or trigger an unauthorized transaction. The fix isn't to block agents. It's to give them a narrow, observable, policy-controlled path through the commerce stack.

The security problem in agentic commerce

Traditional Shopify integrations assume a known application, a fixed workflow, and a human reviewing the final checkout screen. Autonomous agents remove all three assumptions.

A buyer agent may:

Interpret a natural-language request.
Search product catalogs.
Compare variants, prices, and delivery options.
Build a cart across multiple turns.
Select a payment handler.
Complete checkout or hand the buyer to a merchant page.
Monitor fulfillment, refunds, returns, or cancellations.

Every step carries model uncertainty. The agent may misread intent. Product data may be stale. A tool description may be too broad. An external page may carry malicious instructions. A retry may duplicate an action that moves money.

This is why agentic commerce needs a different engineering model. The agent should never hold unrestricted access to Shopify Admin APIs. It should reach approved commerce capabilities through a controlled protocol layer.

The principle is short:

Let the agent reason about commerce, but never let it define its own permissions.

How Shopify agentic commerce works with UCP

The Universal Commerce Protocol (UCP) gives agents and merchants a standard way to describe capabilities, negotiate compatibility, and execute commerce workflows.

Shopify's UCP implementation covers the main buyer journey:

Negotiation and authentication
Product discovery
Cart creation and updates
Checkout creation and completion
Order monitoring and post-purchase events

UCP is not a replacement for Shopify's commerce APIs. It's a standardized interaction layer so different agents and merchant systems can speak in shared commerce concepts. It supports multiple transports — REST, JSON-RPC, MCP, and A2A, plus the JSON-RPC 2.0 channel behind Shopify's Embedded Checkout Protocol — while the business logic stays the same.

The mechanism that matters for security is profile negotiation.

A merchant publishes a business profile, usually at:

https://store.example.com/.well-known/ucp

On Shopify, that profile is tied to the merchant storefront. It's a self-contained document declaring version, services, capabilities, payment_handlers, and — via supported_versions — the profile URIs for older protocol versions. (See the Shopify UCP quick-start for getting the manifest live.)

The agent hosts its own platform profile at an HTTPS URL and passes that URL on every request through the UCP-Agent header. The platform profile mirrors the business one and adds a signing_keys registry. That single document is both the capability declaration and the key-resolution mechanism — which is why profile validation is a security control, not a formality.

Shopify then computes the intersection:

merchant capabilities ∩ agent capabilities = negotiated capabilities

Only compatible capabilities become active. Extensions — dev.ucp.shopping.discounts, dev.ucp.shopping.buyer_consent, dev.ucp.shopping.fulfillment — carry an extends field naming their parent capability, and they never auto-activate. If the parent isn't in the negotiated set, the extension drops out with it.

A trimmed platform profile, showing the shape rather than a complete document:

{
  "version": "2026-04-08",
  "services": {
    "dev.ucp.shopping": {}
  },
  "capabilities": {
    "dev.ucp.shopping.cart": {},
    "dev.ucp.shopping.checkout": {}
  },
  "signing_keys": [
    {
      "kty": "EC",
      "crv": "P-256",
      "kid": "agent-2026-08",
      "x": "...",
      "y": "..."
    }
  ]
}

Protocol versions are still moving through 2026 — check the UCP specification for the current registry shape. Pin the version your integration uses, validate it strictly, and test version negotiation before rollout. Never silently downgrade to an older capability set.

For the wider shift from visual storefronts to programmable commerce, see why agentic commerce will change the way you build Shopify stores.

How do you build secure agentic commerce?

You need an intermediate control plane between the agent and Shopify:

buyer
  ↓
AI agent
  ↓
MCP client
  ↓
intermediate MCP governance server
  ↓
UCP commerce tools
  ↓
Shopify storefront and checkout services

That governance server is the whole point. It keeps the model off sensitive APIs and gives the team one place to enforce policy.

1. Expose task-specific tools

Don't expose a generic shopify_admin_request. Create narrow tools with explicit inputs and outputs:

search_products(query, filters)
get_variant(variant_id)
create_cart(lines, buyer_country)
update_cart(cart_id, lines)
create_checkout(cart_id)
get_order(order_id)

One tool, one well-defined job, every parameter validated against a schema before any downstream request.

Never accept arbitrary GraphQL from an agent. Use fixed queries and allowlisted fields. That prevents data overexposure and shrinks the blast radius of prompt injection.

2. Keep Admin tokens server-side

Admin API tokens belong in a secret manager. Never in:

Agent prompts
Tool responses
Browser JavaScript
Client-side logs
Model context
agents.md
Product descriptions or metafields

The governance server holds the credential and calls only the minimum Shopify operations required. For public product discovery, prefer Storefront API access with appropriate scopes. Reserve Admin API access for back-office operations that genuinely need it.

Use separate credentials for:

Catalog reads
Cart and checkout operations
Order status reads
Fulfillment or refund workflows
Internal administrative actions

Revocation and incident analysis get much easier when the blast radius is already partitioned.

3. Apply capability and state policies

Authorization depends on both the tool and the current commerce state.

Commerce state	Allowed actions	Approval requirement
Discovery	Search products, read public availability	None
Cart building	Add or remove line items, estimate totals	Optional
Pre-checkout	Select fulfillment, validate buyer data	Buyer confirmation
Checkout completion	Submit payment mandate or complete checkout	Strong authentication
Post-purchase	Read order status, track fulfillment	Scoped buyer access

A signed agent is not automatically allowed to complete a purchase. High-risk actions need the right authorization tier, scope, buyer identity, and payment consent.

Treat every checkout completion as a state transition, not an ordinary tool call.

Secure the protocol and the request envelope

The protocol has to authenticate more than the model. It authenticates the agent profile, request origin, capability set, and transaction context.

UCP signs every HTTP-based transport with RFC 9421 HTTP Message Signatures. Signing is asymmetric: ES256 is mandatory, ES384 optional. Public keys are JWKs (RFC 7517) published in the signing_keys array of the signer's profile, and the body is bound in through a Content-Digest header (RFC 9530) computed over the raw body bytes.

A request signature covers @method, @authority, @path, the query, ucp-agent, idempotency-key, and the content headers. Responses cover @status instead of the method. That component list is the security property worth internalizing: the idempotency key is inside the signature, so a replayed request can't be re-pointed at a new operation without invalidating it. UCP deliberately handles replay protection at the business layer through idempotency keys rather than at the signature layer — the RFC 9421 created parameter is optional. If your governance server treats idempotency as an optional convenience, you've removed the replay control.

At the governance layer, verify:

The profile URL from UCP-Agent uses HTTPS.
The profile is valid JSON and within size limits.
The declared UCP version is supported.
Capabilities use compatible versions.
Extension extends dependencies are satisfied.
The signing key resolves from the declared profile's signing_keys.
The signature base reconstructs from the required components.
The Content-Digest matches the raw body you actually read.
Idempotency keys are enforced, stored, and honored on retry.

For custom endpoints, webhooks, or internal proxy routes, HMAC adds a shared-secret check. HMAC does not replace UCP's asymmetric message-signature model — it's an extra control where both parties already share a secret.

A webhook verifier should:

Read the raw request body.
Compute the HMAC using the expected secret.
Compare signatures with a constant-time function.
Reject stale timestamps.
Record the event ID to prevent replay.
Process the event idempotently.

In Laravel terms:

$expected = hash_hmac(
    'sha256',
    $timestamp . '.' . $rawBody,
    $sharedSecret
);

if (!hash_equals($expected, $receivedSignature)) {
    abort(401, 'Invalid signature');
}

Never verify an HMAC over a parsed and re-serialized JSON object. Whitespace and key ordering change the bytes. Verify the original payload.

Human approval is a protocol state

Autonomous doesn't mean every action is automatic.

UCP models graceful escalation through checkout states such as:

incomplete — required information is missing
requires_escalation — buyer input is needed
ready_for_complete — everything is collected and the agent may finalize programmatically

Those three sit alongside complete_in_progress, completed, and canceled in the checkout state machine. A checkout can move back and forth between incomplete and requires_escalation, and it can reach canceled from anywhere.

An agent may select a product and calculate shipping but still need buyer input for a 3DS challenge, address validation, terms acceptance, age verification, or custom selling terms.

Escalation isn't an error path. A requires_escalation response must carry a continue_url and at least one message at escalation severity — that's the merchant handing you a place to send the buyer, plus the reason. Send them there with the cart intact instead of starting over.

Your agent should not try to route around this state. It should surface the escalation messages verbatim and preserve the exact checkout context the merchant returned. The same applies to compliance disclosures: a warning message with presentation: "disclosure" — Prop 65, allergens, age restrictions — must be displayed next to the item it applies to, never collapsed or auto-dismissed. If your surface can't render it faithfully, escalate to continue_url rather than silently downgrading.

Add approval gates for:

Checkout completion
Orders above a configured threshold
Address changes
Discounts outside policy
Refunds and cancellations
Regulated or age-restricted products
Unusual quantity or velocity patterns

Use idempotency keys on every money-moving request. A retry must not create a second checkout or a duplicate order.

Use agents.md for discovery and operational policy

An agents.md file helps compatible tools discover how your application expects agents to behave. Treat it as documentation and policy guidance — never as proof of identity or authorization.

A useful file describes safe defaults, tool boundaries, and failure handling:

# Commerce agent guidance

## Safe defaults

- Use catalog tools for product discovery.
- Never request or expose Shopify Admin tokens.
- Ask for buyer confirmation before checkout completion.
- Respect `requires_escalation` responses.

## Tool boundaries

- Do not call arbitrary GraphQL.
- Do not infer inventory when the API returns unknown.
- Do not modify orders without an authenticated buyer session.

## Failure handling

- Retry read operations with backoff.
- Use idempotency keys for writes.
- Log tool name, request ID, policy decision, and result status.

Keep it version-controlled and review changes like code. Sign or hash the policy bundle if your architecture supports it. A compromised instruction file must never grant permissions the server itself doesn't enforce.

For more on MCP tool boundaries and context control, see Claude MCP and real-time developer tools. The same least-privilege rules apply to commerce agents, and the agentic workflow architecture guide covers human approval and stateful tool loops.

Technical takeaways

Secure agentic commerce is an API and policy engineering problem, not a prompt design problem. Launch checklist:

Publish and validate UCP profiles over HTTPS.
Pin supported protocol and capability versions.
Put an intermediate MCP governance server between agents and Shopify.
Expose narrow, schema-validated tools instead of arbitrary API access.
Keep Admin tokens in a server-side secret manager.
Use scoped credentials for catalog, checkout, orders, and administration.
Verify HTTP Message Signatures and rotate keys.
Add HMAC verification to custom webhooks and proxy endpoints.
Require idempotency for all writes and payment-related operations.
Model checkout as explicit states with human escalation.
Treat agents.md as guidance, never as authorization.
Log every tool call, policy decision, signature result, and transaction identifier.
Test malformed profiles, replay attempts, prompt injection, stale inventory, duplicate retries, and unauthorized checkout attempts.

The opportunity in agentic commerce is large, but trust decides which implementations survive production. What authorization boundary stops your Shopify agent from turning a reasonable buyer request into an unauthorized transaction? If you want a second pair of eyes on that boundary, here's how I work with teams.

MCP vs A2A vs ACP: the agent protocol stack

Wed, 05 Aug 2026 00:00:00 GMT

You are ready to move past single-prompt chatbots and build a real multi-agent system. Then you look at what you actually have: agents that cannot reach your Postgres database without a bespoke script, and cannot coordinate with the agent another team shipped last quarter without a shared Slack channel and a human in the middle.

The missing piece is not model quality. It is a communication standard. Without one, you spend most of your engineering time writing glue code for integrations and very little on the behavior that makes the agents worth running. Every schema change breaks a hand-rolled adapter somewhere.

The good news is that the landscape has converged. Two protocols now cover the two axes that matter: the Model Context Protocol (MCP) for connecting agents to tools and data, and Agent2Agent (A2A) for connecting agents to each other. The Agent Communication Protocol (ACP), the third name you will still see in older posts, has been folded into A2A. This post breaks down what each layer does and how to wire them together.

The current state of agent protocols

In early 2025 you had to pick a vendor SDK and live with it. Function calling looked different on every model, and agent frameworks each invented their own message envelope. Two things changed that.

First, Anthropic donated MCP to the Linux Foundation, where it now sits under the Agentic AI Foundation (AAIF) alongside other agentic projects. Second, Google donated A2A to the Linux Foundation in mid-2025. Both protocols are now governed in the open by the same umbrella, which is the main reason the stack finally stopped moving under everyone's feet.

The second shift is architectural. You no longer need one protocol that does everything. You use a vertical protocol for reaching data and tools, and a horizontal protocol for agents talking to peers.

Protocol	Primary role	Governance	Status
MCP	Agent to tool/data	Linux Foundation, AAIF	De-facto standard
A2A	Agent to agent	Linux Foundation	Stable, actively spec'd
ACP	Agent messaging	Legacy (IBM / BeeAI)	Merged into A2A

MCP: the universal adapter for tools

MCP is the vertical layer. It standardizes how an agent connects to everything that is not another agent: your Shopify store, your Postgres instance, a filesystem, an internal REST service.

Before MCP, giving a model access to a filesystem meant writing a tool definition shaped for that specific model's function-calling format. With MCP you write one server. Any MCP-compatible client — Claude, an IDE assistant, a local model runner — connects and discovers the same capabilities without you rewriting anything.

Why MCP won the tool layer:

JSON-RPC 2.0 on the wire. Boring, well-understood, easy to debug.
Transport flexibility. stdio for local servers, Streamable HTTP for remote ones. (The older HTTP+SSE transport is legacy — new remote servers should use Streamable HTTP.)
Three primitives, not thirty. Servers expose tools the model can call, resources it can read, and prompts the user can invoke. Clients contribute sampling and roots, and a 2025 revision added elicitation so a server can ask the user for missing input mid-call.
Real ecosystem. Thousands of public servers exist for common SaaS platforms, and the official MCP Registry gives clients a discovery path instead of a README scavenger hunt.
Scoped permissions. Servers expose only what you register, so an agent sees the slice of data it needs and nothing else.

If you are modernizing how your systems are consumed, exposing your data through MCP is the highest-leverage first move. It decouples your tools from your model choice, which is the coupling that hurts most when you swap models. I went deeper on the mechanics in API vs MCP and MCP tool-use for context-aware agents.

A2A: the social fabric for agents

MCP handles tools. A2A handles peers. When your merchandising agent needs stock levels from an inventory agent owned by another team — one built on a different framework, deployed in a different cluster — that conversation is A2A. This is the horizontal layer.

A2A lets agents discover each other, delegate tasks, stream progress, and hand back results. The anchor of the protocol is the Agent Card: a JSON document, conventionally served at /.well-known/agent-card.json, that declares who the agent is, which skills it offers, which transports and auth schemes it supports, and what input and output types it accepts. Discovery is fetching that file.

What A2A gives you:

Capability discovery. A client reads an Agent Card (or queries a registry) to find an agent that handles the job, instead of hard-coding a hostname.
Task delegation with a real lifecycle. Tasks move through explicit states — submitted, working, input-required, completed, failed, canceled — so a caller can reason about a long-running job rather than polling a black box.
Streaming and callbacks. Server-Sent Events for live progress on an open connection, plus webhook-style push notifications for tasks that outlive it.
Framework independence. The peer on the other side can be LangGraph, CrewAI, a Laravel service wrapping a model, or something homegrown. The wire format is what you agree on, not the runtime.
Standard auth. Agent Cards declare security schemes, so you authenticate agent-to-agent traffic with the same primitives you already use for APIs.

This is what makes cross-team agents workable. Building agentic commerce on Shopify already means a checkout flow handing structured instructions to fulfillment logic; A2A is what stops that handoff from being a private contract nobody else can reuse.

Why ACP merged into A2A

You will still hit references to the Agent Communication Protocol. ACP came out of IBM and the BeeAI team as a REST-native approach to agent messaging, and it was good at exactly the thing A2A was weakest at early on: stateful, long-running, asynchronous work.

The problem was arithmetic. Two competing agent-to-agent protocols meant every framework author had to pick one or implement both, which is how ecosystems stall. During 2025 the ACP maintainers moved to consolidate behind A2A under Linux Foundation governance.

The practical consequence is short. ACP is no longer an architectural choice you need to evaluate — its strong ideas around state management and durable messaging live on in A2A's task model. If you had ACP on a roadmap, substitute A2A. The concepts map closely and the community is now in one place.

Architecting the two-layer stack

The mental model that keeps this straight: MCP is the device driver, A2A is the network protocol. One lets a process talk to the hardware it is attached to; the other lets it talk to other machines. You need both, and they do not overlap.

An agent is typically an A2A server to its peers and an MCP client to its tools, at the same time. That dual role is the whole architecture.

A workable implementation order:

Data layer (MCP). Wrap your internal APIs and databases in MCP servers. This is the step that pays off immediately, even with a single agent, and it is where a lot of Claude and MCP dev tooling already lives.
Coordination layer (A2A). Put an A2A-compliant interface in front of each agent and publish its Agent Card. This is how informal agentic workflows graduate into services other teams can call.
Governance layer. Route the traffic through an AI gateway so you get auth, rate limits, cost attribution, and traces on both protocols instead of guessing where the spend went.

One caution: a tool call and an agent delegation are not interchangeable, even when both are technically reachable. Exposing another team's agent as an MCP tool flattens away the task lifecycle and turns a long-running negotiation into a request that either returns or times out. Use MCP for deterministic capabilities you own, and A2A when the other side needs to reason, ask you a follow-up question, or take twenty minutes.

Practical implementation tips

Moving to a protocol-first architecture is mostly a change in what you consider the unit of work. Stop shipping "an agent" and start shipping services that speak these standards.

Audit your tools first. Pick the five tools your agents actually reach for and build or adopt MCP servers for them. Resist wrapping everything — an agent handed forty tools makes worse choices than one handed six.

Write Agent Cards early. Even with two agents, defining the card forces you to name each agent's skills and boundaries. Most multi-agent designs fail because responsibilities overlap, and the card is where that shows up before it becomes a runtime problem.

Standardize transports. Streamable HTTP for remote MCP servers, HTTP with SSE for A2A streaming. Streaming matters more than it looks: without it you cannot see intermediate reasoning or partial tool output, and debugging a multi-agent failure becomes archaeology.

Version the contracts, not the prompts. Agent Cards and tool schemas are public interfaces now. Treat a changed tool signature like a breaking API change, because for every agent calling it, that is exactly what it is.

Instrument at the boundary. Every MCP call and A2A task should emit a trace with a correlation ID that survives delegation. When a five-agent chain returns nonsense, the only cheap way to find the bad hop is a trace that spans all of them.

Takeaways

MCP is vertical. It connects agents to tools, databases, and APIs, and it is the de-facto standard for that layer.
A2A is horizontal. It handles discovery, delegation, and task lifecycle between agents, across frameworks and teams.
ACP is legacy. It merged into A2A. Do not start new work on standalone ACP.
Governance is settled. Both protocols now sit under Linux Foundation stewardship, which is what makes them safe to build against.
Each agent plays two roles. A2A server to its peers, MCP client to its tools — that dual role is the stack in one sentence.
The boundary matters. Deterministic capability you own is a tool; another team's reasoning system is a peer. Mixing them up is how the architecture rots.

How are you handling coordination between agent frameworks in your production stack right now? If you are wiring MCP and A2A into a real product, here's how I help teams ship it.

Coolify in 2026: why 60k developers chose self-hosted PaaS

Mon, 03 Aug 2026 00:00:00 GMT

Scaling a web app used to mean signing a blank check. You start on the free tier, traffic spikes, and suddenly the bill has a comma in it. The alternative — a raw VPS, SSH, and a prayer — costs you the weekend instead of the money. Nginx vhosts, certbot renewals that silently fail, a deploy script nobody wants to touch.

That gap is the whole reason Coolify exists, and it's why the project has quietly turned into the default answer for "I want Heroku, but on my server."

As of today the repo sits at 60,298 GitHub stars and ships hundreds of one-click services. Version 4 has been the stable line for a while now. It is no longer a hobby project you're brave for running — it's infrastructure with a bus factor above one.

I run production workloads on it. This post is what I'd tell you over coffee: what the numbers mean, where Coolify genuinely wins, and which of its marketing-adjacent claims you should quietly ignore.

What 60k stars actually signals

Stars are a vanity metric right up until they aren't. What the curve tells you here is not "Coolify is good software" — it's that a critical mass of developers decided sovereign infrastructure was worth the tradeoff.

The reasoning is boring and correct. A managed PaaS owns your build pipeline, your runtime, your egress pricing, and your migration path. When any one of those changes, you refactor on their timeline. Heroku killing free dynos taught a generation of developers that "managed" means "someone else decides."

Self-hosting used to mean giving up the good parts — git-push deploys, automatic TLS, a dashboard your teammate can read. Coolify's actual contribution is that it kept those and dropped the rent.

Practically, a mature project means the things that bite you at 2am are handled by someone other than you: proxy config, certificate renewal, container lifecycle, backup scheduling. That's the product.

Docker containerization is the whole engine

Underneath the dashboard, Coolify is an orchestrator for Docker. Every app, database, and service you deploy is a container. Your local environment and your production server run the same image, which is the entire point.

When you push to your repo, Coolify pulls the code, builds an image, and starts the replacement container. Build sources are flexible: a Dockerfile if you have one, a docker-compose.yaml for multi-service stacks, static output for a plain frontend, or Nixpacks when you want zero config and can live with its opinions.

What containerization buys you here:

Isolation. One app OOM-ing doesn't take the box down with it.
Portability. Moving from the cheapest droplet your provider sells to a dedicated Hetzner box is a server swap, not a migration project.
Resource control. Per-container CPU and memory limits, set in the UI, enforced by Docker.
Reproducibility. The image that passed staging is the image that runs in production.

If you're weighing this against a full orchestrator, my breakdown of Docker vs Kubernetes covers where the line actually sits — and it's further out than most teams assume. Kubernetes earns its complexity somewhere north of "a dozen services and a platform team." Below that, Coolify's model is strictly less work for the same outcome.

For the ground-floor version of this setup, I wrote it up in Coolify and Docker for SaaS hosting.

What the one-click service catalog actually contains

This is the part people underrate. The service catalog is not a gimmick — it's the difference between "I'll set up Plausible this weekend" and "Plausible is running, next task."

Worth splitting into two things that get conflated. Databases are first-class resources, not templates — eight of them: PostgreSQL, MySQL, MariaDB, MongoDB, Redis, DragonFly, KeyDB, and ClickHouse. They get their own connection UI, their own lifecycle, and — for the SQL and document stores — their own backup scheduling.

Everything else is a compose template, and that's where the breadth lives:

Dev tools: Gitea, Hoppscotch, n8n, Uptime Kuma.
Analytics: Plausible, Umami, PostHog.
CMS and app platforms: Ghost, Strapi, Directus, WordPress, Appwrite, Supabase.
AI infrastructure: Qdrant and other vector stores for RAG workloads.

Each template ships with sane defaults, networking, volume mounts, and generated secrets. You get a running service and a URL.

The "280+" figure is Coolify's own tagline and it undersells the current state — the repo's templates/compose directory holds 362 of them today. Worth knowing, though, that catalog size is no longer a moat: Dokploy ships 514 blueprints and CapRover has 354 one-click apps. Everyone in this space has enough templates.

Two caveats worth stating plainly. First, a one-click template is a starting point — it is not tuned for your load, and the defaults are chosen to boot cleanly, not to survive traffic. Second, templates are community-maintained; pin your image tags rather than riding latest into a breaking upgrade.

Coolify vs the alternatives, on real numbers

The self-hosted PaaS space stopped being a one-horse race. Here's where the four main projects actually stand today:

Feature	Coolify	Dokploy	CapRover	Dokku
Interface	Web dashboard	Web dashboard	Web UI	CLI-first
Multi-server	Native + Swarm	Native + Swarm	Docker Swarm	Via plugins
Service catalog	362 templates	514 blueprints	354 one-click apps	Plugin-based
Build sources	Dockerfile / Compose / Nixpacks / static	Dockerfile / Compose / Nixpacks / Railpack / Heroku + Paketo buildpacks	Dockerfile / captain-definition	Herokuish buildpacks / Dockerfile
Backups	S3-compatible, scheduled	S3-compatible	Manual / scripted	Plugin-based
GitHub stars	60.3k	36.5k	15.1k	32.1k

A few honest reads on that table.

Dokploy is the real competitor now, not a footnote — 36k stars and climbing fast, with a template catalog that has quietly grown larger than Coolify's and a wider set of build sources (Railpack and Paketo on top of the usual Nixpacks and Dockerfile). It's leaner and the UI is arguably cleaner. If you're starting fresh in 2026 it deserves a genuine evaluation rather than a dismissal. Coolify's remaining edge is time in production: more people have hit more edge cases, and those fixes are already merged.

Dokku has the smallest resource footprint of the four and the most Unix-native design. If you're comfortable in a terminal and want something that will still work identically in five years, it's a defensible choice. The CLI-first model is a real barrier for teams where not everyone deploys.

CapRover is the oldest of the four and still actively maintained — it committed as recently as this week. It's Swarm-native by design, which is a genuine advantage if clustering is your starting requirement rather than an afterthought. Its ceiling is the smaller community: fewer people hitting problems means fewer problems already solved for you.

What multi-server actually means

Coolify supports three topologies: a single server, multiple standalone servers managed from one dashboard, and Docker Swarm clusters.

The middle one is what most teams want, and it's worth being precise about what it is. Adding a second server means Coolify SSHes into it and manages Docker there. Each server runs its own containers and its own proxy. It is not a cluster — there's no automatic failover, no scheduler moving workloads between nodes. If a server dies, the apps on it are down until you redeploy elsewhere.

That's a feature, not a gap. It's the model that fits the 95% case: put the database on a high-memory box, the app on a high-CPU box, keep the Coolify instance itself on a small separate server so a runaway build can't take down your control plane. If you need true clustering, that's what the Swarm mode is for — and if you need more than Swarm, you're in Kubernetes territory.

I go deeper on the topology decisions, dedicated build servers, and zero-downtime rollouts in scaling SaaS with Coolify.

Security: what's real and what isn't

This is where I'll break with the usual Coolify writeup, because there's a claim floating around that Coolify handles your firewall for you. It does not, and believing it will hurt you.

Here's what Coolify actually gives you:

Automatic TLS. Let's Encrypt issuance and renewal for custom domains, handled by the bundled proxy — Traefik by default, Caddy still marked experimental.
Encrypted secrets. Environment variable values are stored with Laravel's encrypted cast, so they're not sitting in the database as plaintext. Scopes go per-resource, with shared variables at the environment, project, and team level, and separate build-time and runtime visibility.
Team roles. owner, admin, and member per team, so a contractor doesn't get production database access.
Scheduled backups. Postgres gets first-class scheduled dumps (Coolify backs up its own database the same way); MySQL, MariaDB, and MongoDB are covered too. Destination is local disk or any S3-compatible bucket — Backblaze B2 and Cloudflare R2 both work and cost almost nothing.

And here's the part nobody says out loud: Docker publishes ports by writing NAT rules that bypass UFW. If you ufw deny 5432 and then map Postgres to the host, that port is open to the internet and ufw status will happily tell you it's blocked. This is Docker behavior, not a Coolify bug, but the consequence lands on you either way.

The fix is to filter at a layer Docker can't route around:

Use your provider's firewall. Hetzner Cloud Firewall, DigitalOcean Cloud Firewall, AWS security groups — these sit outside the host, so Docker's iptables rules are irrelevant.
Don't publish database ports at all. Databases should be reachable over the internal Docker network by container name. Coolify defaults to this; the risk is you enabling public access "just for a migration" and forgetting.
Close the dashboard ports. Coolify needs 8000, 6001, and 6002 during setup. Once you've put the dashboard behind a domain and its own TLS, those can be closed. Leave 22, 80, and 443.

Do those three and your self-hosted setup is meaningfully harder to reach than most managed deployments, because there's less surface exposed to begin with.

The actual argument: vendor independence

Strip away the features and the case for Coolify is one sentence: you stop renting your deployment pipeline.

The math is not subtle. Ten small projects on a managed platform — a few hobby-tier databases, some build minutes, a bit of bandwidth — lands somewhere around $150–250/month once you're past free tiers. The same ten projects fit on a single mid-tier VPS with 8 vCPU and 16 GB of RAM, with headroom to spare. On Hetzner that's a low-double-digit euro bill on the ARM line, roughly double on x86. Either way it's an order of magnitude, not a percentage.

The catch, stated fairly: you are now the on-call engineer. Kernel updates, disk space, a container that wedges at 3am — that's yours. Coolify reduces that work by maybe 90%, not 100%. For a solo developer or a small team, the trade is usually worth it. For a company where an hour of downtime costs more than a year of managed hosting, it isn't, and you should pay the tax.

I made this exact switch and wrote up the numbers in why I'm ditching expensive cloud providers. The runway extension was the point; the control turned out to matter more.

How I'd approach the migration

If you're considering the move, the order matters more than the tooling:

Price it honestly. Add up your current managed spend including bandwidth and build minutes, then compare against a VPS with 2x the resources you think you need. If the gap isn't at least 3x, the operational burden probably isn't worth it.
Start with something you can afford to break. Staging environments, internal dashboards, side projects. Learn the failure modes on workloads where the blast radius is you.
Get containerized first. If your app already builds from a Dockerfile, migration is an afternoon. If it doesn't, fix that before you touch Coolify — you'll be debugging one thing instead of two.
Wire up S3 backups on day one. Before the first production workload lands. A single server with no offsite backup is a countdown, not an architecture.
Put the control plane on its own box. Coolify's documented minimum is 2 cores, 2 GB of RAM, and 30 GB of disk — the cheapest tier most providers sell. A dedicated instance means a runaway build can never take down the dashboard you'd use to fix it.
Add external monitoring. Coolify tells you a container is running. It does not tell you your users can check out. Uptime Kuma (one-click, naturally) or Better Stack closes that gap.

Coolify's real achievement is that it made the PaaS experience a commodity. The dashboard, the git integration, the automatic TLS — these were competitive moats five years ago. Now they're a curl | bash away, and the only thing you're paying a managed provider for is not thinking about servers.

That's a legitimate thing to pay for. It just isn't worth a 10x premium anymore.

What's still keeping you on managed hosting — the operational load, or the fear of being the one holding the pager? Tell me, I'm genuinely curious which one it is.

AI coding is like an addiction (in the best way)

Sat, 01 Aug 2026 00:00:00 GMT

AI coding is strangely addictive. You start with a single prompt to fix a regex or center a div. You tell yourself it's a one-time thing to save ten minutes. Then you watch it refactor an entire Laravel controller in seconds. Suddenly you're asking it to write your unit tests. Before long you're building custom agents that manage a Shopify store over GraphQL.

The shift happens slowly at first. Then all at once.

The problem it solves for most of us isn't typing speed — it's blank-page fatigue. Staring at a legacy codebase or a fresh architecture doc feels like a mountain of manual labor. You burn hours on boilerplate instead of business logic. That friction is where motivation goes to die.

And the cost of not evolving compounds. Coding without AI in 2026 feels like writing a book with a quill while everyone else runs a word processor. It isn't only speed — it's cognitive load. Energy spent on syntax and API nuance is energy not spent on architecture and strategy.

The answer isn't "use AI." It's building a structured AI coding workflow — moving from passive user to engineer who orchestrates systems. Once you've felt a multi-agent loop close on its own, there's no going back.

Level 1–5: the gateway prompts

Almost everyone starts here. You treat the model like an interactive Stack Overflow. Paste a snippet, ask for a fix, move on.

At Level 1 you're generating small functions and boilerplate. At Level 5 you're debugging — instead of manually scanning logs, you drop a stack trace into a chat and get a diagnosis. That alone saves real hours.

But you're still stuck in the copy-paste loop. You write the code. The AI patches the errors. It's a helpful assistant that has no idea what you're building.

The trap at this level is letting the model freestyle without context. Escaping it means writing specs instead of wishes. You stop saying "fix this" and start saying:

"Refactor this Laravel service to follow the Repository pattern, keep the existing public method signatures, and make sure database exceptions surface as domain exceptions."

Same model. Completely different output.

Level 10–20: building context

At this stage you realize the model is only as good as the information it can see. Isolated chat windows stop being enough. You start using tools that read your whole codebase — the point where the AI vs traditional development question stops being philosophical and turns into a workflow decision.

Level 10 is tests. Writing unit tests is usually the chore you postpone; AI turns it into leverage. A full Pest or PHPUnit suite for a Laravel feature drops in seconds. You're not just producing code anymore — you're producing a safety net that lets the agents at higher levels move fast without wrecking things.

Level 20 is when the AI actually knows your codebase. Codebase indexing, embeddings, RAG. The model retrieves the three files that matter instead of guessing from the file tree. Many teams go further and stand up a local pgvector database holding internal docs, ADRs, and runbooks — the same retrieval discipline behind the 7 mistakes wrecking your production RAG stack.

The payoff is that you stop re-explaining your architecture in every session. Your event-driven layer, your custom service container bindings, your weird legacy billing table — the agent looks it up.

Level 50+: the agentic shift

This is where the addiction matures into an engineering practice. You're no longer chatting with a model. You're building systems that act on your behalf.

Level 50 is the Model Context Protocol. MCP lets agents connect to real tools — the Shopify Admin GraphQL API, your database, your cloud infrastructure. It's the same plumbing behind agentic commerce on Shopify, pointed at your own workflow instead of at a shopper. An agent can watch incoming orders and adjust inventory according to rules you described in plain language, because it holds an actual connection instead of a description of one.

The Level 50 loop I actually run looks like this:

Plan. You write a technical spec in markdown — scope, constraints, acceptance criteria.
Execute. An agent reads the spec and generates the Laravel migrations, models, and controllers.
Verify. A separate agent writes tests and runs them until they pass.
Deploy. A deployment agent ships to a Coolify instance and tails the logs for errors.

You become the conductor. You own the what and the why; the agents grind through the how.

The separation in step 3 matters more than it looks. An agent that writes both the implementation and its tests will happily write tests that pass against its own bug. Two agents with different context catch what one agent rationalizes away — which is why I stopped reading diffs line by line and moved to a multi-agent review pipeline, and why AI-generated code still needs its own test discipline.

Why manual coding feels slow now

Once you've run an agentic workflow, the friction of manual coding becomes physically annoying. Five-minute tasks feel like an eternity. Hunting the correct GraphQL mutation shape for a Shopify app feels absurd when an agent with schema access resolves it in two seconds.

The addiction isn't to the tool. It's to flow. AI removes the micro-frictions that shatter concentration — the doc lookup, the typo, the forgotten import, the "wait, what's this method called again." You stay in a high-level creative state for longer stretches, so you solve bigger problems.

It also quietly redefines what senior means. Not knowing every syntax detail from memory. Knowing how to decompose a system, and how to steer an AI into building it correctly. Builder to architect.

Practical steps to level up

You don't drift into Level 50. You have to build the infrastructure for it.

1. Master MCP

Start with custom MCP servers for the tasks you repeat weekly. If you work on Shopify apps, expose a tool that queries your store's Admin GraphQL API directly, and another that validates a mutation against the current schema version. That single step kills most of the copy-paste in your day. Keep the surface small — every extra tool is context tax and one more thing the agent can misuse.

2. Implement RAG over your codebase

Don't rely on general knowledge for project-specific questions. Index your project. If you're running a Laravel SaaS, make sure the agent can retrieve your service-layer conventions and your event contracts, not just guess from app/. Storing documentation embeddings in pgvector is the cheapest long-term memory you'll ever buy — and it lives in the Postgres you already run.

3. Use multi-agent orchestration

Stop thinking about one AI and start thinking about a team. Planner, implementer, reviewer. Separation of concerns produces better code and fewer hallucinations, for the same reason it does with humans: the reviewer isn't emotionally invested in the plan.

4. Optimize for Shopify GraphQL

Shopify has moved on from REST for new development. Make sure your agents target the current GraphQL Admin API version and don't reach for deprecated fields they memorized from a 2023 blog post. Pin the API version explicitly in your prompts and your client — schema drift is the single most common source of confidently wrong Shopify code.

// Example of a Laravel service using a Shopify GraphQL mutation.
// An agent writes the boilerplate; your spec dictates the contract.
public function updateProductInventory(string $inventoryItemId, int $newQuantity)
{
    $mutation = <<<'GRAPHQL'
    mutation inventorySetQuantities(
      $input: InventorySetQuantitiesInput!
      $idempotencyKey: String!
    ) {
      inventorySetQuantities(input: $input) @idempotent(key: $idempotencyKey) {
        inventoryAdjustmentGroup {
          createdAt
          reason
          changes {
            name
            delta
            quantityAfterChange
          }
        }
        userErrors {
          code
          field
          message
        }
      }
    }
    GRAPHQL;

    $variables = [
        'idempotencyKey' => (string) \Illuminate\Support\Str::uuid(),
        'input' => [
            'name' => 'available',
            'reason' => 'correction',
            'ignoreCompareQuantity' => true,
            'quantities' => [
                [
                    'inventoryItemId' => $inventoryItemId,
                    'locationId' => config('shopify.default_location_id'),
                    'quantity' => $newQuantity,
                ],
            ],
        ],
    ];

    return $this->shopifyClient->query($mutation, $variables);
}

Two details in there are exactly the kind of thing schema drift breaks.

The @idempotent directive arrived as optional in API version 2026-01 and became required in 2026-04. Any agent working from a 2024 blog post will emit this mutation without it and get rejected outright. Worse, a model that half-remembers the shape will reach for inventorySetQuantity — singular — which isn't a mutation in the current schema at all.

And note userErrors. Shopify returns a 200 with a populated userErrors array for most business-rule failures, so an agent that only checks HTTP status will report success on a write that silently did nothing. Bake both rules into your spec once and every generated mutation inherits them.

Takeaways

Start small, aim high. Level 1 prompts are a doorway, not a destination. The value lives in the loops.
Context is king. RAG and pgvector give the model specific knowledge of your codebase and business rules instead of internet averages.
Embrace MCP. Real tool connections — Shopify GraphQL, your database, your infrastructure — beat pasted screenshots every time.
Split the agents. Whoever writes the code should not be the only one grading it.
Standardize the loop. Plan, execute, verify, deploy. The structure is what keeps quality from collapsing as speed goes up.
Focus on architecture. As implementation gets cheap, your value moves to design, constraints, and judgment.

The hardest part of AI coding isn't the learning curve. It's realizing you can't go back. You've tasted a different level of efficiency and the old way now looks like manual labor.

This isn't about replacing yourself. It's about amplifying yourself until you're doing the work of a team.

How are you structuring your AI coding workflow beyond simple chat prompts? Get in touch — I'm always up for comparing agent stacks.

Stop reading every line of AI-generated code

Thu, 30 Jul 2026 00:00:00 GMT

Nobody wants to read a 5,000-line diff. But that is what lands in the pull request when an agent spends an afternoon refactoring a legacy service or scaffolding a new Laravel module end to end.

The failure mode that follows is worth naming precisely, because it does not look like failure while it is happening. An agent scaffolds a multi-tenant module in one pass — migrations, models, policies, jobs, tests. The diff is correct, mostly. You spend two evenings reading it line by line and approve it. Weeks later something breaks in production: a queued job that ran outside the tenant scope. You read that file. You read that exact method. Your eyes went over it and your brain filed it as "looks like the other ones."

It feels like diligence. It is theater.

Where line-by-line review actually breaks

Code review guidance has been consistent for two decades: reviewers find defects reliably in chunks of roughly 200 to 400 lines, and effectiveness drops sharply past that. Nothing about that number has changed because we bolted an LLM onto the front of the process. Human attention is the constant. The volume of code is the variable, and it just went up by an order of magnitude.

Three things go wrong when you push past that limit:

You review syntax, not semantics. Naming, formatting, and shape are cheap to evaluate, so tired brains drift toward them. A perfectly formatted diff can still ship an N+1 query, a missing index, or a broken state machine.
You lose the cross-file thread. The bug is almost never in the file you are reading. It is in the interaction between the job, the observer, and the tenant scope — three files you looked at twenty minutes apart.
You pattern-match against yourself. Agent-generated code is internally consistent. That consistency reads as correctness. Every file looks like the last one, so your reviewer instinct stops firing.

None of this is new. What changed is that we used to write code slowly enough that review capacity roughly matched output. That coupling is gone. Generation scales with tokens; reading scales with eyeballs.

What agents genuinely do better — and what they don't

A review agent pointed at a repository does not read files the way you do. Given the right tooling it walks the AST, follows call graphs, and traces a value from a controller through a service into a model and out to an external API. It does that for file forty with the same attention it gave file one.

That is the real advantage: breadth and consistency, not intelligence. An agent will happily check all 340 controller actions for a missing authorization call. You will check the twelve you remember.

I want to be equally clear about the other side, because "agents review better than humans" is a bad summary of what I actually believe:

Agents hallucinate findings. They will confidently flag a race condition that cannot occur, and the fix they suggest can be worse than the code.
Agents have no idea whether the feature should exist. Product intent is not in the diff.
Agents are weak on the thing that only shows up at runtime under load — the query that is fine with 200 rows and fatal with 2 million.
An agent reviewing code written by the same model family shares its blind spots.

So the move is not "trust the agent instead of your eyes." It is: give the agent the work that scales with volume, and keep for yourself the work that scales with judgment. That split is the same one I drew in AI vs traditional development — the boundary moved, it did not disappear.

Dimension	Human line-by-line review	Agentic verification
Effective scope	A few hundred lines before quality drops	Whole repository, via AST and call-graph traversal
Consistency	Degrades with fatigue and diff size	Same checks applied to file 1 and file 400
Typical focus	Style, naming, local logic	Invariants, contracts, types, test outcomes
Failure mode	Misses cross-file interactions, rubber-stamps	Confident false positives, misses product intent
Cycle time	Hours to days	Minutes, on every push

The shift: own the spec, not the syntax

If you are not reading the code, something else has to hold the line. For me that is the specification layer — and writing it is now the highest-leverage thing I do on an agent-assisted project.

Concretely, that means:

Executable acceptance criteria. Not a Notion doc. Feature tests that fail before the agent starts and pass when it is done.
Property-based tests for anything with arithmetic or state. Pricing, proration, inventory, refunds. Instead of three examples, assert the invariant: a refund never exceeds the captured amount, total allocated inventory never exceeds stock on hand.
Contract tests at every boundary. Webhook payloads, third-party API responses, queue message shapes. This is where agent code fails quietly, because the happy path is the only path in the training data.
Machine-checkable rules for the things I keep repeating. Static analysis at a strict level, an architecture-test suite asserting "no job may run without a tenant context," a lint rule for direct DB access outside repositories.

That last one is the real trick. Every review comment I would type twice becomes a rule instead. If the agent can violate an invariant and the pipeline stays green, that is my bug, not the agent's. The numbers behind why this layer is non-negotiable — and the CI configuration I run — are in test AI code too.

When a check fails, I do not hand-patch the file. I fix the prompt, tighten the spec, or add the missing rule, then re-run. That loop is the practical core of agentic workflows, and it only works if the feedback the agent receives is precise. Vague context produces vague code — the point I made in prompt engineering vs context engineering.

A multi-agent review pipeline that earns its cost

One giant "review this PR" prompt produces mush. Narrow agents with narrow briefs produce findings you can act on. This is the verify stage of the plan, execute, verify, deploy loop, and it deserves its own agents for the same reason it deserves its own step. The setup I run now has three, and they all execute inside CI rather than in my editor:

Correctness. Runs the suite, static analysis, and the architecture tests. Then reviews the diff strictly against the written acceptance criteria — its brief explicitly forbids style commentary. Output: does this satisfy the spec, and where does it not.
Security. Injection paths, authorization gaps on new routes, secrets in config, unsafe deserialization, mass-assignment on new models, anything touching a webhook signature. This one gets the OWASP-shaped checklist and nothing else.
Regression. Diffs behavior against the previous stable build. It reads the migration files, flags schema changes without a rollback path, hunts for queries added to hot code paths, and cross-references the touched files against past incident history.

Each agent needs real access to be useful — the schema, the logs, the actual test output, not a pasted snippet. That is exactly the problem MCP servers solve, and it is the difference between a reviewer that guesses and one that checks.

Two rules keep this from becoming noise. First, findings are severity-ranked and anything below "would break in production" goes to a comment, never a block. Second, a second agent tries to refute each finding before I see it. A large share of the initial findings die there, and they are exactly the ones that would otherwise burn an afternoon.

The loop

The pipeline is only worth building if it closes without me in the middle of it:

[Spec + tests] --> [Agent generates] --> [Static analysis + type checks]
                          ^                          |
                          |                          v
                   [Self-correction] <-- [Test suite + review agents]
                          |
                          v (all green)
                   [Human: seams review] --> [Merge / deploy]

Failures feed back into the agent's context automatically. I only see the branch once it is green, which is the same discipline that makes CI and CD work in the first place — the pipeline is the gate, not the reviewer's inbox.

What I still read myself

"Stop reading code" is a slogan, and taken literally it is wrong. Here is my actual list of things I open every time, no matter how green the pipeline is:

Migrations. Anything irreversible or lock-heavy on a large table.
Auth and permission boundaries. Policies, scopes, middleware, anything that decides who sees what.
Money paths. Charges, refunds, discounts, tax, billing webhooks. Tests are necessary here and not sufficient.
New architectural seams. A new queue, a new external dependency, a new cache layer. The code may be fine; the decision may not be.
Anything the agent changed that nobody asked it to change. Unrequested scope is the loudest smell in agent diffs.

That list is maybe 3% of a large diff. Reading 3% carefully beats skimming 100%, and it is the part where my decade of production scars actually transfers. The rest — the 340 controller actions, the DTO fields, the test scaffolding — is machine work, and I stopped pretending otherwise.

Takeaways

Line-by-line review does not scale to agent-sized diffs. Past a few hundred lines you are performing diligence, not doing it.
Use agents for breadth, not judgment. Cross-file tracing and repeated checks are their edge; product intent and architectural taste are not.
Convert review comments into rules. Anything you would say twice belongs in a test, a static-analysis level, or an architecture test.
Split the review agent into narrow briefs — correctness, security, regression — and make a second pass try to refute each finding before it reaches you.
Keep a short human read list: migrations, auth, money, new seams, unrequested changes.

The uncomfortable question is what your team's review process is actually for. If it exists to catch defects, most of it should be automated by now. If it exists to spread knowledge, say that out loud and redesign it around that goal instead.

Where does your review process still depend on someone reading every line — and what would it take to turn that into a check? Tell me via contact, I collect these. 🤘

Vibe coding vs agentic engineering: which ships?

Fri, 24 Jul 2026 00:00:00 GMT

The era of manual syntax is over. In 2026 the question is no longer whether AI writes your code — it's how you govern the AI that does. Most developers I talk to are caught between two modes: the high-speed thrill of vibe coding and the slower discipline of agentic engineering.

Both are real. Both work. But they don't work for the same job. Vibe coding will conjure a working application in an afternoon. Agentic engineering is what makes that application survive contact with production. Shipping in 2026 means knowing which one you're in at any given moment — and stopping the vibes before they reach main.

The rise and fall of vibe coding

Vibe coding was the breakout habit of 2025. It's a conversational approach where the feel of the interaction takes precedence over the underlying architecture. You describe a feature, the model returns a large block of code, you run it to see whether it works. It breaks, you paste the stack trace back, you ask for a fix. Repeat.

That cycle is fast. It's addictive. It feels like magic right up until you try to scale a system built entirely on vibes.

The real problem isn't the code quality — models are good now. The problem is that vibe coding is development without verification. When the model hands you 500 lines and you ship because it looks right, you're operating on faith. You've moved the bottleneck from typing to reviewing, and then you skipped the reviewing.

None of that makes it useless. The first pass of a Shopify storefront section or a Laravel reporting dashboard can come together in an afternoon this way. The trouble shows up six weeks later: no tests, three competing patterns for the same problem, and a Controller doing the job of a service, a job, and a repository. That's not a code problem, it's a process problem — and it's the same failure mode I wrote about in why projects need more than just logic.

Agentic engineering: the architecture of intent

Agentic engineering is the professional evolution of the same tooling. It isn't chatting with a single model. It's running a system of agents that plan, implement, test, and review under your supervision. Your role changes from coder to architect of intent.

In an agentic workflow you supply a specification, not a vibe: the requirement, the architectural constraints, the acceptance criteria. The system decomposes it. One agent researches the API surface. One writes the implementation. One writes the tests. One reads the diff looking for reasons to reject it.

The spec is the whole trick, and it's usually shorter than people expect:

## Task: subscription pause endpoint

Constraints

- Laravel 12, existing `SubscriptionService`, no new packages
- Idempotent: repeat calls with the same `Idempotency-Key` return the first result
- Authorization via existing `SubscriptionPolicy@pause`

Done when

- Feature test: pause, double-pause, unauthorized, already-cancelled
- No changes to `routes/api.php` ordering
- `php artisan test` and `vendor/bin/pint --test` both green

You're no longer reviewing lines — a habit that stops scaling at agent-sized diffs. You're reviewing a pull request that other agents already argued about. The human decision shrinks to go/no-go — which is exactly where a human decision is worth the most. That's the architecture side of it, and I go deeper into the MCP and loop mechanics in the shift to agentic workflows.

Side by side: vibe coding vs agentic engineering

Most AI-assisted projects that stall share one root cause: vibe coding applied to a problem that needed agentic engineering.

Dimension	Vibe coding	Agentic engineering
Primary goal	Speed and exploration	Correctness and scale
Your role	Conversational partner	Architect, mission control
Verification	"Does it seem to work?"	Automated tests plus peer-agent diff review
Structure	Loose, improvised	Written specs, repeatable SOPs
Best for	Prototypes, spikes, one-offs	Production SaaS, Shopify Plus apps
Tech debt	High and invisible	Managed and visible
Failure mode	Silent wrongness	Slow starts, over-specification

Note the last row. Agentic engineering has its own failure mode: you can spend an hour writing a spec for something you could have vibed in ten minutes and thrown away. Discipline applied to a throwaway prototype is just waste with better manners.

The hybrid workflow: mornings vibe, afternoons engineer

The people shipping fastest in 2026 don't pick a side. They split the day. Creative exploration in the high-energy hours, engineering rigor in the disciplined ones. If you want the rung-by-rung version of how a workflow gets there, I mapped the levels from gateway prompts to agentic systems separately.

Morning: the vibe

Start with exploration. If I'm adding a RAG-backed feature, I don't open a spec document — I open the editor and vibe out the retrieval logic. Try pgvector, try a hosted index, see how the chunking feels against real documents. Wire Claude and MCP into the local environment and let it poke at the database directly.

The output of the morning is not code you keep. It's a decision you keep. Nothing from this session is allowed to merge.

Afternoon: the rigor

Once the shape is proven, the vibes end. The prototype becomes the input to a spec: schema, API contract, error semantics, test coverage. Then the agents refactor that morning code into something documented and tested, and a review agent tries to break it.

The hard rule that makes this work: the morning branch never merges. It gets read, summarized into a spec, and deleted. If you let vibe-coded code merge "just this once," you've quietly reverted to mode one — and today's speed becomes next month's outage.

Building the agentic stack on Laravel and Shopify Plus

Agents need predictable ground to stand on. My stack is Laravel for application logic and Shopify Plus when the surface is commerce, and that's not nostalgia — it's because both are legible to a model.

Laravel's conventions are the point. Service providers, policies, form requests, and a canonical directory layout mean an agent can answer "where does this belong?" without guessing. Shopify's GraphQL Admin API is similarly self-describing: typed, introspectable, versioned. An agent can discover the mutation it needs instead of hallucinating a REST route that was deprecated two versions ago. That predictability is most of what makes agentic commerce on Shopify tractable.

The other half is memory. Your agents need your codebase, your ADRs, and your incident history — otherwise every session starts from zero and you re-litigate decisions you settled in March. A vector store over your own repository and docs is the cheapest leverage in the stack, provided the retrieval layer is honest. Garbage context produces confident garbage code, which is exactly the failure pattern behind most RAG mistakes in production.

Deploying with confidence

The last place vibes leak into production is the deploy. If a human is manually clicking ship after an agent wrote the change, the human is the weakest link — they're approving a diff they didn't write against tests they didn't read.

Push the verification into the pipeline instead: migrations checked, feature tests green, a smoke pass against a preview environment, error rate watched for a window after rollout, automatic rollback if it moves. Docker plus Coolify gets you this on your own boxes without a platform bill, which is the whole premise of self-hosting your SaaS.

The goal isn't zero human involvement. It's that a bad vibe can't reach customers without something automated objecting first.

Takeaways

Vibe coding is a discovery tool. Use it for prototypes, UI spikes, and messy ideas — then throw the code away and keep the decision.
Agentic engineering is a production tool. Specs, tests, and multi-agent review are what make AI-written code safe to charge money for.
The skill that matters in 2026 is writing unambiguous specs. It's the new senior-engineer bottleneck, and it's a writing skill more than a coding one.
Give your agents memory. Vector-indexed code, docs, and incident history stop every session from restarting at zero.
Split your day, and enforce the boundary. The morning branch does not merge.
Watch the opposite failure too: over-specifying a throwaway spike is waste, not discipline.

Which part of your workflow is still running on vibes alone — and what would an agent find if it audited that code tomorrow? If you're trying to get an AI-assisted team from prototypes to production, here's how I help.

Modular monoliths first: why microservices can wait

Wed, 24 Jun 2026 00:00:00 GMT

Distributed systems are the most expensive way to solve a problem you do not have yet.

Every year a new batch of SaaS founders jumps straight to microservices because they want to "build for scale." Six months later they are debugging network latency and distributed transactions instead of shipping features. The product has not moved. The infrastructure bill has.

The modular monolith has quietly won this argument. It gives you the logical separation you actually need without the operational tax of a distributed environment. This post covers why you should start there, how to structure it so it stays modular, and the specific signals that tell you it is finally time to split.

If you are still weighing the two patterns at a high level, read monolith vs microservices first. This post assumes you have picked the monolith and want to build one that does not rot.

The microservice tax is real

Most startups choose microservices for the wrong reasons. They look at Netflix or Uber and assume the infrastructure is the blueprint for success. What they miss is that those companies adopted microservices to solve organizational problems — hundreds of engineers who could not coordinate a single deploy — not purely technical ones.

Split prematurely and you pay a heavy tax:

Operational overhead. You now need service discovery, centralized logging, distributed tracing, and a CI/CD pipeline per repository. None of that ships a feature.
Data consistency. Distributed transactions are hard. You end up with eventual consistency problems that need sagas or an outbox pattern to fix — code that exists only because you split.
Network latency. Every cross-service call costs milliseconds and can fail. In a monolith these are function calls in memory that cannot time out.
Developer friction. Debugging a request that hops through five services is far worse than stepping through one process. Reproducing it locally is worse still.

For a small team this overhead kills velocity. You spend 40% of your time on infrastructure and 60% on product. In a modular monolith that ratio flips back toward the thing customers pay for.

What a modular monolith actually is

A modular monolith is not a big ball of mud with nicer folder names. It is a single deployable unit where code is strictly organized into independent modules with well-defined interfaces between them.

In a Laravel codebase that means each domain gets its own namespace, its own service provider, its own routes, and its own migrations. A Billing module never reaches into the Users tables directly. It talks through a contract.

// app/Modules/Billing/Contracts/CustomerDirectory.php
namespace App\Modules\Billing\Contracts;

interface CustomerDirectory
{
    public function find(int $customerId): ?CustomerSummary;
}

// app/Modules/Users/Adapters/EloquentCustomerDirectory.php
namespace App\Modules\Users\Adapters;

use App\Modules\Billing\Contracts\CustomerDirectory;
use App\Modules\Billing\Contracts\CustomerSummary;
use App\Modules\Users\Models\User;

final class EloquentCustomerDirectory implements CustomerDirectory
{
    public function find(int $customerId): ?CustomerSummary
    {
        $user = User::query()->find($customerId);

        return $user
            ? new CustomerSummary($user->id, $user->email, $user->billing_country)
            : null;
    }
}

Billing depends on an interface it owns and a DTO it controls. Users supplies the implementation. Swap that adapter for an HTTP client tomorrow and Billing does not change a single line. That is the whole trick: the seam already exists, you just move what is behind it.

The goal is logical separation with physical unity. You get a clean, decoupled architecture without managing a fleet of containers on Coolify or Kubernetes before you need to.

Bounded contexts keep the modules honest

The concept doing the real work here is the bounded context — a term from Domain-Driven Design that marks the boundary where one model of a thing applies.

A Product in the Inventory module is not the same object as a Product in the Marketing module. One cares about stock levels, SKUs, and warehouse locations. The other cares about SEO titles, hero images, and merchandising rules. Forcing them into one bloated Product model is how modular monoliths turn into mud.

Three rules keep boundaries intact:

Enforce them mechanically. Human discipline fails under deadline. Add an architecture test that fails the build when Modules\Billing imports Modules\Inventory\Models. In PHP, Deptrac or a Pest arch test does this in a few lines. Any language has an equivalent.
Keep the shared kernel tiny. A little shared code is fine. A giant Common package that every module depends on is a monolith wearing a costume — you can never split anything out of it.
Prefer events over direct calls. When Orders needs Shipping to react, emit a domain event instead of calling a method. Replacing an in-process listener with a message queue later becomes a config change, not a rewrite.

That third rule is the highest-leverage one. Internal events are the cheapest dress rehearsal for asynchronous communication you will ever get, and they cost nothing while everything still runs in one process.

The data ownership trap

The database is where most monolith-to-microservice migrations die.

If your modules share tables or run JOINs across domains, you are coupled at the data layer — the hardest coupling to break. No amount of tidy namespaces saves you when Reporting joins six tables owned by four other modules.

So aim for schema per module. Use one physical Postgres or MySQL instance for simplicity, but give each module its own tables and treat them as private. In practice:

No foreign keys crossing module boundaries. Store the ID and let the application layer resolve the relationship.
No cross-module JOINs. If Billing needs a customer email, it calls the contract, not the users table.
Read models over reach-ins. If Reporting needs a wide view, have modules publish into a reporting table they explicitly own.

Here is the test: if you cannot imagine running your Orders module against a separate database server tomorrow, your monolith is not modular yet. It is a monolith with folders.

A decision framework for when to split

You rarely outgrow a monolith because of traffic. A single well-tuned Laravel box with Octane and a queue handles more load than most SaaS companies ever see. You outgrow it because of friction. Three signals matter:

1. Team autonomy

Are developers constantly blocking each other? Twenty engineers merging into one codebase with a deployment queue is a real organizational bottleneck, and that alone can justify a split. Five engineers? A monolith is almost always faster. Conway's Law cuts both ways — do not buy a distributed architecture for a co-located team.

2. Divergent scaling profiles

Does one part of the app have radically different resource needs? An AI inference module that wants GPUs while your dashboard is plain CRUD is a genuine case for extraction. You stop paying for GPU-sized instances to serve settings pages, and your DevOps spend tracks actual demand.

3. Fault isolation

If a bug in non-critical reporting takes down checkout, you have a resilience problem. First try to solve it in-process — better error handling, background jobs, timeouts, a bulkhead around the risky call. If it keeps happening, a separate service acts as a circuit breaker around your core revenue path.

Metric	Modular monolith	Microservices
Deployment	Simple (one pipeline)	Complex (many pipelines)
Testing	Easy (in-process)	Hard (end-to-end focused)
Data integrity	Strong (ACID)	Eventual consistency
Debugging	Stack trace	Distributed trace
Operational cost	Low	High
Team scaling	Bottlenecks past ~15–20	Scales with squads

Notice what is missing: raw performance. It is almost never the deciding factor, and when it is, a bigger box or a read replica usually beats a rewrite.

Extract background workers before services

When the split finally makes sense, your first move should not be a full service.

Start with an extracted background worker. Move heavy, long-running tasks — PDF generation, CSV exports, video transcoding, embedding jobs — into their own process consuming from a queue. You get isolation, independent scaling, and blast-radius reduction without the pain of synchronous API contracts, retries, and versioning. RabbitMQ or a Pub/Sub-style event backbone covers most of this, and the same pattern powers queue-based document processing.

Only after that should you consider carving out a synchronous service. When you do, the strangler fig migration is the safe path — route one endpoint at a time and keep the monolith as your fallback.

One more constraint: wait until your domain is stable. Early-stage products change their data models weekly. Hard service boundaries during that discovery phase turn every small feature into a multi-service orchestration project. Boundaries are cheap to move inside a monolith and expensive to move across a network.

Takeaways

Start modular. Separate business domains with namespaces, modules, and contracts from day one — this costs nothing early and is nearly impossible to retrofit later.
Enforce boundaries with tooling. Architecture tests in CI, not code-review vigilance.
Own your data per module. No cross-module foreign keys, no cross-domain JOINs. Data coupling is the coupling that traps you.
Emit events internally. In-process listeners today become queue consumers tomorrow with a config change.
Split on friction, not fashion. Deployment bottlenecks, divergent scaling profiles, and repeat fault cascades are reasons. A conference talk is not.
Extract workers first. Async background processes give you most of the isolation benefits at a fraction of the operational cost.

If your architecture lets you change your mind later without a rewrite, you have already won. That is the whole point of deferring the decision.

How often are you actually checking for cross-module coupling in your codebase? If the answer is "never," that is the cheapest audit you can run this week — and I am happy to look at it with you.

Stateless vs stateful apps: the architecture split

Tue, 23 Jun 2026 00:00:00 GMT

Scaling a web application often feels like trying to upgrade a jet engine while the plane is mid-flight. You start with a single server that handles every request perfectly. But as your traffic grows, you add more servers, and suddenly everything breaks. Users are getting logged out randomly. Shopping carts are disappearing into thin air. The database is screaming under the pressure of redundant session checks. This chaos usually stems from a fundamental architectural decision made in the early stages of development. You are likely struggling with the friction between stateless and stateful design patterns.

If your application relies on the server remembering who a user is based on local memory, you are building a stateful system. This works great for small projects but becomes a nightmare when you need to scale horizontally. On the other hand, moving to a fully stateless model requires a complete rethink of how you handle authentication and data persistence. Understanding the trade-offs between stateless vs stateful apps is not just an academic exercise. It is a prerequisite for building robust, high-performance software in a modern cloud environment.

Defining state in the digital world

Before comparing the two architectures, we must define what "state" actually means in a web context. State is any data that the application needs to remember between different interactions. This could be a user's login status, the items in a Shopify cart, or the progress of a multi-step form.

In a traditional web application, the server manages this state by creating a unique session for every visitor. The server stores a small file or a piece of memory linked to a specific session ID. When the user moves from one page to another, the server looks up that ID and retrieves the state. This makes the application "stateful" because the server's response to a request depends on what happened in previous requests.

The stateless architecture: the forgetful master

A stateless application treats every single HTTP request as a completely new event. The server does not remember anything about the client once the request is finished. A user clicks a button, the server processes the data, sends a response, and immediately forgets that user ever existed.

For this to work, the client must provide all the necessary information with every single request. This is why stateless apps often use JSON Web Tokens (JWT) or API keys. The token contains the user's identity and permissions. When the server receives the token, it validates it, performs the requested action, and sends back the result.

The primary advantage of this approach is horizontal scalability. Since the server does not store any local session data, any server in your cluster can handle any request. You can add ten more servers to your stack using a tool like Coolify or Docker and the load balancer can distribute traffic without worrying about where the user's session is located. This same property is what lets a stateless tier sit cleanly behind an API gateway.

The stateful architecture: the memory expert

Stateful applications are built on the premise of continuity. The server maintains a persistent connection or a session record for every active user. This was the default way of building the web for decades. If you are using Laravel with standard Blade templates and the built-in authentication guard, you are likely running a stateful application.

In a stateful system, the server's internal memory or local disk stores the user's context. This makes development faster and easier for certain features. For example, "flashing" a success message to the next page is trivial in a stateful app. The server just puts the message in the session and reads it on the next load.

However, statefulness introduces a "sticky session" problem. If you have three servers (A, B, and C) and a user's session is stored on Server A, the load balancer must ensure that every subsequent request from that user goes back to Server A. If the user hits Server B, that server will have no record of them, and they will appear logged out. This makes scaling significantly more complex and creates a single point of failure. If Server A crashes, all users "stuck" to it lose their session data.

Stateless vs stateful apps: key differences at a glance

Choosing between these two paths depends on your specific technical requirements. Below is a breakdown of how they compare across critical engineering metrics.

Feature	Stateless Apps	Stateful Apps
Data storage	State is stored on the client or a shared database/cache.	State is stored in the server's memory or local storage.
Scalability	High. Any server can process any request.	Low. Requires sticky sessions or complex synchronization.
Resilience	High. If a server dies, another one takes over instantly.	Moderate. Server failure often leads to session loss.
Complexity	Higher initial setup for token management and external caching.	Lower initial setup for small-scale projects.
Performance	Potential overhead from passing tokens or fetching data from Redis.	Faster local memory access but slower overall scaling.

Practical implementation in Laravel

In the world of PHP development, Laravel gives you the flexibility to choose either path. By default, the web middleware group uses stateful sessions. It stores a session cookie on the browser and matches it to a server-side entry, which since Laravel 11 lands in the database driver out of the box. This is perfect for traditional dashboards where you need simple state management and cookie-based CSRF protection.

To make your Laravel app stateless, you move toward token-based authentication using Laravel Sanctum or Passport. You skip session cookies on your API routes and let every request carry its own bearer token, validating the user against a shared store like Redis or the database. This shift is essential when building backends for mobile apps or complex React/Vue frontends.

This is also where the stateless model pays off as you grow: because no node owns a session, you can lean on horizontal scaling and add capacity behind the load balancer without any session-affinity gymnastics.

Scaling with Shopify and modern e-commerce

Shopify provides an interesting look at how these architectures live together. The Shopify platform itself is a massive distributed system. While the "state" of a store (orders, inventory, customers) is preserved in giant databases, the web tier that handles incoming traffic is designed to be stateless. This allows Shopify to handle massive spikes during Black Friday by spinning up thousands of web workers that don't need to share local memory.

If you are building agentic commerce solutions on Shopify, your app architecture should lean toward statelessness. Your app will receive webhooks and API calls from various Shopify nodes. If your app is stateful and relies on local memory to track a multi-step checkout process, you will likely encounter race conditions or lost data as Shopify's infrastructure scales. Using a shared Redis instance to store temporary job state is the professional way to handle this.

DevOps and deployment considerations

Your choice between stateless vs stateful apps will dictate your DevOps strategy. Stateless apps are the "gold standard" for containerization. Since they have no local dependencies, you can run them in Docker containers and deploy them to any cloud provider without friction. You don't need to worry about preserving the "health" of a specific server instance.

Stateful apps require much more care. If you are deploying a stateful Laravel app, you must ensure that your session driver is set to something central like Redis or a database. Laravel 11 and later default to the database driver, but if you switch it back to file, each node writes sessions to its own disk and your horizontal scaling will fail. You also need to consider how you handle deployments. A "zero-downtime" deployment is harder when you have thousands of active sessions living in server memory. You often have to wait for sessions to drain before taking a node offline.

Takeaways

Stateless apps treat every request as a new event, requiring the client to provide context (tokens) every time.
Stateful apps remember user interactions through local server memory or session files, making them easier to build but harder to scale.
Horizontal scaling is the primary driver for choosing a stateless architecture. It allows you to add servers without session conflicts.
Laravel supports both. Use sessions for simple web apps and tokens (Sanctum) for scalable APIs.
Shared storage (like Redis) is the bridge that allows an application to feel stateful to the user while remaining stateless at the server level.
Shopify developers should prioritize stateless designs to handle the platform's distributed nature and high-volume webhooks.

How are you managing session persistence in your current production environment to ensure horizontal scaling?

Docker vs Kubernetes: containers vs orchestration

Mon, 22 Jun 2026 00:00:00 GMT

Shipping software is hard. You build an app that works perfectly on your machine, but the moment it hits production, everything breaks. This "it works on my machine" syndrome is exactly why understanding the difference between Docker vs Kubernetes is essential for modern engineers. Environment inconsistencies create friction, delay releases, and lead to late-night debugging sessions that could have been avoided with the right tooling.

The gap between local development and production scale is wide. One tool packages your application into a portable box; the other manages a fleet of those boxes across a cluster of servers. If you are shipping modern web or e-commerce applications, you eventually need both, and knowing where each one stops saves you a lot of wasted effort.

The container revolution with Docker

Docker changed how we think about software delivery by introducing the concept of containerization. A container is a lightweight, standalone package that includes everything needed to run an application. This includes the code, runtime, system tools, libraries, and settings.

When you use Docker, you are essentially creating an immutable image of your software. This image behaves exactly the same whether it is running on your laptop, a colleague's machine, or a staging server. It eliminates the need to manually configure environments, which is a major win for developer productivity.

Docker operates on a single-host level. It manages the lifecycle of individual containers. You use the Docker CLI to build, run, and stop these containers. For many small-scale projects or early-stage startups, Docker on a single VPS is often enough. In fact, tools like Coolify for Docker SaaS hosting have made it incredibly easy to manage these deployments without needing a massive orchestration layer.

Understanding Kubernetes orchestration

If Docker is about the container, Kubernetes is about the cluster. Kubernetes, often abbreviated as K8s, is an open-source platform designed to automate the deployment, scaling, and management of containerized applications. It does not compete with Docker. Docker builds the image; Kubernetes schedules and runs it at scale through whatever container runtime sits on each node.

Imagine you have a high-traffic Shopify app that suddenly experiences a surge in users. Managing fifty individual Docker containers across five different servers manually would be a nightmare. You would have to track which server has space, handle load balancing, and manually restart any container that crashes.

Kubernetes handles this automatically. It uses a declarative approach where you define the "desired state" of your system in YAML files. The Kubernetes control plane then works tirelessly to ensure the actual state matches your requirements. If a container dies, Kubernetes restarts it. If a node fails, it reschedules the work elsewhere.

Docker vs Kubernetes: key technical differences

Comparing Docker vs Kubernetes is not about choosing one over the other. They operate at different layers of the stack. Docker is the runtime that builds and runs the container. Kubernetes is the orchestration layer that schedules those containers across a network.

Feature	Docker	Kubernetes
Primary goal	Containerizing an application	Managing a cluster of containers
Scaling	Manual scaling on a single host	Automated horizontal scaling
Self-healing	Restart policies, single host	Probe-based restarts and rescheduling
Networking	Basic host-level networking	Advanced cluster-wide networking
Complexity	Low to medium	High

Docker focuses on the "how" of running an app. Kubernetes focuses on the "where" and "how many" of running those apps across a distributed system. If the unit of scheduling is new to you, it helps to understand the difference between a container and a pod before you reach for orchestration.

How they work together in production

In a professional DevOps workflow, Docker and Kubernetes are teammates. The process usually starts with a Dockerfile. You build a Docker image and push it to a private container registry. This image is your "source of truth" for the application.

Next, you create Kubernetes manifests. These files tell the cluster which image to use, how many replicas are needed, and what environment variables to inject. When you apply these manifests, the kubelet on each node calls the container runtime to pull the image and start the container. One caveat that trips people up: since version 1.24, Kubernetes removed dockershim, so it no longer talks to Docker Engine directly. Nodes now run a CRI-compliant runtime such as containerd or CRI-O. The image you built with Docker still runs fine because it follows the OCI image spec, but Docker Engine itself is no longer the thing executing it.

This synergy allows for seamless updates. You can perform rolling deployments where Kubernetes replaces old pods with new ones in a controlled rollout. This keeps the service available throughout. If the new version has a bug, Kubernetes can automatically roll back to the previous stable image.

Choosing the right path for your project

Not every project needs the overhead of Kubernetes. If you are an entrepreneur or a small team building a simple web application, starting with Docker Compose or a self-hosted SaaS platform might be more efficient. It allows you to ship fast without managing a complex cluster.

However, if your business requires high availability, handles massive amounts of data, or uses a microservices architecture, Kubernetes is the industry standard. It provides the horizontal scaling needed to grow from a few hundred users to millions without changing your core infrastructure.

Shopify itself is a good example of the payoff: its platform runs on Kubernetes across hundreds of clusters on Google Kubernetes Engine, autoscaling stateless workloads to absorb the brutal traffic spikes of Black Friday and Cyber Monday. Most merchants never touch that layer because Shopify owns it, but if you are building custom apps or your own infrastructure at that scale, the ability to declare capacity and let the cluster reconcile it is the competitive advantage that outweighs the setup complexity.

Takeaways

Docker is for creating, packaging, and running individual containers on a host.
Kubernetes is for orchestrating and managing fleets of containers across a cluster of servers.
Synergy: You use Docker to build the images and Kubernetes to deploy and scale them.
Scale matters: Small projects should stick to Docker to avoid unnecessary complexity. Enterprise-grade apps require Kubernetes for self-healing and autoscaling.
Declarative power: Kubernetes uses YAML to maintain a desired state, making infrastructure management more predictable.

At what stage of growth did your infrastructure move from a single server to a distributed cluster? If you're weighing that jump right now, here's how I help teams get the call right.

Forward proxy vs reverse proxy: the technical guide

Mon, 22 Jun 2026 00:00:00 GMT

Most developers interact with proxies every single day without realizing which direction the traffic is actually flowing. The choice between a forward proxy vs reverse proxy comes down to one question: whose side is the middleman on? You set up Nginx for a Laravel app, and it works. You route outbound traffic through a corporate proxy, and it works. But when the site goes down under heavy load or your IP gets blacklisted, that distinction becomes the difference between a quick fix and hours of infrastructure debt.

In modern web architecture, a proxy is essentially a "middleman" server. It sits between two parties to facilitate communication. However, the side it represents determines its name, its function, and its security benefits. This guide breaks down the core technical differences to help you choose the right pattern for your next deployment.

The forward proxy: protecting the client

A forward proxy sits in front of one or more client machines and acts as their representative to the open internet. When a user makes a request to a website, the request first hits the forward proxy. The proxy then evaluates the request, sends it to the web server, and passes the response back to the user.

From the perspective of the internet, the forward proxy is the one making the request. The original client's IP address remains hidden behind the proxy's IP. This is a common setup in corporate environments or for users seeking anonymity.

Why use a forward proxy?

Forward proxies are primarily used to manage and secure outbound traffic. Here are the most common engineering use cases:

Anonymity and privacy: By masking the client IP, forward proxies prevent websites from tracking individual users based on their network location.
Content filtering: Organizations use forward proxies to block access to specific URLs or categories of websites. If a request violates a security policy, the proxy simply drops it.
Bypassing geo-restrictions: If you need to access a service only available in another region, a forward proxy located in that region can make your request appear local.
Caching for performance: If multiple clients in the same network request the same external resource, the forward proxy can cache that response locally. This saves bandwidth and reduces latency for subsequent requests.

The reverse proxy: protecting the server

While a forward proxy represents the client, a reverse proxy represents the server. It sits at the edge of your infrastructure and intercepts all incoming requests from the internet before they reach your backend application.

The client believes they are communicating directly with the origin server. In reality, they are talking to the reverse proxy. The proxy then decides which backend server should handle the request. This architecture is a cornerstone of modern cloud infrastructure and high-availability systems.

Why use a reverse proxy?

Reverse proxies are essential for scaling and securing web applications. They handle several "heavy lifting" tasks that your application code shouldn't have to manage.

Load balancing: This is the most common use case. A reverse proxy like Nginx or HAProxy distributes incoming traffic across multiple app nodes so no single server becomes a bottleneck. The overlap here is real enough that it's worth reading load balancer vs reverse proxy to see where the two roles diverge.
SSL termination: Managing TLS certificates on every backend server is a nightmare. A reverse proxy decrypts incoming HTTPS at the edge and forwards plain HTTP across a trusted internal network. If compliance demands end-to-end encryption, you re-encrypt to the backend with proxy_pass https:// and proxy_ssl_verify on instead.
Security and WAF: Reverse proxies hide the existence and characteristics of your backend servers. You can run a Web Application Firewall (WAF) at the proxy level to filter SQL injection and XSS before they ever hit your code, and absorb volumetric DDoS traffic at the edge.
Caching: By caching static assets or even entire HTML responses, a reverse proxy serves requests without touching the database or the application server. Push that cache out to the network edge and you are effectively running a CDN — which is why high-traffic sites need both.

Forward proxy vs reverse proxy: visibility and flow

The easiest way to remember the difference is to look at who is being "hidden" from whom.

Feature	Forward Proxy	Reverse Proxy
Who it protects	The client	The server
IP hiding	Hides client IP from server	Hides server IP from client
Placement	Internal network (client-side)	Edge of the network (server-side)
Primary goal	Privacy, filtering, egress control	Load balancing, security, performance
Example tool	Squid, Privoxy	Nginx, HAProxy, Cloudflare

In a forward proxy setup, the origin server has no idea who the actual client is. In a reverse proxy setup, the client has no idea which backend server actually processed their request. Both are essential for clean architecture but solve entirely different problems.

Engineering implementations: Nginx and Docker

When building modern web applications, you are most likely to interact with reverse proxies. If you are using a tool like Coolify or Docker, the reverse proxy is often the component that manages your containers.

For instance, an Nginx reverse proxy configuration for a Laravel application might look like this:

server {
    listen 80;
    server_name myapp.com;

    location / {
        proxy_pass http://app_container:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

In this setup, Nginx acts as the reverse proxy. It receives the request from the user and forwards it to the app_container. It also passes along the X-Forwarded-For header so your application can still know the original user's IP address if needed. This is a critical pattern when building an API gateway for an AI stack or managing Shopify app extensions.

Advanced use cases: the mesh approach

In complex microservices environments, the lines blur. Service meshes like Istio and Linkerd typically deploy a "sidecar" proxy next to every service, and each sidecar acts as both a forward and a reverse proxy depending on whether the traffic is ingress (incoming) or egress (outgoing).

This allows for incredibly granular control over how services talk to each other. You can implement automatic retries, circuit breaking, and mutual TLS without writing a single line of application code. While this adds complexity, it provides the level of observability and reliability required for enterprise-grade systems.

Takeaways

Understanding which direction traffic flows is the first step toward building resilient systems. The points worth keeping:

Forward proxies protect the user. Use them when you want to control how your internal network accesses the internet or to maintain user anonymity.
Reverse proxies protect the infrastructure. Use them to scale your applications through load balancing, improve performance via caching, and secure your backend.
Direction matters. A forward proxy handles outbound requests. A reverse proxy handles inbound requests.
Nginx is the industry standard. It is the most common tool for implementing reverse proxies in Laravel and Docker environments.
Security is centralized. Both types of proxies allow you to centralize security policies rather than implementing them on every individual device or server.

If you are managing a growing web application, you should focus on your reverse proxy configuration. It is the single most powerful tool in your DevOps kit for ensuring uptime and performance.

Have you ever found yourself troubleshooting an "IP mismatch" error caused by a misconfigured proxy header?

DNS vs service discovery

Sun, 21 Jun 2026 00:00:00 GMT

You deploy a new version of your microservice and the old containers are killed instantly. You update your internal DNS records to point to the new IP addresses. However, for the next five minutes, your API gateway continues to send 40 percent of your traffic to the dead containers. Your logs are filled with connection timeouts and your error rate is spiking. This is the classic DNS staleness trap that plagues modern distributed systems.

The problem lies in the fundamental design of how we locate resources. Traditional DNS was built for a world where servers lived for years. In a modern cloud environment, servers might only live for minutes. Relying on static naming systems to manage high-churn infrastructure creates a gap between where your traffic is going and where your healthy services actually live.

This article explores the technical differences between DNS vs service discovery, why the distinction matters for your uptime, and how to choose the right strategy for your DevOps architecture.

DNS vs service discovery: defining the map and the radar

At its core, DNS is a distributed, hierarchical naming system. It acts like the Yellow Pages for the internet. You give it a hostname, and it returns an IP address. It is incredibly efficient and globally ubiquitous. Every programming language and operating system knows how to talk to it.

Service discovery is a more specialized control plane. Instead of just a static map, it acts like a live radar system. It tracks the dynamic state of every service instance in your cluster. While DNS tells you where a service should be, service discovery tells you where it is right now.

A service discovery system like Consul or the internal registry in Kubernetes maintains a "service catalog." This catalog is a live database of every running instance. When a new container starts, it registers itself with the catalog. When it shuts down, it is removed. This happens in milliseconds, far faster than traditional DNS propagation.

The TTL problem and DNS caching

The biggest hurdle in using DNS for microservices is Time-To-Live (TTL). DNS relies heavily on caching to prevent every single request from hammering the root name servers. Your operating system caches the result. Your browser caches the result. Your API gateway caches the result.

If you set a high TTL, your service changes are slow to propagate. If you set a very low TTL (like 0 or 1 second), you might overwhelm your DNS server with lookups. Even worse, some runtimes ignore the TTL entirely. The JVM, for example, caches a successful lookup for 30 seconds by default and forever when a security manager is set, so it can keep a stale IP until the process restarts.

Feature	DNS	Service Discovery
Primary Goal	Human-readable name to IP	Dynamic instance tracking
Propagation	Slow (TTL dependent)	Near-instant (Gossip/Streaming)
Metadata	Very limited (TXT records)	Rich (tags, version, region)
Client Support	Native in all OS	Often requires API/Agent
Health Awareness	None (Static)	Active monitoring

Service discovery solves this by moving away from deep-level caching. Clients or load balancers often maintain a streaming connection to the registry. When a service instance moves, the registry pushes a notification to all subscribers. There is no waiting for a cache to expire. The system converges on the new state almost instantly.

Health awareness: the core differentiator

A standard DNS server is oblivious to the health of the IP addresses it returns. If a server rack loses power, the DNS record still points to those IPs. You have to manually update the record or run a custom script to change it.

Service discovery systems treat health as a first-class citizen. They perform active health checks on every registered instance. These checks can be as simple as a TCP probe or as complex as a custom HTTP endpoint that checks database connectivity.

If a health check fails, the instance is automatically marked as "unhealthy" in the registry. The discovery system then stops returning that IP address to clients. This provides a level of self-healing that is impossible with vanilla DNS, and it pairs naturally with the signals you already collect through logging and monitoring. If you are hosting a SaaS on Docker, automated health-aware routing is the difference between a minor blip and a major outage.

Metadata and rich discovery

DNS is built to return a single type of data: an IP address. While you can use SRV records to include port numbers or TXT records for strings, the interface is clunky. It does not support complex queries.

Service discovery allows for metadata-driven routing. You can ask the registry for "all healthy instances of the 'orders' service running version 2.1 in the 'us-east-1' region." This unlocks advanced deployment patterns like:

Canary Deployments: Routing only 5 percent of traffic to a specific version tag.
Blue/Green Deployments: Swapping traffic between service sets by changing a metadata flag.
Locality-Aware Routing: Directing traffic to the instance physically closest to the requester to reduce latency.

This level of granularity is essential for scaling complex systems where simple round-robin load balancing is not enough.

How modern orchestrators bridge the gap

You might notice that in Kubernetes, you still use DNS names to talk to services. You might call http://order-service.default.svc.cluster.local. Does this mean Kubernetes just uses DNS?

Not exactly. Kubernetes uses a hybrid approach. It runs a service called CoreDNS, but CoreDNS is not backed by static zone files. It is plugged directly into the Kubernetes API. When a Pod starts or dies, the control plane updates the Service and EndpointSlice objects. CoreDNS watches those objects through the API and updates its responses in real time.

In this model, DNS is just the "wire protocol." It is the interface that the application uses because it is easy and standard. However, the backend is a fully dynamic Service Discovery engine. This gives you the best of both worlds: the simplicity of DNS and the speed of Service Discovery.

Implementation strategies: when to use which?

Choosing between DNS vs service discovery depends on your infrastructure scale and churn rate.

If you are running a monolithic application on a few virtual machines that rarely change, DNS is perfectly fine. You can manage your records with simple automation or even manually. The complexity of a dedicated discovery system would outweigh the benefits.

However, if you are using containers, serverless functions, or microservices, you need a dynamic solution. If your IPs change every time you deploy or scale, DNS will eventually break your traffic flow.

For many developers, the best path is to use a tool that provides a DNS interface on top of a dynamic registry. HashiCorp Consul is a popular choice for this. It allows you to query the registry via a standard DNS lookup, but it handles the health checking and registration logic behind the scenes.

Takeaways

DNS is for stability: Use it for external traffic, long-lived resources, and cross-company communication where caching is an advantage.
Service Discovery is for churn: Use it for internal microservices, containers, and autoscaling groups where instances appear and disappear frequently.
Mind the Cache: Never rely on vanilla DNS for sub-minute failover because client-side caching will almost always outlive your records.
Health is Binary: Without active health checks, your discovery system is just a list of guesses. Always integrate automated liveness and readiness probes.
Hybrid is Best: Use a discovery engine (like Kubernetes or Consul) that exposes a DNS interface. This simplifies your application code while keeping your infrastructure dynamic.

When was the last time a stale DNS record caused a production incident in your environment? If you're untangling service routing for a high-churn stack, here's how I help teams ship it.

Bandwidth vs throughput: a wider pipe won't fix lag

Sat, 20 Jun 2026 00:00:00 GMT

You pay for a 1 Gbps fiber line yet your API calls take 500ms to resolve and your database backups crawl at a fraction of that speed. Most engineering teams mistake capacity for performance. They assume that widening the pipe automatically solves the lag. This fundamental misunderstanding leads to over-provisioned cloud bills and under-performing applications. You are throwing money at a bandwidth problem when you actually have a throughput bottleneck.

Bandwidth vs throughput is the difference between a theoretical promise and a practical delivery. In high-performance web development and Shopify ecosystems, knowing which one you are actually limited by is what lets you scale without overpaying.

The capacity promise of bandwidth

Bandwidth represents the maximum theoretical amount of data that can pass through a network path in a given time. Think of it as the number of lanes on a highway. If you have a twelve-lane highway, you have massive bandwidth. You have the potential to move thousands of cars simultaneously.

In technical terms, bandwidth is a measure of capacity. It is usually expressed in bits per second (bps), Megabits per second (Mbps), or Gigabits per second (Gbps). When a cloud provider like Google Cloud or AWS quotes you a network speed, they are selling you bandwidth. It is a hard ceiling on how much data can move.

However, bandwidth is passive. It does not account for the speed of the individual cars or whether there is a massive traffic jam at the exit ramp. You can have a 100 Gbps connection, but if the protocol or the destination server cannot keep up, that bandwidth remains largely unused.

The reality check of throughput

Throughput is the actual amount of data that successfully travels from point A to point B in a specific timeframe. If bandwidth is the number of lanes, throughput is the actual number of cars that arrive at the destination every minute.

Throughput is almost always lower than bandwidth. Several factors degrade the actual flow of data. These include protocol overhead, network congestion, hardware limitations, and packet loss. While you might have a 1 Gbps link, your application might only achieve a throughput of 200 Mbps due to internal processing delays or inefficient code.

Measuring throughput gives you the real picture of your system health. It tells you how your Shopify store or your Laravel backend is actually performing under load. If your throughput is significantly lower than your bandwidth, you are experiencing a bottleneck that more "lanes" will not fix.

The invisible hand of latency

You cannot discuss bandwidth and throughput without addressing the elephant in the room: latency. Latency is the time it takes for a single packet of data to travel from the source to the destination and back. It is the "lag" you feel in a video call or a gaming session.

High bandwidth does not equal low latency. Consider a geostationary satellite link. It may have massive bandwidth (great for downloading large files), but the round trip is roughly 500ms because the signal has to climb to ~35,786km and back. For a "chatty" application that fires many sequential calls, like a RAG-based AI system chaining retrieval and generation, high latency kills throughput.

Every time your application waits for an acknowledgment from the server, it is sitting idle. Even if you have infinite bandwidth, your throughput is capped by how many round trips your data has to make. This is why optimizing for latency is often more impactful than upgrading your network plan.

Why bandwidth vs throughput matters for e-commerce

In a Shopify Plus environment, the gap between bandwidth and throughput directly impacts conversion rates. When a customer hits your store, their browser makes dozens of requests for images, scripts, and API data.

If your images are unoptimized, they eat up bandwidth. If your Shopify apps are poorly coded, they introduce latency. The result is a drop in throughput. The data isn't getting to the customer fast enough. You can have the fastest hosting in the world, but if your liquid templates are doing heavy lifting on every page load, the actual delivery speed stalls.

For businesses scaling their digital presence, focusing on throughput means focusing on the user experience. It involves minimizing the payload size and reducing the number of round trips. It is about making sure the "cars" on your highway are moving at top speed and arriving without delay.

Bottlenecks in the Laravel and DevOps stack

In a typical Laravel environment managed with tools like Docker or Coolify, throughput bottlenecks often hide in the database or the cache layer. You might have a 10 Gbps internal network between your app server and your database server. On paper, your bandwidth is huge.

However, if your queries are not indexed or if you are fetching thousands of unnecessary rows, your throughput will tank. The network is fast, but the application is slow to process and deliver the data. This is where clean architecture and efficient query design become network optimization tools.

DevOps engineers also face throughput issues during CI/CD deployments. Moving a large Docker image across a network requires bandwidth. But the time it takes to unzip, layer, and verify that image is a throughput concern. Optimizing your Dockerfiles to reduce layer size is a direct way to improve the "actual flow" of your deployment pipeline.

Optimizing for performance: a practical approach

Improving network performance requires a two-pronged strategy. You must manage your capacity and optimize your flow. Here are the technical levers you can pull:

Compression and minification: Reducing the size of the data packets (the cars) allows more of them to fit through the pipe simultaneously. Use Gzip or Brotli for your web assets.
CDN implementation: Moving data closer to the user reduces latency. Shorter distances mean faster round trips and higher throughput, see CDN vs cache for where each layer belongs.
Connection pooling: Reusing existing connections for database or API calls eliminates the overhead of the "three-way handshake" required for every new TCP connection.
Asynchronous processing: In Laravel, using queues allows you to handle heavy tasks in the background. This keeps your main application throughput high for the end-user.
Protocol upgrades: HTTP/2 multiplexes many requests over one TCP connection. HTTP/3 goes further, running over QUIC to remove transport-level head-of-line blocking, so a single lost packet no longer stalls every other stream. On lossy mobile links the throughput gain is real.

Measuring the right metrics

Stop looking at your ISP's speed test as the sole measure of success. To truly understand your system, you need to monitor both bandwidth utilization and application throughput. Tools like Google Cloud Monitoring or Datadog provide granular insights into these metrics.

Look for patterns where bandwidth is high but throughput is low. These gaps are where your technical debt lives. They represent inefficient protocols, unoptimized assets, or server-side delays. Closing this gap is how you achieve a "snappy" feel for your web applications.

Architecture matters more than raw speed. A well-designed system on a moderate 100 Mbps link will often outperform a bloated system on a 1 Gbps link. Focus on the efficiency of the data flow rather than the width of the pipe.

Takeaways

Bandwidth is capacity: It is the maximum potential of your network link, not the actual speed of your data.
Throughput is reality: It is the successful delivery rate of data, always limited by overhead and congestion.
Latency is the silent killer: Even with high bandwidth, high latency will cap your throughput by forcing wait times.
Optimize the payload: Smaller data sizes and fewer round trips are the most effective ways to increase throughput.
Monitor the gap: Use dashboard metrics to identify when your actual performance falls far below your theoretical capacity.
Protocol choice matters: A modern transport like HTTP/3 raises effective throughput over lossy links; query layers like GraphQL help separately by cutting over-fetching and round trips.

If you had to choose between doubling your bandwidth or halving your latency for a real-time AI application, which would yield the better ROI for your specific infrastructure? If you're chasing a throughput bottleneck in production, here's how I help teams ship the fix.

Container vs pod: the building blocks

Sat, 20 Jun 2026 00:00:00 GMT

When you move from a simple Docker setup to an orchestrated environment like Kubernetes, the terminology starts to blur. You wonder why you can't just deploy a container directly, and why Kubernetes insists on wrapping your perfectly good Docker image in something called a Pod. The container vs Pod distinction is the first thing that trips people up.

Treat a Pod as merely a "fancy container" and you miss the shared networking and storage that make Kubernetes powerful. You end up with monolithic containers that are hard to scale, or sidecars that can't actually reach the main application. Understanding how a container relates to a Pod is the difference between a brittle deployment and a scalable, resilient system.

The atomic unit: what is a container?

A container is a lightweight, standalone executable package. It includes everything needed to run an application: code, runtime, system tools, system libraries, and settings. At its core, a container is an isolated process running on a host operating system. It shares the host's kernel but maintains its own filesystem and environment variables.

In the world of DevOps and Docker, containers solved the "it works on my machine" problem. They provide a consistent environment from development to production. Whether you are running a Laravel backend or a Shopify app extension, the container remains the same. However, a container is inherently solitary. By default, it has its own IP address and its own isolated filesystem. Communication between two containers usually requires explicit networking configuration or external links.

The logical host: why Kubernetes needs Pods

Kubernetes does not manage containers directly. This is a common point of friction for beginners. Instead, it manages Pods. A Pod is the smallest deployable unit in Kubernetes. Think of a Pod as a "logical host" for one or more containers.

The Pod acts as a wrapper. It provides a shared execution environment for the containers inside it. While most Pods only contain a single container, the ability to group multiple containers is a core feature. These containers are always co-located and co-scheduled. They run on the same physical or virtual machine within the cluster. This coupling allows them to behave as if they were processes running on the same server, despite being isolated in their own containers.

Shared network and localhost: the magic of one IP

The most significant technical advantage of a Pod is the shared network namespace. Every Pod is assigned a unique IP address within the Kubernetes cluster. Every container inside that specific Pod shares this IP address.

This shared network space changes how services communicate. In a standard Docker setup, Container A would need to know the IP of Container B to send a request. Inside a Kubernetes Pod, Container A can talk to Container B simply by using localhost.

This has a few technical implications:

Port management: Since they share an IP, containers in the same Pod cannot bind to the same port. If one container uses port 8080, another container in that same Pod must use a different port.
Performance: Communication over localhost is extremely fast. There is no need for complex routing or service discovery between the containers within the same Pod.
Simplicity: You can build modular systems where a helper container provides a service to the main application without exposing that service to the rest of the cluster.

Shared storage: passing files between containers

Just as they share a network, containers in a Pod can share storage. While a container's internal filesystem is ephemeral and isolated, a Pod can define shared Volumes. These volumes are mounted into the filesystem of every container that needs them.

This is essential for applications that need to pass data between processes. For example, a main application might generate log files, while a separate log-processing container reads those files and ships them to a central server. Without the Pod abstraction, you would have to deal with complex network mounts or external storage providers. In a Pod, it is as simple as mounting a shared directory.

The sidecar pattern: real-world multi-container Pods

The "sidecar pattern" is the primary reason we use multi-container Pods. It allows you to add functionality to an application without changing the application code itself. The "sidecar" container sits next to the "main" container and performs a supporting task.

Common sidecar examples include:

Logging agents: A sidecar that watches a log file on a shared volume and sends the data to Elasticsearch or CloudWatch.
Proxies: A service mesh sidecar (like Istio or Envoy) that handles all incoming and outgoing network traffic for the main application.
Config reloaders: A sidecar that watches a configuration source (like a Git repo or ConfigMap) and signals the main application to reload when changes occur.
Security: A sidecar that handles SSL/TLS termination so the main application only has to deal with plain HTTP.

By separating these concerns into different containers within the same Pod, you keep your main application container clean and focused. This modularity is a pillar of containers versus orchestration thinking.

A practical note: historically you added a sidecar by listing a second entry under spec.containers, which gave you no control over startup or shutdown order. Kubernetes now has first-class sidecar support — an init container with restartPolicy: Always starts before the main containers, stays running for the Pod's lifetime, and shuts down after them. This feature reached stable in Kubernetes v1.33, so reach for native sidecars over plain co-containers when ordering matters.

Technical comparison: container vs Pod

Feature	Standalone Container	Containers in a Pod
Unit of Deployment	Single process image	Kubernetes Pod object
Networking	Unique IP per container	Unique IP per Pod (shared)
Localhost Access	Isolated to the container	Shared across all containers
Storage	Isolated filesystem	Shared Volumes available
Scheduling	Manual or via runtime	Automatic by K8s scheduler
Lifecycle	Tied to the process	Tied to the Pod's status
Scaling	Scale individual instances	Scale the entire Pod unit

DevOps deployment: GCP and AWS context

When you move your workloads to managed cloud providers like Google Cloud (GKE) or AWS (EKS), the container vs Pod distinction becomes operational. These platforms manage the infrastructure, but you still define the Pod specifications.

The line gets blurrier on serverless platforms. EKS on Fargate still runs real Pods, so multi-container Pods and sidecars work exactly as they do on a self-managed node — Fargate just provisions the compute per Pod instead of per node. Cloud Run started as single-container only, but since May 2023 it supports multi-container deployments where sidecars share the network namespace and communicate over localhost, just like a Pod. So you no longer have to jump to full Kubernetes the moment you need a sidecar — though you do once you need richer orchestration like DaemonSets, complex scheduling, or fine-grained networking.

Takeaways

A container is the packaging format, while a Pod is the execution environment.
Containers in a Pod share the same IP address and can communicate via localhost.
Shared Volumes allow containers within a Pod to exchange data through the filesystem.
The sidecar pattern uses multiple containers in one Pod to separate concerns like logging and security.
Kubernetes schedules and scales Pods as a single unit, ensuring all containers land on the same node.
Understanding Pods is crucial for managing complex deployments on GCP, AWS, or self-hosted tools like Coolify.

At what point does the overhead of managing a multi-container Pod outweigh the benefits of process separation in your current infrastructure? If you're architecting workloads that have outgrown plain Docker, here's how I help teams ship it.

AI vs machine learning: an engineering deep dive

Fri, 19 Jun 2026 00:00:00 GMT

The tech industry often treats "AI" and "machine learning" as interchangeable. This confusion leads to real architectural debt when teams build intelligent features without understanding the underlying mechanics. You end up trying to build a predictive engine out of static rule-based systems or, conversely, over-engineering a simple decision tree with a neural network.

Misidentifying the right tool produces bloated cloud bills, slow performance, and systems that fail to generalize to real-world data. When you conflate the umbrella field of artificial intelligence with the specific mechanics of machine learning, you lose the ability to choose the most efficient path for your product.

This guide draws the line between the two concepts and shows how they manifest in modern stacks like Laravel and Shopify, with a focus on RAG and agentic systems. The goal: a clear framework for deciding when to reach for rule-based logic and when to deploy a learned model.

The AI umbrella: broad intelligent systems

Artificial Intelligence (AI) is the broad field of creating systems capable of performing tasks that typically require human intelligence. This is the "umbrella" term. It encompasses everything from simple "if-then" logic to the most complex large language models (LLMs).

In engineering terms, AI is about the system's behavior. If a software system can reason, plan, or solve problems, it is an AI system. This does not mean it has to "learn." Early AI systems, often referred to as symbolic AI or expert systems, relied on hardcoded rules and logic gates. These systems are highly predictable and easy to debug because every decision path is explicitly defined.

For example, a sophisticated shipping calculator in a Shopify Plus store that adjusts prices based on complex regional taxes and carrier API responses is a form of narrow AI. It mimics human decision-making based on a set of logical parameters. However, it is not machine learning because it does not improve its performance based on past data unless a developer manually updates the code.

Machine learning: the engine of pattern recognition

Machine Learning (ML) is a subset of AI that focuses on the development of algorithms that allow computers to learn from and make predictions based on data. Instead of being explicitly programmed to perform a task, an ML model is "trained" on a dataset to find patterns and hidden structures.

When you are building a product that needs to handle high-dimensional data where rules are too complex to write by hand, ML is the solution. Think about image recognition or fraud detection. You cannot write enough "if" statements to account for every possible pixel arrangement in a photo of a cat. Instead, you feed an ML model thousands of images, and it learns the statistical representation of a "cat."

In a production environment, ML involves a lifecycle that is distinct from traditional software development. It requires data collection, cleaning, feature engineering, model training, and evaluation. You can read more about how this differs from standard workflows in our post on AI vs traditional development. For the deeper discriminative-vs-generative comparison inside ML itself, see machine learning vs generative AI.

AI vs machine learning in RAG systems

The distinction becomes critical when you move into modern AI Engineering, particularly with Retrieval-Augmented Generation (RAG). A RAG system is a perfect example of an AI system that incorporates multiple ML components to achieve a goal.

In a RAG pipeline, the system behavior is the AI part. The orchestration of how a user query is received, how a search is performed against a vector database, and how the results are fed into a prompt is a design problem. The components doing the heavy lifting, however, are ML models.

Embedding models and vector databases

The "retrieval" part of RAG relies on embedding models. These are ML models (specifically deep learning models) that transform text into high-dimensional vectors. When you store these vectors in a tool like pgvector or a dedicated vector database, you are using the output of a machine learning process.

The generator (LLM)

The "generation" part is handled by a large language model. This is a massive ML model trained on trillions of tokens of text. While you interact with it via an API or a local deployment, the model itself is a static file of weights learned through intensive training.

When you refine your RAG system, you are often doing AI engineering by changing the chunking strategy or the system prompt. You are only doing ML engineering if you decide to fine-tune the embedding model or the LLM itself on your domain data — a trade-off covered in RAG vs fine-tuning. Understanding these layers helps prevent common RAG mistakes in production.

Agentic systems and autonomous workflows

Agentic systems take the AI vs machine learning comparison a step further. An "agent" is an AI system that uses an ML model as its "brain" to determine a sequence of actions toward a goal — the jump from a static model to an autonomous one is the focus of LLM vs AI agent.

In an agentic workflow, the ML model (the LLM) is just one tool in the agent's belt. The agent might also have access to a search engine, a calculator, or a database. The logic that handles the "loop" (Observe -> Think -> Act) is the AI system design.

For developers working with Shopify, agentic commerce allows for autonomous customer service or inventory management. The agent uses machine learning to understand the customer's intent (NLP) but uses traditional software APIs to execute a refund or check stock levels.

// A conceptual example of an AI Agent 'thought' process in a Laravel controller
public function handleAgentRequest(Request $request)
{
    $userInput = $request->input('query');

    // ML Component: Identify intent using an LLM
    $intent = $this->llmService->identifyIntent($userInput);

    // AI System Logic: Choose the tool based on intent
    if ($intent === 'check_order_status') {
        return $this->orderService->getStatus($request->user());
    }

    // AI System Logic: Fallback to RAG if intent is informational
    return $this->ragService->queryKnowledgeBase($userInput);
}

Practical implementation: Laravel and Shopify contexts

Integrating AI and ML into existing frameworks like Laravel or Shopify requires a clear understanding of where the data lives and how the models are served.

Laravel and ML orchestration

Laravel is an excellent framework for building the "AI system" around an ML model. You can use Laravel's robust queue system to handle long-running ML tasks or use its HTTP client to communicate with Python-based ML microservices. Many developers use Laravel to manage the "human-in-the-loop" aspects of AI, such as reviewing model outputs before they are published.

Shopify and AI

Shopify has integrated AI features directly into its platform via Shopify Magic. However, for custom Shopify Plus builds, you might implement your own ML-driven product recommendation engine. This involves capturing user behavior data, training a model (likely off-platform on Google Cloud or AWS), and serving those recommendations via a custom app or a Liquid block.

Cloud infrastructure for AI and machine learning

Deploying these systems requires different infrastructure strategies. AI systems (the orchestration code) can usually run on standard web servers or serverless functions. Machine learning models, especially for training or high-throughput inference, often require GPUs or specialized hardware.

Using Docker and tools like Coolify can simplify the deployment of these modular systems. You might host your Laravel application on a standard VPS while your vector database and ML inference server run in separate containers. For more on this, check out our guide on Coolify and Docker for SaaS hosting.

Monitoring is also different. For an AI system, you monitor latency and error rates. For an ML model, you monitor "drift" (when the real-world data starts to look different from the training data) and accuracy.

Takeaways

Distinguishing between AI and machine learning is not just about semantics. It is about choosing the right architecture and team skill sets for your project.

AI is the "what": It describes the goal of creating intelligent behavior. It includes both hardcoded logic and learned models.
Machine Learning is the "how": It is a specific method for achieving AI by training models on data.
RAG and agents are hybrid systems: They use ML components (LLMs, embeddings) inside an AI system designed with code and prompts.
Framework integration matters: Laravel is great for AI orchestration, while Shopify Plus provides a robust environment for ML-driven commerce.
Infrastructure needs differ: AI code is lightweight. ML models require specialized environments for training and inference.

Are you building a system that needs to follow strict regulatory rules, or one that needs to adapt to unpredictable user behavior?

Training vs inference: scaling AI systems

Thu, 18 Jun 2026 00:00:00 GMT

Most engineering teams treat AI models as a single black box. They allocate a massive GPU budget and hope for the best. But when the application hits production, latency spikes, costs spiral out of control, and the "intelligent" features start timing out. This happens because developers fail to distinguish between the two distinct phases of an AI lifecycle: training and inference. Without a clear understanding of how these stages consume resources, your AI strategy is essentially a shot in the dark.

The anatomy of training: learning from data

Training is the "learning" phase of a machine learning model. During this stage, you feed an algorithm a massive dataset. The model looks at the data, makes a guess, compares its guess to the actual answer, and adjusts its internal parameters (weights) to get closer to the truth next time. This process is repeated millions or even billions of times.

The primary goal of training is to minimize error. Because this requires massive matrix multiplications and constant backpropagation, it is extremely compute-intensive. You are effectively asking a computer to solve a giant calculus problem over and over again. This is why training typically happens on large clusters of high-end GPUs or TPUs.

Training is usually a burst-heavy, high-upfront-cost activity. You might spend two weeks and $50,000 to train a custom model for your specific industry. Once the model reaches a satisfactory level of accuracy, the training phase ends. The model's weights are "frozen," and it is ready to be used in the real world.

The power of inference: applying knowledge

Inference is the "execution" phase. This is what happens when a user interacts with your application. A customer types a query into your Shopify store's AI assistant, the model processes that query using its frozen weights, and it returns an answer. No learning happens during inference. The model is simply applying what it already knows.

In technical terms, inference is a "forward pass." You provide an input, the data flows through the layers of the model, and an output is generated. There is no backpropagation and no weight updates. This makes inference much faster and less compute-intensive than training on a per-request basis.

However, inference is where the "unbounded cost" problem lives. While training is a one-time or periodic expense, inference happens every time a user makes a request. If you have a million users making ten queries a day, you are running ten million inferences. Over the lifetime of a successful product, inference costs often dwarf training costs by a factor of 10x or more.

The classroom metaphor: student vs. graduate

To simplify these complex technical ideas, think of a student in medical school.

Training is the years of study. The student reads thousands of textbooks, attends lectures, and takes practice exams. This process is slow, expensive, and requires intense focus. The "parameters" of the student's brain are being adjusted as they learn how to diagnose diseases.

Inference is the doctor in the clinic. A patient walks in with symptoms. The doctor uses their existing knowledge to provide a diagnosis. The doctor doesn't go back to medical school for every patient. They simply apply the patterns they have already learned. The diagnosis happens in minutes, not years.

If you are building an AI vs traditional development strategy, you need to decide if you are training a new doctor (custom training) or simply hiring one that already exists (using a pre-trained model via API).

Hardware and infrastructure: GPUs vs. the rest

The hardware requirements for these two phases are fundamentally different. Understanding this can save you thousands in infrastructure costs.

Feature	Training	Inference
Primary Goal	High Throughput	Low Latency
Compute Pattern	Burst-heavy / Parallel	Steady / Sequential
Hardware	Multi-GPU Clusters (H100, A100)	Single GPU, CPU, or Edge (T4, L4, Apple Silicon)
Optimization	Gradient Descent / Backprop	Quantization / Model Compression
Cost Type	CAPEX (Upfront)	OPEX (Recurring)

For training, you need massive VRAM and high-speed interconnects (like NVLink) between GPUs. For inference, you often prioritize energy efficiency and "cost per token." In many cases, a well-optimized model can run inference on standard CPUs or specialized "edge" chips, which is much cheaper than maintaining a fleet of high-end GPUs. If you manage your own servers, you can split the workloads: put training tasks on high-perf clusters and move inference to smaller, distributed nodes closer to your users.

Integrating inference into Laravel applications

When building custom web solutions, you usually deal with the inference side of the equation. You aren't training a frontier model from scratch. You are calling an API or a self-hosted model to perform a task. Here is a typical pattern for handling AI inference inside a Laravel controller.

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Http;

class AIInferenceController extends Controller
{
    /**
     * Handle an AI inference request.
     */
    public function generate(Request $request)
    {
        $prompt = $request->input('prompt');

        // We use a high-performance inference endpoint
        // This could be OpenAI, Anthropic, or a self-hosted vLLM server
        $response = Http::withHeaders([
            'Authorization' => 'Bearer ' . config('services.ai.key'),
        ])->post('https://api.inference-provider.com/v1/completions', [
            'model' => 'llama-3-70b',
            'prompt' => $prompt,
            'max_tokens' => 150,
            'temperature' => 0.7,
        ]);

        if ($response->successful()) {
            return response()->json([
                'result' => $response->json('choices.0.text'),
                'latency' => $response->header('X-Inference-Time'),
            ]);
        }

        return response()->json(['error' => 'Inference failed'], 500);
    }
}

This simple setup highlights a key architectural point: the API Gateway for your AI stack must be able to handle the specific latency requirements of inference. Users expect a response in milliseconds, not minutes.

The role of RAG: inference with a memory

One way to bridge the gap between training and inference is retrieval-augmented generation (RAG). Instead of re-training a model every time your data changes (which is expensive and slow), you provide the model with "context" during the inference phase. That tradeoff is its own decision, covered in RAG vs fine-tuning.

In a RAG system, you search a vector database for relevant information and "stuff" it into the prompt. The model then uses its pre-trained reasoning capabilities to answer based on that new data. This is inference acting like it has a temporary memory. However, be careful. If you don't optimize your vector search, your inference latency will explode. You can read more about avoiding RAG mistakes in production to keep your systems lean.

Takeaways

Training is about learning. It is a one-time or periodic compute-heavy process that builds the model's intelligence.
Inference is about acting. It is the real-time application of that intelligence and represents the majority of long-term costs.
Hardware matters. Don't use a massive GPU cluster for inference if a smaller, quantized model can run on a single T4 or even a CPU.
Optimize for your phase. If you are training, focus on throughput (tokens per second). If you are serving users, focus on latency (time to first token).
RAG is your friend. It allows you to give "new knowledge" to a frozen model during inference without the massive cost of re-training.

At what point in your product's growth do you anticipate inference costs will exceed your initial development budget? If you're architecting an AI stack that has to stay fast and affordable at scale, here's how I help teams ship it.

Vector search vs graph search for RAG

Thu, 18 Jun 2026 00:00:00 GMT

Retrieval-Augmented Generation (RAG) forces a question most teams put off: how is data actually retrieved? Most production systems start with vector search because it is accessible and effective for basic similarity. But as queries get more complex, the limits of semantic similarity show. A system that finds "similar" things often fails when asked to explain "connected" things. That gap is where the choice between vector search and graph search decides whether your RAG strategy holds up.

Relying solely on vector embeddings can lead to a phenomenon known as the semantic trap. You might retrieve five document chunks that all mention a specific topic, but if those chunks do not explicitly link to each other, the LLM will struggle to synthesize a multi-hop answer. This often results in hallucinations or incomplete reasoning. If your RAG pipeline cannot traverse relationships, it is essentially working with a deck of shuffled cards rather than an organized map.

The fix starts with understanding the trade-offs between vector-based and relationship-based retrieval. Vector search excels at high-dimensional similarity; graph search offers structured traversals that preserve the logic of your data. Combining the two into a hybrid architecture is usually the most robust path forward.

Understanding vector search and embeddings

Vector search operates by converting unstructured data into dense numerical arrays called embeddings. These embeddings represent the semantic meaning of the text in a multi-dimensional space. When a user submits a query, that query is also converted into a vector. The system then calculates the mathematical distance between the query vector and the stored vectors using algorithms like cosine similarity or Euclidean distance.

For developers working within the Laravel or Node.js ecosystems, tools like pgvector have made this incredibly accessible. By adding a vector column to a standard Postgres database, you can perform similarity searches directly alongside your relational data. This approach is highly efficient for "fuzzy" matching. It can find a product description for a "crimson summer dress" even if the query only mentions a "red lightweight gown."

However, vector search is fundamentally limited by its lack of structural awareness. It treats every chunk of data as an independent point in space. It has no inherent understanding that "User A" is the "CEO" of "Company B" unless those specific words are clustered together in a single text chunk.

The mechanics of graph search

Graph search takes a completely different approach by modeling data as nodes (entities) and edges (relationships). Instead of looking for similarity in a coordinate system, graph search traverses defined paths. A node might represent a person, a place, or a concept, while an edge defines how they interact. For example, an edge labeled "works_at" might connect a person node to a company node.

This structure allows for multi-hop queries that are nearly impossible for pure vector search. You can ask the system to "find all employees at companies that use Laravel and were founded after 2015." A graph database like Neo4j or a graph-capable extension can follow these links precisely. In the context of RAG, this means the retrieval engine can pull in a coherent chain of facts rather than a disjointed set of similar-sounding paragraphs.

The challenge with graph search is the ingestion process. Unlike vector search, which only requires a simple embedding model, graph search requires entity extraction and schema mapping. You must identify which entities exist in your text and how they relate to one another before they can be stored in the graph. This adds complexity to your data pipeline but pays dividends in reasoning accuracy.

Comparison: vector vs graph search

Choosing the right approach depends on the nature of your data and the questions your users are asking. The table below outlines the primary technical differences.

Feature	Vector Search (pgvector)	Graph Search (Knowledge Graph)
Data Model	High-dimensional dense vectors	Nodes, edges, and properties
Query Type	K-Nearest Neighbors (k-NN)	Traversals and pattern matching
Strengths	Semantic similarity, fuzzy match	Complex relationships, multi-hop logic
Weaknesses	Struggles with structural reasoning	High ingestion complexity
Ideal For	FAQ bots, general search, broad Q&A	Fraud detection, supply chain, reasoning
Scaling	Efficient with ANN indexing (HNSW)	Sensitive to graph density and depth

For a deeper look at avoiding common pitfalls in this space, see our guide on 7 RAG mistakes in production. Many teams find that they start with vectors and only introduce graphs when they hit a "reasoning wall."

GraphRAG: the hybrid evolution

The most advanced RAG systems are moving toward a hybrid model often referred to as GraphRAG. This architecture does not choose one over the other. Instead, it uses both to provide the LLM with a richer context. In a GraphRAG setup, the system first performs a vector search to identify relevant starting points in the knowledge base. Once those starting points are found, it uses graph traversals to pull in related entities and contextual relationships.

Imagine a medical research application. A vector search might find a paper about a specific drug. The graph search then identifies the chemical compounds in that drug, the clinical trials associated with it, and the known side effects reported in other related papers. The resulting context provided to the LLM is a structured "subgraph" of knowledge. This significantly reduces the risk of hallucinations because the LLM is working with explicitly linked facts.

Implementing this hybrid approach requires a solid DevOps foundation. Tools like Docker and Coolify can help manage the multiple services involved, including your vector store, graph database, and the extraction services that keep them in sync. If you are exploring how to host these complex stacks, our article on Coolify and self-hosted SaaS provides a good starting point for infrastructure management.

Technical implementation with pgvector and SQL

For teams already using Postgres, pgvector is the logical starting point for adding vector capabilities. It integrates seamlessly into existing SQL workflows. You can store your embeddings in a vector column and use the <-> (Euclidean) or <=> (cosine) operators to query them.

-- Example: Finding similar document chunks in Postgres
SELECT content, 1 - (embedding <=> '[0.1, 0.2, 0.3, ...]') AS similarity
FROM document_chunks
WHERE 1 - (embedding <=> '[0.1, 0.2, 0.3, ...]') > 0.8
ORDER BY similarity DESC
LIMIT 5;

To approximate a graph without a dedicated graph database, you can model simple one-to-many or many-to-many relationships with relational joins. But as the number of hops grows, recursive joins and WITH RECURSIVE queries get expensive fast, and the planner struggles to keep them efficient. That is the point to introduce a specialized graph layer such as Neo4j or the Apache AGE extension, which adds openCypher graph queries directly to Postgres. For the broader question of which retrieval components to assemble, see picking the right RAG stack.

Choosing your path

The decision between vector and graph search is not binary. It is a spectrum of technical complexity versus reasoning capability. For simple semantic search over a collection of PDFs, vector search with pgvector is almost always the right answer. It is fast, easy to implement, and requires minimal maintenance.

If your application requires high precision, multi-step logic, or the ability to explain "why" a result was chosen, the investment in a knowledge graph is necessary. The architectural overhead of building an extraction pipeline is the price you pay for a system that truly understands the relationships within your data.

Most production-grade AI systems will eventually land in the middle. They will use vectors for broad discovery and graphs for deep reasoning. By designing your system with a modular approach today, you can ensure that your infrastructure is ready to evolve as your AI needs grow.

Takeaways

Vector search is best for semantic similarity and is easy to implement using tools like pgvector.
Graph search excels at multi-hop reasoning and mapping complex relationships between entities.
Vector search treats data points as isolated, while graph search treats them as connected nodes.
GraphRAG is a hybrid approach that uses vector search for discovery and graph search for context expansion.
Start with vector search for most projects, but prepare for graph search if your queries require complex structural reasoning.
Monitor retrieval metrics like recall and precision to spot when a vector-only strategy starts failing.

How is your current RAG pipeline handling multi-hop queries that connect data points across documents? If you're building one for production, here's how I help teams ship it.

Terraform vs Ansible: the real difference in DevOps

Wed, 17 Jun 2026 00:00:00 GMT

You spend six hours manually clicking through the AWS console to set up a VPC, three subnets, and a load balancer, only to realize you missed a single security group rule that breaks the entire staging environment. Then you have to do it all over again for production. This manual toil is a ticking time bomb for technical debt and human error. Infrastructure as Code (IaC) is the industry standard solution, but the market is split between two titans: Terraform and Ansible. Choosing the wrong one for the wrong task leads to fragile pipelines and "snowflake" servers that no one dares to touch.

Terraform vs Ansible: provisioning vs configuration

The most common misunderstanding in DevOps is treating Terraform and Ansible as interchangeable tools. They are not. At their core, they solve two distinct stages of the infrastructure lifecycle.

Terraform is a provisioning tool. Its primary job is to talk to cloud providers like AWS, Google Cloud, or Azure to create the virtualized "hardware" of your stack: VPCs, subnets, IAM roles, and managed databases. It builds the foundation your software will live on.

Ansible is a configuration management tool. Once the server exists, Ansible takes over to install Nginx, configure the PHP-FPM pool, or deploy your latest Laravel build. It is designed to manage the internal state of the operating system and the applications running on it.

Feature	Terraform	Ansible
Primary Goal	Provisioning infrastructure	Configuration management
Language	HCL (declarative)	YAML (procedural/imperative)
State	Managed (state file)	Stateless
Architecture	Client-only (API-based)	Agentless (SSH/WinRM)
Best For	VPCs, clusters, databases	Installing apps, OS hardening

Declarative vs procedural logic

The way you talk to these tools defines how you manage your stack. Terraform is strictly declarative. You describe the "end state" you want. If you tell Terraform you want five EC2 instances, it looks at your current environment. If you have three, it adds two. If you have seven, it deletes two. You don't tell it how to do it; you tell it what you want the result to be.

Ansible is primarily procedural (or imperative), though it uses declarative modules. You write playbooks that list a series of steps:

Update apt-get.
Install Docker.
Copy the config file.
Restart the service.

While Ansible modules are idempotent (meaning they won't re-install Docker if it's already there), the workflow follows a specific sequence of commands. This makes Ansible exceptionally good at complex application deployments where the order of operations matters.

Immutable vs mutable infrastructure

The choice between Terraform vs Ansible often dictates your architectural philosophy. Terraform leans heavily toward immutable infrastructure. In an immutable world, you don't "fix" a server. If you need to change the instance type or update the base OS, you destroy the old server and provision a new one from a fresh image. This is the same philosophy behind containers and orchestration, and it eliminates "configuration drift" where servers that started identical become different over time due to manual patches.

Ansible is the king of mutable infrastructure. It is designed to go into existing, long-lived servers and modify them. This is often necessary for legacy systems or complex environments where spinning up a fresh cluster for every minor config change is too slow or expensive. For teams using self-hosted solutions like Coolify for SaaS hosting, Ansible can be a powerful ally in managing the underlying VPS environment.

State management: the source of truth

Terraform's superpower (and its greatest complexity) is the state file. This JSON file acts as a map of your real-world infrastructure. When you run a command, Terraform compares your HCL code against this state file to determine what needs to change. This allows Terraform to detect "drift": when someone manually changes a setting in the AWS console, Terraform will see the discrepancy and offer to revert it.

Ansible is stateless. It doesn't keep a record of what it did yesterday. It simply connects to the IP addresses in your inventory and attempts to execute the playbook. If a server is down, Ansible reports a failure but doesn't have a "global view" of your infrastructure health in the same way Terraform does. This makes Ansible easier to start with but harder to use for tracking the total lifecycle of high-level cloud resources.

Better together: the hybrid workflow

In a professional DevOps pipeline, you rarely choose just one. The most robust engineering teams use a "best of breed" approach.

A typical workflow looks like this:

Terraform provisions the network (VPC), the security groups, and the base EC2 instances using a clean Ubuntu AMI.
Terraform outputs the IP addresses of those new instances.
Ansible picks up those IPs and runs a playbook to install the LEMP stack, configure SSL certificates, and tune the firewall.

By separating the cloud fabric (Terraform) from the software layer (Ansible), you create a modular system that is easy to debug and scale. If you need to move from AWS to Google Cloud, you rewrite your Terraform providers but keep your Ansible playbooks largely the same. Wiring both stages into a single CI/CD pipeline turns this into a one-command, reproducible build.

One 2026 caveat worth flagging: HashiCorp moved Terraform to the Business Source License in August 2023, and the community forked it into OpenTofu (now a CNCF project under the Linux Foundation). OpenTofu is a near drop-in replacement using the same HCL syntax and state format, so "Terraform" in this article applies equally to it. IBM completed its acquisition of HashiCorp in February 2025, which has only sharpened that licensing question for teams.

Takeaways

Terraform is for building the house (infrastructure). It is declarative, immutable, and stateful.
Ansible is for decorating and maintaining the house (software configuration). It is procedural, mutable, and stateless.
Use Terraform to manage resources with a clear lifecycle, like databases and load balancers.
Use Ansible to manage the "inside" of a VM, such as package updates and application deployments.
Avoid using Ansible to provision cloud resources; while possible, it lacks the sophisticated state management and dependency graphing of Terraform.
Combine both tools in a CI/CD pipeline for a fully automated, reproducible environment.

If you had to rebuild your entire production environment from scratch in 30 minutes, would your current automation tools be enough to restore both the infrastructure and the application state?

SRE vs Platform Engineer: who to hire for scale

Tue, 16 Jun 2026 00:00:00 GMT

Your production environment is down and the error budget is burning. You have two choices. You can hire someone to fix the immediate fire and ensure it never happens again. Or you can hire someone to build the tools that prevent your developers from starting that fire in the first place. This is the fundamental tension between Site Reliability Engineering (SRE) and Platform Engineering.

For years, "DevOps" was the catch-all term for anyone who touched a server. But as systems have grown in complexity, the roles have fractured into specialized disciplines. SRE and Platform Engineering are the two most prominent results of this evolution. While they often share tools like Kubernetes, Terraform, and Docker, their missions are worlds apart. One focuses on the runtime reality of the user. The other focuses on the internal experience of the developer.

The SRE: the guardian of production

Site Reliability Engineering is what happens when you ask a software engineer to design an operations function. Originally pioneered by Google, SRE is a discipline that treats operations as a software problem. The primary mission of an SRE is simple but difficult. They must ensure that production services are reliable, scalable, and performant.

SREs live and breathe metrics. They define Service Level Indicators (SLIs) and Service Level Objectives (SLOs) to quantify what "up" actually means. If a service has a 99.9% availability target, the SRE manages the "error budget." This is the remaining 0.1% of downtime allowed before the team must stop shipping features and focus entirely on stability.

The daily life of an SRE involves on-call rotations, incident response, and post-mortem analysis. They don't just fix bugs. They build automation to eliminate "toil." Toil is the manual, repetitive work like scaling clusters or rotating certificates that scales linearly with the size of the system. By writing code to automate these tasks, an SRE ensures that the infrastructure can grow without requiring a proportional increase in headcount.

The Platform Engineer: architect of the golden path

Platform Engineering is the practice of building and operating internal developer platforms (IDPs). If the SRE is focused on the end-user, the Platform Engineer is focused on the internal developer. Their goal is to improve Developer Experience (DX) by abstracting away the complexity of the underlying infrastructure.

A Platform Engineer builds "Golden Paths." These are standardized, self-service workflows that allow a developer to go from "code on my laptop" to "running in production" without needing to open a ticket for the infrastructure team. Instead of every developer learning the nuances of AWS IAM roles or Kubernetes ingress controllers, they use a platform that handles these details automatically.

The success of a Platform Engineer is measured by lead time to production and developer satisfaction. They treat the platform as a product. They conduct user research with their internal developers to find friction points. They build CI/CD pipelines, environment provisioning tools, and internal portals that make shipping software feel effortless. You can see similar patterns in how tools like Coolify simplify SaaS hosting by providing a cohesive management layer.

The core divergence: metrics and customers

The easiest way to distinguish these roles is to look at who they serve and how they are measured.

Feature	SRE	Platform Engineer
Primary Customer	End users & product teams	Internal developers
Success Metric	SLOs, latency, MTTR	Lead time, deployment frequency
Key Focus	Production reliability	Developer productivity
Artifacts	Alerting rules, runbooks, SLOs	IDPs, CLI tools, CI/CD templates

An SRE cares about the "now." Is the site up? Is the latency within limits? If a database query takes 500ms instead of the usual 50ms, the SRE is the first person to notice. They are the frontline defenders of the business's reputation.

A Platform Engineer cares about the "how." How long does it take for a new hire to ship their first line of code? How many manual steps are in the deployment process? They are the industrial engineers of the software factory. They optimize the assembly line so that everyone else can move faster. This role is increasingly important as we move toward agentic commerce and automated Shopify workflows, where the speed of iteration is a competitive advantage.

A Formula 1 metaphor

Imagine a Formula 1 team. The SRE is the pit crew and the race engineer. They are monitoring the car in real-time during the race. They check tire pressure, fuel levels, and engine temperature. If something goes wrong on lap 30, they are the ones making split-second decisions to keep the car on the track. They manage the "reliability" of the race.

The Platform Engineer is the engineer back at the factory who designed the car and the tools used to build it. They created the wind tunnel, the simulation software, and the standardized parts that make the car fast and safe. They ensure that the driver and the pit crew have the best possible equipment to do their jobs. Without the factory engineer, the car wouldn't be fast. Without the race engineer, the car wouldn't finish the race.

The tools of the trade

While both roles use similar technologies, they apply them differently.

SRE tooling:

Observability: Prometheus, Grafana, Datadog, Honeycomb.
Incident management: PagerDuty, Opsgenie.
Resilience: Chaos Mesh, Gremlin.
Automation: Python, Go, Ansible.

Platform engineering tooling:

Internal portals: Backstage, Port, Cortex.
Infrastructure as Code: Terraform, Pulumi, Crossplane.
CI/CD: GitHub Actions, GitLab CI, ArgoCD.
Developer environments: Loft, DevPod, Docker.

The SRE uses observability tools to find "unknown unknowns" in production. The Platform Engineer uses those same tools to bake monitoring defaults into the platform. If you want to dive deeper into the technical stack for modern applications, check our guide on the API gateway for the AI stack.

Better together: the synergy loop

In a high-performing organization, these two roles form a powerful feedback loop. The SRE discovers a recurring failure mode during an incident. Perhaps developers are forgetting to set proper resource limits on their containers. This causes nodes to run out of memory.

Instead of just telling developers to "be more careful," the SRE brings this feedback to the Platform Engineer. The Platform Engineer then updates the "Golden Path" templates to include sensible default resource limits automatically. Now, every new service created on the platform is "reliable by design."

This synergy reduces the SRE's operational load. They spend less time fighting fires and more time on high-level architecture. Simultaneously, the developers are happier because the platform prevents them from making common mistakes. This is the pinnacle of modern DevOps maturity.

Which one do you need?

The choice depends on your current pain points.

If your developers are constantly struggling to set up environments, fighting with CI/CD pipelines, or waiting weeks for infrastructure tickets, you need a Platform Engineer. You have a productivity bottleneck. You need to productize your infrastructure to allow your team to scale.

If your site is frequently down, your performance is unpredictable, and your developers are terrified of shipping on a Friday, you need an SRE. You have a reliability bottleneck. You need someone to instill the discipline of SLOs and incident management into your culture.

In many startups, a single "DevOps Engineer" handles both. But as you grow, the split is inevitable. Specialized roles allow for deeper expertise. An SRE who doesn't have to build CI/CD pipelines can focus entirely on making the system indestructible. A Platform Engineer who isn't on-call for every production blip can focus entirely on making the developer experience world-class.

Takeaways

SRE focuses on the reliability of production systems for end users.
Platform Engineering focuses on the developer experience and internal tooling.
SRE uses SLOs and error budgets to balance speed and stability.
Platform Engineering uses "Golden Paths" to provide self-service infrastructure.
The two roles are complementary. SRE provides the feedback, and Platform Engineering provides the abstractions.
Both roles are essential for scaling modern, complex software organizations.

How does your team handle the balance between shipping fast and staying up?

Synchronous vs asynchronous communication

Tue, 16 Jun 2026 00:00:00 GMT

Every developer has faced the dreaded "spinning wheel of death." You click a button, the browser hangs, and you wait five seconds for a confirmation that never feels fast enough. This lag usually stems from a synchronous process holding the entire request-response cycle hostage while it waits for a third-party API or a heavy database query. In high-traffic environments, these blocking calls are not just a nuisance. They are a scalability killer that can bring down your entire infrastructure.

Architecting for scale requires a deep understanding of when to keep things synchronous and when to move them to the background. This decision impacts everything from user experience to server costs. By shifting heavy lifting to asynchronous workers, you decouple your system. This allows your application to handle thousands of concurrent users without breaking a sweat.

The blocking nature of synchronous communication

Synchronous communication is the traditional request-response model. When a client sends a request, it waits for the server to process the logic and return a response. This is a "blocking" operation. The execution thread is tied up until the task completes.

Think of it like a phone call. You dial a number, wait for the other person to pick up, and you cannot do anything else until the conversation is over. In web development, this is perfectly fine for simple operations like fetching a user profile or updating a single database row. The latency is minimal and the user needs the data immediately to continue.

However, synchronous flows become dangerous when you introduce external dependencies. If your Laravel controller calls the Shopify Admin API to update 500 products during a standard HTTP request, your PHP worker is stuck. If Shopify takes three seconds to respond, that worker cannot serve any other users for those three seconds. Under heavy load, your worker pool will exhaust itself. This leads to 504 Gateway Timeout errors and a broken experience.

The fire-and-forget power of asynchronous logic

Asynchronous communication decouples the request from the processing. The client sends a message or triggers an event and immediately receives a response. The actual work happens "out of band" in a separate process or at a later time.

This is more like sending an email. You hit send and immediately go back to your day. The recipient reads and processes the message whenever they are available. In a technical stack, this is achieved using message queues like Redis or Amazon SQS, or a dedicated broker such as RabbitMQ.

When you move a task to an asynchronous worker, the user gets an instant "Success" message. The heavy processing happens in the background. This architecture is essential for:

Sending transactional emails.
Generating PDF reports or data exports.
Communicating with third-party APIs like Shopify or Stripe.
Running complex AI agents or RAG pipelines.

Laravel queues and background jobs

Laravel provides a robust implementation of asynchronous processing through its Queue system. Instead of performing a slow task in your controller, you dispatch a "Job."

// Synchronous (Bad for slow tasks)
public function store(Request $request) {
    $order = Order::create($request->all());
    Mail::to($user)->send(new OrderConfirmed($order)); // Waits for SMTP
    return response()->json($order);
}

// Asynchronous (Scalable)
public function store(Request $request) {
    $order = Order::create($request->all());
    ProcessOrderEmail::dispatch($order); // Returns immediately
    return response()->json($order);
}

By using dispatch(), you push a payload into Redis. A separate process, managed by a tool like Laravel Horizon, picks up the job and executes it. This keeps your web-facing workers free to handle more incoming traffic. If the email server is down, the job stays in the queue and retries later. This level of resilience is impossible in a strictly synchronous world.

Shopify webhooks: the event-driven standard

For e-commerce developers, understanding asynchronous communication is mandatory when working with Shopify. Shopify uses webhooks to notify your application of events like orders/create or products/update.

Webhooks are fundamentally asynchronous. Shopify does not wait for your app to process the entire order. It sends the POST request and expects a 2xx response within five seconds. If your code tries to run complex inventory logic or sync data to an ERP synchronously within that webhook route, you risk timing out. Shopify then retries the failed delivery up to eight times over roughly four hours, which can mean duplicate processing if your handler is not idempotent. Worse, if your endpoint keeps failing, Shopify removes the webhook subscription entirely, and you stop receiving events until you re-register it.

The best practice for agentic commerce on Shopify is to receive the webhook, validate the signature, dispatch a Laravel Job, and return the response immediately. This ensures your app stays responsive and Shopify remains happy with your delivery rates.

Infrastructure impact and DevOps considerations

Moving to an asynchronous architecture changes how you manage your infrastructure. In a synchronous world, you scale your web servers to handle peak traffic. In an asynchronous world, you scale your workers.

Tools like Coolify and Docker make it easier to manage these separate services. You can run your web container on one set of resources and your worker containers on another. If you have a massive spike in background jobs, you can spin up more workers without affecting the performance of your main website.

For cross-service communication, Google Cloud Tasks is a strong alternative to a self-hosted queue. It dispatches HTTP callbacks to any endpoint with built-in rate limiting, scheduling, and retries. This is particularly useful when building an API gateway for AI stacks, where different microservices need to talk to each other without blocking the main user flow.

When to choose sync vs async

Choosing the right pattern depends on the user's expectations and the reliability of the task.

Feature	Synchronous	Asynchronous
User Experience	Immediate feedback required.	Background processing is okay.
Data Integrity	Result needed for next step.	Eventual consistency is okay.
Reliability	Fails if the connection breaks.	Retries automatically on failure.
Complexity	Simple code structure.	Requires queue management and workers.
Example Use Case	Login validation, viewing a cart.	Order fulfillment, image processing.

Use synchronous when:

The operation is extremely fast (under 100ms).
The user cannot proceed without the result of the operation.
You are performing a simple read/write to your primary database.

Use asynchronous when:

You are calling an external API.
The task takes more than 200ms to complete.
The task can fail and needs to be retried.
You are performing bulk operations on large datasets.

Takeaways

Designing for high performance means moving away from a single-threaded mindset. By embracing asynchronous communication, you build systems that are more reliable and easier to scale.

Identify bottlenecks: Use tools like Laravel Telescope or OpenTelemetry to find slow controller actions.
Offload everything: If it doesn't need to happen right now, push it to a queue.
Handle webhooks fast: Always return a 200 response to Shopify immediately and process the logic later.
Monitor your workers: Use dashboards like Laravel Horizon to track queue health and failure rates.
Design for retries: Ensure your background jobs are idempotent, meaning they can run multiple times without causing side effects.

How are you currently handling long-running API tasks in your Laravel or Shopify application?

Solutions architect vs forward deployed engineer

Mon, 15 Jun 2026 00:00:00 GMT

Engineering is no longer just about writing code in a dark room. It is about where that code sits in the customer's value chain — and the difference between a solutions architect and a forward deployed engineer decides who is accountable when it lands there.

Many organizations invest millions in complex software platforms like Shopify Plus or custom Laravel ecosystems only to realize they cannot bridge the gap between a sales demo and a running production system. The implementation phase becomes a graveyard of missed requirements and technical debt. Sales cycles stall because the "how" is missing. This is exactly where the two roles diverge.

While both roles sit at the intersection of engineering and customer success, they solve fundamentally different problems. One builds the blueprint to ensure the house will stand. The other moves into the construction site to ensure the pipes actually connect to the city main. Understanding which role fits your project — or your career — requires a deep dive into the mechanics of technical delivery.

The design blueprint: defining the Solutions Architect

The Solutions Architect is the strategic engine of a technical engagement. Their primary goal is to design a scalable, low-risk implementation architecture that maps customer business requirements to technical capabilities. They operate in the space between a "yes" from the buyer and a "go-live" from the developers.

An architect focuses on the macro. They evaluate how a new Laravel development project will integrate with existing legacy databases or how a Shopify app will interact with a third-party ERP. Their deliverables are not usually production pull requests. Instead, they produce sequence diagrams, entity-relationship diagrams (ERDs), and security compliance documents.

They spend their days in design workshops and advisory conversations. They must convince a CTO that the proposed cloud infrastructure is secure while proving to the marketing manager that the data flow will support their holiday campaigns. The Solutions Architect owns the design. They ensure that if the plan is followed, the system will be robust, secure, and performant. However, once the blueprint is approved, they often move on to the next challenge, handing the execution to a delivery team.

The boots on the ground: defining the Forward Deployed Engineer

The Forward Deployed Engineer is a hybrid creature born from the world of high-stakes enterprise software. Pioneered by Palantir to embed engineers in messy, sensitive customer data environments, the FDE is a full-stack engineer who works directly inside the customer's environment. They do not just advise on how to build the system. They write the production code that makes it real.

If a Solutions Architect is a designer, the FDE is a lead engineer who is also a specialized diplomat. They inherit the "messy" reality of customer data, undocumented APIs, and internal politics. When a RAG pipeline fails because the customer's vector database has inconsistent metadata, the FDE is the one debugging the ingestion script at 2:00 AM.

The FDE owns the outcome. They are measured by whether the system actually works in production and delivers business value. This role requires a high tolerance for ambiguity and the ability to pivot when a design meets the harsh reality of a production environment. They are the ultimate feedback loop. They find the bugs and missing features in the core product and push those requirements back to the internal product teams.

Core differences: strategic design vs production ownership

The divide between these roles can be summarized by where they sit in the software development lifecycle (SDLC) and who owns the risk.

Feature	Solutions Architect	Forward Deployed Engineer
Primary output	Blueprints, PoCs, design docs	Production code, integrations, live systems
Lifecycle stage	Pre-sales and discovery	Implementation and post-launch
Code ownership	Reference implementations only	Direct commits to customer repos
Main stakeholder	CTOs and architects	Engineering managers and devs
Goal	Risk reduction and scalability	Successful deployment and value delivery

A Solutions Architect might design a multi-region deployment strategy on Google Cloud Platform (GCP) for a global e-commerce brand. They will specify the load balancers, the database replication strategy, and the caching layers. A Forward Deployed Engineer will then take that design and actually write the Terraform scripts, configure the Docker containers, and debug the latency issues that appear when the first 10,000 users hit the site.

The architect operates at a level of abstraction. The FDE operates at a level of execution. This is why FDEs are often found in companies selling complex, horizontal platforms that require significant customization to be useful.

Real-world scenarios: from Laravel to AI agents

To see how these roles interact, consider the deployment of an agentic AI system for a large retail client. This project involves a complex stack: a Laravel backend, a Shopify frontend, and an AI orchestration layer using Claude and MCP.

The Solutions Architect starts the project. They define how the Claude MCP dev tools will interface with the client's private product catalog. They map out the authentication flow to ensure that the AI agent cannot access sensitive customer financial data. They produce a high-level technical document that the client's security team signs off on.

Once the "paperwork" is done, the Forward Deployed Engineer moves in. They realize the client's product catalog API is significantly slower than promised. The FDE writes a custom Redis caching layer in the Laravel middleware to solve this. They spend three days pairing with the client's frontend team to integrate the AI chat widget into a bespoke Shopify theme. They are the ones who realize the RAG system needs a different chunking strategy for the specific type of PDF manuals the client uses. They fix it in the code.

In this scenario, the architect ensured the project was safe and technically sound from a high level. The FDE ensured that the specific, messy details of this one client did not sink the entire implementation.

Hiring the right talent: which one do you need?

Choosing between hiring a Solutions Architect or a Forward Deployed Engineer depends on your product's complexity and your business model.

If you are a consultancy or a software vendor with a product that is "plug-and-play" but requires significant integration planning, a Solutions Architect is your best bet. They can handle five or six customers simultaneously, providing the high-level guidance needed to keep projects moving without getting bogged down in any single code repository.

However, if you are building "deep tech" or complex platforms like AI-driven supply chain tools or custom enterprise ERPs, you need Forward Deployed Engineers. These products are never truly "plug-and-play." They require an engineer to sit with the customer for months, adapting the product to the data.

From a candidate perspective, the choice depends on your preference for the "blank page" versus the "broken system." Architects enjoy the creative challenge of designing from scratch and the variety of working across many industries. FDEs enjoy the satisfaction of shipping code that solves a tangible, immediate problem for a human being they interact with every day. If you are weighing engineering tracks more broadly, the same blueprint-versus-operations split shows up in SRE vs platform engineer and in cloud engineer vs DevOps engineer.

Takeaways

Solutions Architects focus on the "what" and "why" of a system. They provide the strategic design and reduce technical risk during the early stages of a project.
Forward Deployed Engineers focus on the "how." They are hands-on coders who live inside the customer's environment to ensure a system actually reaches production.
Ownership is the main divider. Architects own the design document. FDEs own the live production outcome.
Feedback loops differ. Architects improve the company's "standards." FDEs improve the company's "product" by finding real-world bugs.
Skill sets overlap but diverge at the keyboard. Both need strong communication skills, but the FDE must be a top-tier debugger and implementation specialist.

When a project fails, it is rarely because of a bad design or a bad implementation in isolation. It is usually because there was a gap between the two. The best technical organizations find a way to make these roles work in tandem, ensuring the blueprint is sound and the builders have the tools they need to execute.

If you are currently scaling a technical team, are you optimizing for the number of designs approved or the number of systems successfully deployed into production? If you need a Forward Deployed Engineer to close that gap, here's how I help teams ship.

REST vs gRPC: two API philosophies

Sun, 14 Jun 2026 00:00:00 GMT

Choosing between REST and gRPC is not just a choice of protocol. It is a choice of architectural philosophy that shapes how your services communicate. Pick the wrong one for a high-traffic microservice environment and you will spend your time fighting network latency and rising cloud costs as JSON payloads bloat under load. Force a binary protocol onto a public-facing web client and you break the very interoperability that makes the modern web work.

The choice between Representational State Transfer (REST) and gRPC (a Google-built RPC framework whose name is a recursive joke — "gRPC Remote Procedure Calls") is fundamentally a trade-off between human readability and machine efficiency. While REST has been the undisputed champion of the web for decades, gRPC has rapidly become the preferred choice for internal service-to-service communication. Understanding the nuances of these two philosophies is essential for any engineer building scalable systems in 2026.

The mechanical advantage of gRPC

At its core, gRPC is built to be fast. It achieves this by moving away from the text-based nature of REST and embracing a binary format called Protocol Buffers (Protobuf). In a typical REST interaction, your server takes an object, serializes it into a JSON string, and sends it over the wire. The receiving server then parses that string back into an object. This process is CPU-intensive and creates large payloads because JSON includes every key name in every single message.

gRPC bypasses this overhead. Protobuf is a strongly typed binary serialization format. Because the schema is defined in advance using a .proto file, the messages do not need to include field names. Instead, they use small numeric tags to identify each field. The payload savings depend heavily on data shape — numeric and structured data compresses dramatically, often several times smaller than the equivalent JSON, while large free-text fields see less benefit. Either way, binary Protobuf parsing is typically much faster than JSON parsing, which meaningfully cuts serialization CPU in high-throughput environments.

Another technical pillar of gRPC is its reliance on HTTP/2. While many REST implementations still run on HTTP/1.1, gRPC requires HTTP/2. This brings several advantages like request multiplexing. In HTTP/1.1, a client effectively sends one request at a time over a connection, which leads to application-level head-of-line blocking. HTTP/2 multiplexes multiple requests and responses over a single TCP connection, removing that HTTP-layer blocking. (TCP-level head-of-line blocking still exists under packet loss — the problem HTTP/3 and QUIC were designed to solve.) This efficiency is critical for modern API gateway architectures that handle thousands of concurrent requests.

The universality of REST

If gRPC is so much faster, why hasn't it replaced REST entirely? The answer lies in the browser. REST was born from the architecture of the web itself. It treats every piece of data as a resource that can be accessed via standard HTTP verbs like GET, POST, PUT, and DELETE. This resource-oriented approach makes it incredibly intuitive and easy to consume.

Every web browser, every language, and every command-line tool like curl understands REST. If you are building a public API that third-party developers will use, REST is the only logical choice. The barrier to entry is almost zero. A developer can open their browser console and immediately see what your API returns in a human-readable format. This "inspectability" is a massive advantage for debugging and onboarding.

REST is also highly flexible. It does not require a strict contract to function. While tools like OpenAPI (Swagger) provide structure, a REST API can still evolve loosely. This flexibility is perfect for startups and small teams that need to iterate quickly on their digital presence. When you are deploying a new SaaS product on Coolify or Docker, the simplicity of a RESTful interface often outweighs the performance gains of gRPC during the early stages of growth.

Schema-first vs resource-first development

One of the most significant differences between these two philosophies is how you actually write code. gRPC forces a "contract-first" approach. You must define your service and your message types in a .proto file before you write a single line of application logic.

// A typical gRPC service definition
service ProductService {
  rpc GetProduct (ProductRequest) returns (ProductResponse);
}

message ProductRequest {
  string id = 1;
}

message ProductResponse {
  string name = 1;
  double price = 2;
}

Once this file is defined, gRPC tools generate client and server stubs in the language of your choice. This provides strong typing across different services. If you have a Go backend talking to a Python microservice, the Protobuf contract ensures both sides agree on the data structure. This eliminates a whole class of bugs caused by missing fields or incorrect types in JSON.

REST typically follows a "resource-first" or "implementation-first" approach. You define your routes and your controllers, and then you might generate documentation later. While this allows for faster prototyping, it can lead to "API drift" where the documentation and the actual implementation become out of sync. In a large microservice ecosystem, this lack of strict contracts can become a maintenance nightmare.

Streaming and real-time capabilities

Another area where gRPC shines is in its native support for streaming. Because it is built on HTTP/2, gRPC supports four types of communication:

Unary: A single request and a single response (the typical REST pattern).
Server streaming: The client sends one request and the server sends back a stream of messages.
Client streaming: The client sends a stream of messages and the server responds once.
Bidirectional streaming: Both client and server send a stream of messages simultaneously.

This makes gRPC the ideal candidate for real-time applications like chat services, stock tickers, or IoT telemetry feeds. In the world of REST, you would typically need to reach for WebSockets or Server-Sent Events (SSE) to achieve similar results. These are often treated as "add-ons" to the API rather than a core part of the protocol. With gRPC, streaming is a first-class citizen.

Imagine a system that needs to process a massive dataset of vector embeddings for an AI application. A client could stream the data to the server, and the server could stream back the results as they are processed. This reduces the memory footprint on both ends because the entire dataset never needs to be loaded into RAM at once.

Choosing between REST and gRPC for 2026

The decision between REST and gRPC should be based on your "consumer." If your consumer is a human developer or a web browser, choose REST. The ecosystem of tools, from Postman to Chrome DevTools, is simply too mature to ignore. REST is the language of the public web.

If your consumer is another server or a performance-constrained device like a mobile phone or an IoT sensor, gRPC is usually the superior choice. The performance gains in serialization and the reduced network overhead will save you money on bandwidth and compute. In a modern architecture, it is common to see both living together. A RESTful API gateway handles incoming traffic from the internet, but then it communicates with internal microservices using gRPC. This "hybrid" approach gives you the best of both worlds: broad interoperability and extreme internal performance.

As we move further into the era of AI-integrated development, the efficiency of these data pipelines will become even more critical. Large language models and agentic systems require low-latency access to data, making gRPC a natural fit for the "inner loop" of AI infrastructure.

Takeaways

Performance: gRPC is significantly faster than REST due to binary serialization (Protobuf) and HTTP/2 multiplexing.
Payload size: Protobuf messages are smaller than JSON because they omit redundant field names and use compact binary encoding, though the gain depends on data shape.
Contract-first: gRPC requires a strict schema definition, leading to better type safety and less "API drift" in large systems.
Interoperability: REST remains the king of the public web and browser-based clients due to its human-readable JSON format and native browser support.
Streaming: gRPC supports native bidirectional streaming, making it ideal for real-time data pipelines and IoT.
Hybrid approach: The most robust modern architectures use REST for the public-facing edge and gRPC for internal service-to-service communication.

If you are building for the web, start with REST. If you are building for the cloud at scale, master gRPC.

Are you prepared to handle the added complexity of a contract-first architecture in exchange for smaller payloads and faster serialization? If you're designing that service mesh for production, here's how I help teams ship it.

Serverless vs containers: the 2026 engineering guide

Sun, 14 Jun 2026 00:00:00 GMT

Developers are drowning in YAML files and server patches while the business demands faster shipping cycles. Managing infrastructure often feels like a full-time job that has nothing to do with writing actual code.

When your application hits a sudden traffic spike during a flash sale or a viral product launch, the "504 Gateway Timeout" becomes your worst enemy. If your infrastructure cannot scale in seconds, you lose revenue and customer trust. The choice between Serverless vs Containers is no longer just a technical preference. It is a strategic decision that determines your operational overhead and your ability to stay lean in a competitive market.

In 2026, the lines between these technologies have blurred. We see the rise of serverless containers and event-driven architectures that mix both worlds. This guide breaks down the engineering substance of Serverless vs Containers to help you decide where to host your next Laravel application or Shopify integration.

Understanding the architectural split

The debate over Serverless vs Containers is often simplified into "no servers" vs "virtual servers." In reality, the difference lies in the abstraction layer.

Serverless (often referred to as Function-as-a-Service or FaaS) abstracts the entire execution environment. You upload code, and the provider (AWS Lambda, Google Cloud Functions) handles the trigger, the scaling, and the underlying OS. It is fundamentally event-driven. Your code stays dormant until an HTTP request, a file upload, or a database change wakes it up.

Containers (Docker, Kubernetes) package the entire runtime environment. This includes the application code, libraries, and system dependencies. You have full control over the operating system version and the configuration. While containers run on infrastructure you manage (or semi-manage via Fargate or Cloud Run), they are typically "always on" or require specific scaling rules to spin up and down.

Feature	Serverless (FaaS)	Containers (Docker/K8s)
Control	Minimal; provider-managed	High; you define the image
Scaling	Automatic per request	Orchestrator-managed
State	Strictly stateless	Can be stateful
Runtime	Limited to provider support	Anything that can be Dockerized
Timeout	Usually < 15 minutes	No inherent execution limit

Serverless: the high-speed execution engine

Serverless is the ultimate tool for developers who want to ignore infrastructure. The primary advantage is the "scale-to-zero" model. When no one is using your app, you pay nothing. When traffic surges, the provider spins up new instances of your function automatically — within account concurrency limits (AWS Lambda defaults to 1,000 concurrent executions per region, raisable on request, and scales out at roughly 1,000 new environments every 10 seconds).

However, this comes with the "cold start" penalty. When a function hasn't been used recently, the provider must provision a container and boot your runtime. Lightweight runtimes like Node.js and Go start fast natively, and provisioned concurrency keeps instances warm. Heavier runtimes feel it more — which is why AWS built SnapStart (initially for Java, later .NET and Python) to snapshot an initialized runtime and cut cold starts dramatically. For frameworks like PHP, cold starts remain a factor that requires careful architectural planning.

Serverless is perfect for "glue code." If you are building a Shopify app architecture that needs to process webhooks or resize images on the fly, serverless functions are incredibly efficient. They handle the bursty, unpredictable nature of webhooks without requiring a dedicated server to sit idle 99% of the time.

Containers: the universal blueprint

Containers offer a level of portability that serverless cannot match. A Docker image that runs on your local machine will run exactly the same way on AWS ECS, Google Cloud Run, or a self-hosted Coolify instance.

For long-running processes or heavy compute tasks, containers are the standard. If your application needs to maintain a persistent WebSocket connection, perform heavy machine learning inference, or run long-running cron jobs that exceed 15 minutes, containers are the only viable path.

The primary drawback is the "operational tax." Even with managed services like AWS Fargate, you are still responsible for your Dockerfiles, image security scanning, and ensuring your containers don't run out of memory. You are managing the environment, even if you aren't managing the physical hardware.

# A typical Laravel Dockerfile for a containerized approach
FROM php:8.4-fpm-alpine

# Install system dependencies
RUN apk add --no-cache libpng-dev libzip-dev zip unzip git

# Install PHP extensions
RUN docker-php-ext-install pdo_mysql gd zip

# Set working directory
WORKDIR /var/www

# Copy application code
COPY . .

# Install composer dependencies
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
RUN composer install --no-dev --optimize-autoloader

CMD ["php-fpm"]

Technical head-to-head: latency and cost

When comparing Serverless vs Containers, cost is the most common point of confusion. Serverless looks cheaper because you only pay for what you use. This is true for low-traffic or spiky applications.

However, at a certain threshold of sustained traffic, containers become more cost-effective. Once your application is processing thousands of requests per minute consistently, the per-invocation cost of serverless starts to exceed the monthly cost of a reserved container instance.

Latency is another critical trade-off. Containers offer "warm" execution. Since the process is already running, the time-to-first-byte (TTFB) is consistent. Serverless performance can be a "jittery" experience. One request might take 30ms while the next (a cold start) takes several hundred milliseconds. For an interactive admin dashboard, this inconsistency can frustrate users — and it ties directly into how you architect stateless vs stateful apps, since serverless forces a strictly stateless design.

Laravel and Shopify: where to host?

For a modern Laravel application, the choice often comes down to Laravel Vapor (Serverless) vs Docker on Cloud Run/Coolify (Containers).

The case for serverless Laravel

If you are building a SaaS with unpredictable growth, Laravel Vapor is a powerhouse. It handles the complexity of deploying a full-stack PHP framework to AWS Lambda. It manages your assets on S3 and handles database scaling. It is the "easy button" for high-scale Laravel apps that don't want a dedicated DevOps engineer.

The case for containerized Laravel

If your application is "always on" and involves heavy background processing (like syncing thousands of products for a Shopify store), containers are superior. Using Docker allows you to run your HTTP layer, your queue workers, and your scheduler in a cohesive environment. This setup matches your local development environment perfectly, reducing the "it works on my machine" bugs.

The 2026 hybrid reality

Modern engineering has moved past the binary choice of Serverless vs Containers. We are now in the era of serverless containers. Services like Google Cloud Run and AWS App Runner allow you to package your app as a container but enjoy the autoscaling and pay-per-use benefits of serverless.

You can deploy your main Laravel API as a container on Cloud Run, which scales to zero when idle. Simultaneously, you can use pure serverless functions (like AWS Lambda) to handle specific, isolated tasks like PDF generation or sending transactional emails.

This hybrid approach allows you to place the right workload in the right environment. Your core business logic stays in a predictable container, while your bursty, auxiliary tasks scale independently in a serverless environment.

Takeaways

Choosing between Serverless vs Containers requires an honest assessment of your team's skills and your application's traffic patterns.

Choose Serverless if your traffic is spiky, you have a small team with no DevOps experience, and your tasks are short-lived (under 15 minutes). It is the fastest path from code to production for event-driven systems.
Choose Containers if you have steady, high-volume traffic, require specific OS libraries, or need long-running background processes. It offers the best price-to-performance ratio for "always-on" applications.
Go Hybrid if you want the best of both worlds. Use a serverless container platform like Cloud Run for your web app and FaaS for your side effects.
Laravel developers: Vapor is great for AWS-centric teams, but Dockerized deployments on platforms like Coolify offer more control and lower long-term costs for many regional businesses.
Shopify developers: Use serverless functions for webhooks to prevent bottlenecks during peak sales events like Black Friday, but keep your admin UI in a container for consistent speed.

If you had to migrate your core API today, would you prioritize the absolute control of a Dockerfile or the operational freedom of an event-driven function? Here's how I help teams make that call.

Replication vs backup: why Laravel needs both

Sat, 13 Jun 2026 00:00:00 GMT

You deploy a breaking database migration that drops a critical column. Your production database has real-time replication set up to three different nodes across two regions. Within milliseconds, that destructive change propagates across every single one of your "safety" copies. You have zero downtime, but you have no data left. This is the moment you realize that replication is not a backup.

Engineering teams often conflate high availability with data durability. While both are pillars of a robust infrastructure, they solve fundamentally different problems. Replication protects you from hardware failure and latency. Backups protect you from logic errors, corruption, and human mistakes. If you are building a Laravel application or a high-volume Shopify Plus integration, understanding where one ends and the other begins is the difference between a minor incident and a company-ending event.

The fundamental trade-off: speed vs history

Replication is about continuity. Its primary goal is to ensure that if your main database server vanishes, a secondary node is ready to take over immediately. This is measured in Recovery Time Objective (RTO). In a well-tuned system, failover happens in seconds. You are mirroring every INSERT, UPDATE, and DELETE as they happen.

Backups are about recovery. Their goal is to provide a safe version of your data from a specific point in history. If a bug corrupts your inventory levels at 2:00 PM, a backup from 1:00 PM is your only lifeline. Backups are usually stored as compressed snapshots on detached storage like Amazon S3 or Google Cloud Storage.

Feature	Replication	Backup
Primary Goal	High Availability (HA)	Disaster Recovery (DR)
Data State	Real-time / Live	Historical / Snapshot
Propagation	Immediate (including errors)	None (isolated from live changes)
Storage Cost	High (hot, identical hardware)	Low (cold, compressed snapshots)
Recovery Speed	Seconds to Minutes	Minutes to Hours

Why replication faithfully mirrors your mistakes

The greatest strength of replication is its greatest weakness. It is designed to be a mirror. If you execute a truncate command on your primary database, the replication protocol assumes this was intentional. It will purge that data from your replicas before you can even hit "Ctrl+C" on your terminal.

I have seen developers rely solely on RDS Read Replicas as their "safety net." When a rogue queue job began overwriting customer email addresses with null values, the replicas updated instantly. Without a point-in-time backup, those original emails were gone forever. Replication provides infrastructure resilience, not data integrity.

For a production-grade Coolify self-hosted SaaS, you must separate your concerns. Use replication to scale your reads and handle node failures. Use automated, encrypted backups to ensure you can roll back to a known-good state.

Implementing replication in Laravel

Laravel handles read/write splitting through native configuration. By defining read and write connections in your config/database.php, the framework automatically routes SELECT statements to your replicas while sending INSERT and UPDATE statements to the primary. This is the same connection layer you tune when designing a multi-tenant Laravel architecture.

'mysql' => [
    'read' => [
        'host' => [
            '192.168.1.10', // Replica 1
            '192.168.1.11', // Replica 2
        ],
    ],
    'write' => [
        'host' => [
            '192.168.1.1', // Primary
        ],
    ],
    'sticky' => true,
    'driver' => 'mysql',
    // ... other settings
],

The sticky option is critical here. It ensures that if you write a record during a request, any subsequent reads during that same request will come from the primary. This avoids the "read-after-write" lag where a replica might be a few milliseconds behind the primary, causing your application to appear as if the data vanished.

Shopify Plus and the sync fallacy

In the world of Shopify Plus, many developers build "replication-style" sync engines. They listen for orders/create or products/update webhooks and mirror that data into a local Laravel database. This is a powerful pattern for building custom reporting or complex agentic commerce workflows.

However, this local database is often mistaken for a backup. If an admin user deletes a collection of products in the Shopify admin panel, Shopify fires a webhook. Your Laravel app receives that webhook and promptly deletes those products from your local DB to stay "in sync."

If you do not have a separate backup strategy that creates daily snapshots of your local DB, your local data is just as ephemeral as the live Shopify data. To build true resilience, you must store historical JSON payloads of those Shopify resources in a versioned storage system like S3. This allows you to reconstruct your state even if the live sync deletes everything.

Cloud infrastructure and the cost of availability

Managing replication manually is a DevOps nightmare. For most Laravel applications, using managed services like AWS RDS or Google Cloud SQL is the correct move. These services handle the binary log replication, failover orchestration, and monitoring out of the box.

When configuring your cloud DB, you will encounter "Multi-AZ" (AWS) or "High Availability" (GCP) settings. A single-standby Multi-AZ deployment uses synchronous replication, and it roughly doubles your database cost because you are running a standby instance in a second Availability Zone that does nothing but wait for the primary to die. Note that this standby cannot serve read traffic — to scale reads you need separate read replicas (or RDS Multi-AZ DB clusters), not the HA standby.

Backups, by contrast, are extremely cheap. Storing 500GB of compressed dumps in S3 standard runs a few dollars a month; archival tiers like Glacier Deep Archive drop that to cents, at the cost of multi-hour retrieval. The cost of a backup is not in the storage; it is in the testing. A backup that has never been restored is just a collection of random bits. You must automate your restore tests. I recommend using Coolify and Docker to spin up ephemeral environments where you can periodically test your backup restoration process without touching production.

Takeaways

Replication is for uptime. It allows your app to stay online during hardware failures or network partitions.
Backups are for survival. They are your only defense against data corruption, malicious attacks, and developer errors.
Replication propagates bugs. If your code breaks the data, the replica will break just as fast.
Laravel supports read/write splitting. Use the sticky configuration to prevent consistency issues during web requests.
Shopify webhooks are not backups. A synchronized local database is a replica, not a historical record.
Test your restores. Automate a process to verify that your backup snapshots actually work.

If you had to choose between a system with 99.99% uptime but no backups, and a system with 95% uptime but hourly backups, which one would keep you from losing your business? If you're architecting that resilience layer for production, here's how I help teams ship it.

RAG vs fine-tuning: choosing your AI architecture

Fri, 12 Jun 2026 00:00:00 GMT

Large language models are only as good as the information they can access. You build a custom application and realize the base model knows nothing about your internal documentation or yesterday's product launch. It starts making things up. This hallucination problem is the biggest hurdle for developers moving from a prototype to production, and it is exactly where the RAG vs fine-tuning decision gets made.

The tension usually boils down to two distinct paths. You can either give the model a search engine to find the right information at runtime, or you can retrain the model to bake that information directly into its weights. These two methods are Retrieval-Augmented Generation (RAG) and fine-tuning.

Choosing the wrong one leads to wasted engineering hours and high infrastructure bills. A RAG system might be too slow for a high-traffic API. A fine-tuned model might become obsolete the moment you update your pricing page. This guide breaks down the technical nuances of both approaches to help you decide which architecture fits your next build.

Understanding RAG as the open-book exam

Retrieval-Augmented Generation is essentially giving an LLM an open-book exam. Instead of relying on the model to remember everything from its original training, you provide a set of relevant documents along with the user prompt. The model then uses this provided context to generate an accurate answer.

The technical workflow involves a few moving parts. First, you convert your documents into numerical representations called embeddings. You store these in a vector database like pgvector or Pinecone. When a user asks a question, your system performs a semantic search to find the most relevant "chunks" of text. These chunks are then injected into the prompt window of the LLM.

RAG is the gold standard for applications where data changes frequently. If you are building a support bot for a Shopify store, you need it to know about current inventory levels. Retraining a model every time a product sells out is impossible. With RAG, you just update the vector index. You can read more about avoiding common pitfalls in this space in our guide on 7 RAG mistakes in production.

Fine-tuning as internalized knowledge

Fine-tuning is the process of taking a pre-trained model and continuing its training on a smaller, specialized dataset. You are effectively changing the "brain" of the model by adjusting its internal weights. This makes the model inherently understand the patterns, tone, and specific terminology of your domain without needing external documents for every query.

This approach is less about adding new facts and more about teaching the model how to act. It shines when you need a consistent style, tone, or response pattern that prompting alone cannot pin down reliably. (For strict JSON shape, reach for structured outputs or constrained decoding first — every major provider now guarantees schema-valid output at inference time, no training run required.)

Fine-tuning is also the go-to for specialized industries like legal or medical tech. The model learns the specific "language" of the field. However, fine-tuning has a major drawback. It creates a static snapshot of knowledge. If the underlying facts change, the model remains stuck with its training data until you run another expensive training cycle.

The latency and throughput battle

Performance is where these two architectures diverge sharply. RAG adds several steps to every single request. Your application must generate an embedding for the query, search the vector database, and then send a much larger prompt (containing the retrieved text) to the LLM. Each of these steps adds milliseconds or even seconds to the total response time.

For high-traffic applications, this latency can be a deal-breaker. The retrieval step also means standing up and querying a vector store alongside your app — see picking the right RAG stack for how that choice shapes both speed and cost.

Fine-tuning offers much lower latency at runtime. There is no external retrieval step. The prompt remains short because the model already "knows" the context. This makes fine-tuned models ideal for real-time applications or high-volume background tasks like sentiment analysis or lead scoring.

Infrastructure and cost considerations

The cost of RAG is largely operational. You pay for the storage and querying of the vector database. You also pay more for LLM tokens because your prompts are significantly longer. Over millions of requests, these "context tokens" add up quickly. RAG is cheaper to set up but can become more expensive at extreme scales.

Fine-tuning has a high upfront cost. You need to curate a high-quality dataset, which often requires human labeling. You also need significant GPU power to perform the training. Once the model is trained, however, your per-query costs are lower. The prompts are shorter and you do not need to maintain a complex retrieval pipeline.

Managing the infrastructure for these systems requires a solid DevOps foundation. The deeper split is operational: fine-tuning lives in the training world (GPUs, datasets, MLOps), while RAG lives in the inference-time data-pipeline world. Decide which your team is actually equipped to run.

Data privacy and governance

For enterprise clients, data privacy is often the deciding factor. RAG offers superior data governance. Since the information is retrieved from your own database at runtime, you can apply standard access controls. You can ensure a user only retrieves documents they are authorized to see. The LLM never "learns" the data permanently.

Fine-tuning is riskier in this regard. If you train a model on sensitive customer data, that information is baked into the model weights. Membership inference and training-data extraction attacks are well-documented ways to pull memorized data back out. This makes it hard to "delete" a user's data from a fine-tuned model short of retraining, which can lead to compliance issues with regulations like GDPR.

The hybrid case: RAG and fine-tuning together

In 2026, the most sophisticated systems are not choosing one over the other. They combine both. You might fine-tune a smaller, cheaper model (like a Llama variant) to understand your company's specific API schemas and brand voice. Then, you use RAG to give that model access to live data.

This combination allows the model to be both fast and accurate. The fine-tuning handles the "how" (formatting and style) while RAG handles the "what" (current facts and data). This is particularly effective when working with Claude and the Model Context Protocol (MCP), where the model can use specific tools to fetch data while maintaining a pre-trained understanding of the environment.

Takeaways

Choosing between RAG and fine-tuning depends on your specific goals for data freshness, latency, and budget. Here are the core pillars to remember:

Use RAG for knowledge: If your data changes frequently or you need to cite sources, RAG is the standard choice. It is easier to update and more transparent.
Use fine-tuning for behavior: If you need specific output formats, a unique brand voice, or low-latency responses, fine-tuning is the way to go.
Evaluate your infrastructure: RAG requires a robust data pipeline and vector database. Fine-tuning requires specialized training data and GPU resources.
Consider privacy early: RAG is generally safer for handling sensitive or permission-based data because the model does not memorize the information.
Think hybrid for scale: Combining a fine-tuned model for reasoning with a RAG pipeline for facts offers the most robust performance for complex applications.
Monitor costs: Watch your token usage in RAG systems as context windows grow. Conversely, budget for periodic retraining if you choose the fine-tuning path.

Is your current AI architecture bottlenecked by the speed of retrieval or the accuracy of the model's internal knowledge? If you're deciding between these paths for a real product, here's how I help teams ship it.

Rate limiting vs throttling

Fri, 12 Jun 2026 00:00:00 GMT

Your server is screaming, not because of a bug, but because of a success. A sudden viral tweet or a massive batch of automated requests has flooded your API. Without rate limiting or throttling in place, your database locks up, your CPU pegs at 100%, and the site goes down for everyone.

This is the nightmare scenario for any engineering team. To prevent it, you need to control the flow of traffic. However, engineers often use the terms "rate limiting" and "throttling" interchangeably. While they both deal with traffic management, they solve the problem using different philosophies.

Choosing the wrong one can lead to a degraded user experience or, worse, a complete system failure under pressure. This guide breaks down the technical nuances of both strategies and how to implement them in modern stacks like Laravel and Shopify.

The traffic surge crisis

The problem starts with resources. Every server has a finite amount of memory, compute, and bandwidth. When requests come in faster than your system can process them, a queue builds up. Once that queue exceeds the system's capacity, the service fails.

This is not just about malicious actors or DDoS attacks. It is often about "noisy neighbors" in a multi-tenant environment or a poorly optimized loop in a client-side application. I have seen production environments crash simply because a mobile app's "retry" logic was too aggressive during a minor network hiccup.

Rate limiting and throttling are your tools to enforce discipline. They ensure that no single user or service can monopolize your infrastructure. They are the gatekeepers of your cloud infrastructure.

Defining rate limiting: the hard stop

Rate limiting is a policy-based approach. It defines a strict contract: "You are allowed exactly X requests per Y amount of time." Once a user reaches that limit, the gate shuts.

When a request exceeds the limit, the server immediately rejects it. This is typically done by returning an HTTP 429 "Too Many Requests" status code. The server does not spend any more resources on that request. It does not look up data in the database. It just says "no."

Why use rate limiting?

Rate limiting is primarily about fairness and security. It protects your API gateway from abuse. If you are running a SaaS, you might have different tiers. A free user gets 60 requests per minute, while a premium user gets 1,000.

Rate limiting is easy to communicate to users. They can check their response headers (like X-RateLimit-Limit and X-RateLimit-Remaining) to see exactly where they stand. It is a binary state: you are either within your limit or you are blocked.

Defining throttling: the gentle brake

Throttling is a runtime behavior designed to "shape" traffic. Instead of a hard rejection, throttling slows down the processing of requests. Think of it like a funnel. You can pour a bucket of water into it all at once, but it only drips out at a controlled, steady speed.

In a throttled system, if you send too many requests, the server might add a delay to each response. It might queue the requests and process them as capacity becomes available. The goal is to smooth out spikes and avoid a "jagged" traffic pattern.

Why use throttling?

Throttling is excellent for protecting backend resources like databases or third-party APIs. If you know your database can only handle 500 writes per second, you might throttle incoming requests to stay just under that limit.

It provides a better user experience for occasional spikes. Instead of a 429 error, the user might just see a slightly longer loading time. However, if the traffic remains high for too long, the queue will eventually fill up, and the system will have to start rejecting requests anyway.

Key algorithms: token vs leaky bucket

To implement these strategies, engineers rely on specific mathematical models. Understanding these is crucial for fine-tuning your system performance.

1. Token bucket (common for rate limiting)

Imagine a bucket that holds "tokens." Every time a request comes in, a token is removed. If the bucket is empty, the request is rejected. Tokens are added back to the bucket at a constant rate.

Pros: It allows for "burstiness." If the bucket is full, a user can send a quick burst of requests until the tokens run out.
Cons: Hard to manage if the burst is too large for your downstream services.

2. Leaky bucket (common for throttling)

Imagine a bucket with a small hole at the bottom. Requests are poured into the bucket. They "leak" out of the hole at a constant rate to be processed. If the bucket overflows, new requests are dropped.

Pros: It ensures a completely stable, predictable flow of traffic to your backend.
Cons: It is very strict. It does not allow for bursts even if the system has idle capacity.

Practical implementation: Laravel and Shopify

How does this look in the real world? Let's look at two ecosystems where these patterns are vital.

Rate limiting in Laravel

Laravel makes rate limiting simple through its RateLimiter facade and the throttle middleware. The built-in limiter uses a fixed-window counter backed by your cache store.

In Laravel 11 and 12, you define named limiters in the boot method of AppServiceProvider (the old RouteServiceProvider was dropped from the default skeleton):

use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\RateLimiter;

RateLimiter::for('api', function (Request $request) {
    return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip());
});

This tells Laravel to allow 60 requests per minute per user ID or IP address. If the limit is hit, Laravel automatically throws a ThrottleRequestsException, which results in a 429 response. This is a classic "hard stop" rate limit.

Throttling in the Shopify API

Shopify uses a leaky bucket algorithm for its GraphQL Admin API on every plan, not just Plus. This is a clean example of throttling.

When you make a GraphQL call, the response carries cost details under extensions.cost, including the requestedQueryCost and a throttleStatus.

GraphQL cost: Each query is assigned a calculated cost based on the fields and connection sizes you request.
The bucket: Your app has a bucket of "points" — 100 per second restore on Standard, 200 on Advanced, 1,000 on Plus. Points are spent on each query and restore over time.
The brake: If you spend points faster than they restore, Shopify returns a THROTTLED error.

For high-volume commerce, this means you have to build back-off logic into your application. A well-behaved client reads throttleStatus.currentlyAvailable and slows down before it hits the wall, rather than firing blindly and retrying on every THROTTLED error. When you do get throttled, wait long enough for restoreRate to refill the points your next query needs.

Feature	Rate Limiting (Laravel Default)	Throttling (Shopify API Style)
Primary Action	Block (HTTP 429)	Delay or Queue
Best For	Security & Quotas	Resource Stability
Logic	Fixed Window	Leaky Bucket
User Experience	Instant Error	Latency Spike

Architectural impact: security vs experience

When designing your system, you must decide where to place these controls.

At the edge: Implement rate limiting at the WAF or API gateway level. This stops malicious traffic before it even touches your application code. This saves money on compute costs.

Inside the application: Implement throttling within your service logic. Use it when calling external APIs or writing to a shared database. Use a queue system like Redis or Amazon SQS to hold requests that exceed your immediate capacity.

I have found that the most resilient systems use both. Rate limiting at the perimeter blocks the "bad actors," while internal throttling ensures that your internal services don't melt down during a legitimate traffic surge. This is especially important when building agentic commerce systems that may generate many automated API calls in a short period. And if those calls hit a paid LLM, the stakes shift from CPU to your bill — see rate limiting and the denial-of-wallet problem for the token-cost angle.

Takeaways

Managing traffic is about balance. You want to provide a fast experience for users while keeping your infrastructure healthy.

Rate limiting is for policy. Use it to enforce subscription tiers and block brute-force attacks.
Throttling is for stability. Use it to smooth out traffic spikes and protect your database or external API dependencies.
Return 429 codes. Always let the client know they are being limited. Include a Retry-After header so they know when they can try again.
Monitor your limits. Use dashboards to track how often users hit their limits. If 20% of your users are being limited, your limits might be too low — or your app might be inefficient.
Use Redis for state. Both rate limiting and throttling require a fast, central store to track request counts. Redis is the industry standard for this.

How do you decide between rejecting a request immediately or making the user wait 500ms longer to maintain system stability? If you're hardening an API for production, here's how I help teams ship it.

RAG architectures: traditional, agentic, corrective

Thu, 11 Jun 2026 00:00:00 GMT

Retrieval is no longer just about embeddings. Most developers build a basic RAG system only to find it hallucinating or failing on complex questions within a week of deployment. If your vector search returns the wrong context, your LLM will confidently lie to your face. This gap between basic search and reliable intelligence is why RAG architectures have evolved from simple pipelines into self-correcting, agentic systems.

The problem with many initial AI implementations is their static nature. You feed a query into a vector database, pull some chunks, and hope the LLM makes sense of them. This is the traditional RAG model. It works for simple FAQs, but it breaks down when a query requires multi-step reasoning or when the retrieved data is irrelevant. The result is "garbage in, garbage out": the model burns tokens trying to answer from junk context.

This guide compares three RAG architectures so you can pick the right one for your workload: the speed of a traditional pipeline, the reasoning of agentic RAG, or the verification of corrective RAG (CRAG).

Traditional RAG: the linear standard

Traditional RAG is the foundation of most AI-driven applications. It follows a strictly linear, one-shot path: retrieve then generate. You start by converting your documents into vector embeddings and storing them in a database like pgvector or Pinecone. When a user asks a question, the system converts that query into an embedding, performs a similarity search, and injects the top results into the prompt.

This architecture is prized for its low latency and simplicity. If you are building a simple internal search tool for a Shopify store or a basic documentation bot, Traditional RAG is often sufficient. It is cost-effective because it typically involves only one LLM call and one vector search operation.

However, its simplicity is also its biggest weakness. It assumes that the initial retrieval step is always successful. If the vector search returns noise, the LLM has no mechanism to identify that the context is wrong. It will attempt to answer regardless. This often leads to the 7 RAG mistakes in production that plague early-stage AI projects.

Key components of traditional RAG

Vector store: holds document chunks as embeddings.
Retriever: a similarity search function that pulls the top-k relevant chunks.
Generator: the LLM that synthesizes an answer from the retrieved chunks.

Agentic RAG: the strategic pivot

Agentic RAG transforms the retrieval process from a passive pipeline into an active control loop. Instead of a fixed sequence, an LLM agent acts as a "brain" that manages the entire workflow. The agent can plan its approach, decide which tools to use, and iterate until it finds a satisfactory answer.

In an Agentic RAG system, the agent might decide that a single search is not enough. It might break a complex user request into three sub-queries, search different data sources for each, and then synthesize the final answer. This is particularly useful for agentic commerce on Shopify where a user might ask for a comparison between multiple products across different categories.

The core of this architecture is the plan-act-observe cycle (the same loop behind ReAct-style agents). The agent plans a step, performs an action (like calling a search tool), observes the result, and decides whether it needs more information. This iterative nature lets it solve multi-hop problems, where the answer to the first part of a question provides the search terms for the second.

While highly powerful, Agentic RAG is more expensive and slower than traditional methods. Each iteration requires another LLM call. This increases both the token cost and the time the user spends waiting for a response. Managing these loops requires robust infrastructure, often involving an API gateway in the AI stack to handle the increased traffic and orchestration complexity.

Corrective RAG (CRAG): the self-healing layer

Corrective RAG, or CRAG, adds a self-correction step to retrieval. Its goal is to cut hallucinations by inserting a lightweight retrieval evaluator between the retrieval and generation steps to judge how relevant the retrieved documents are. The original CRAG paper uses a fine-tuned T5-large model as that evaluator.

The evaluator scores each retrieval into one of three confidence levels: correct, incorrect, or ambiguous. When confidence is high (correct), CRAG keeps the retrieved context but refines it with a decompose-then-recompose step that strips out irrelevant text before generation. When the retrieval is incorrect, CRAG discards it and triggers a large-scale web search to pull in more reliable knowledge. The ambiguous case combines both: refined retrieval plus web search results.

CRAG suits high-stakes environments where accuracy is non-negotiable. It brings a layer of grounded verification to the otherwise probabilistic behavior of LLMs, deciding whether to trust, refine, or replace retrieved context. By checking whether the ground truth is actually present in the retrieved data, CRAG keeps the model from inventing facts when the database comes up empty.

How the CRAG loop works

Retrieve: fetch initial context chunks.
Evaluate: a lightweight evaluator scores each chunk's relevance into correct, incorrect, or ambiguous.
Correct: if confidence is low, trigger a secondary retrieval (commonly a web search) and refine the context.
Generate: synthesize the final answer only from verified or corrected context.

Comparison: speed vs accuracy vs reasoning

Choosing between these RAG architectures is a trade-off between performance, cost, and complexity. Use the table below to guide your decision. If you are still settling on the storage layer underneath, picking the right RAG stack covers the vector database choices in depth.

Feature	Traditional RAG	Agentic RAG	Corrective RAG
Flow Type	Linear	Cyclic / Iterative	Evaluative Loop
Latency	Low	High	Medium
Cost	Low	High	Medium-High
Use Case	Simple FAQ, Lookup	Complex Research, Workflows	High-Accuracy Q&A
Reliability	Moderate	High (Reasoning)	Very High (Grounding)
Implementation	Easy	Complex	Moderate

For most startups, starting with Traditional RAG and then moving toward a Corrective layer is the most logical path. It allows you to ship quickly while providing a roadmap for increasing reliability as your dataset grows.

Implementation in production: Laravel and cloud

Building these architectures takes more than an LLM API key. It needs a robust backend to handle state, queues, and data processing. In a Laravel environment, you can run the agentic loops with job queues and dedicated service classes. Laravel's ecosystem is well-suited for the orchestrator logic that drives an agentic RAG system.

// Conceptual Laravel Service for a Corrective RAG Flow
class RagOrchestrator {
    public function handleQuery(string $userQuery) {
        // 1. Retrieve initial chunks
        $chunks = $this->vectorStore->search($userQuery);

        // 2. Evaluate with a Critic
        $evaluation = $this->critic->evaluate($userQuery, $chunks);

        if ($evaluation->isIrrelevant()) {
            // 3. Corrective action: Web Search or Retry
            $chunks = $this->webSearch->search($userQuery);
        }

        // 4. Final generation
        return $this->llm->generate($userQuery, $chunks);
    }
}

When deploying these systems, Docker and cloud infrastructure management become critical. You need to scale your vector database and your orchestration layer independently. Tools like Coolify for self-hosting or managed GCP services help with the compute demands of multi-step agentic loops.

Technical takeaways for engineers

Traditional RAG is for speed and simplicity. It is the baseline for all projects.
Agentic RAG is for thinking tasks. Use it when the user needs a consultant, not just a search bar.
Corrective RAG is for truth tasks. Use it when hallucinations are a business risk.
Caching is non-negotiable in agentic RAG. Cache the results of sub-queries to cut cost and latency for recurring questions.

Takeaways

RAG is no longer a "one size fits all" solution. The move toward Agentic and Corrective systems signifies a shift in AI engineering where the focus is on reliability rather than just capability. By choosing the right architecture, you ensure that your application provides value instead of just noise.

Start with Traditional RAG to validate your data and basic retrieval quality.
Implement a Critic layer (Corrective RAG) early if accuracy is your primary KPI.
Reserve Agentic RAG for workflows that require actual decision-making and tool use.
Monitor your retrieval hit rate and token usage religiously.
Use a modular backend structure like Laravel to manage the complexity of multi-loop architectures.

Which architecture currently provides the best balance of cost and accuracy for your production workloads? If you're deciding which RAG architecture fits your product, here's how I help teams ship it.

Monolith vs microservices: how to choose

Wed, 10 Jun 2026 00:00:00 GMT

Complexity is the silent killer of engineering velocity. You start with a clean codebase and a clear vision. Within months, your deployment times have doubled. Your team is tripping over each other's pull requests. You are facing the classic architectural crossroads: monolith vs microservices. Choosing the wrong path early on can lead to catastrophic technical debt or unnecessary operational overhead that drains your budget before you find product-market fit.

In the world of modern web development, particularly for those building with Laravel or Shopify, the pressure to adopt microservices is immense. The industry often treats distributed systems as the default goal. However, for many businesses, a well-structured monolith is not just a starting point. It is often the most efficient way to scale. This guide breaks down the engineering substance behind these two patterns to help you make an informed decision for your next project on Google Cloud or AWS.

Defining the monolithic architecture

A monolithic architecture is a unified software model where all components of an application are interconnected and interdependent. In a Laravel context, this usually means your routes, controllers, models, and background jobs live in a single repository. It is a single deployable unit. When you push code, the entire application is built and shipped to your server or container.

Monoliths are often unfairly criticized as "legacy." In reality, they offer significant advantages for rapid development. Because all modules share the same memory space and database, communication between parts of the system is nearly instantaneous. You do not have to worry about network latency, API versioning, or complex distributed transactions. For a Shopify app or a custom web solution, this simplicity translates to faster shipping cycles.

The benefits of a single codebase

Simplified deployment: You only need one CI/CD pipeline. Whether you are using GitHub Actions to deploy to a Docker-based host or a VPS, the process remains straightforward.
Cross-cutting concerns: Implementing features like authentication, logging, and caching is easier when they are centralized. You don't have to replicate these services across multiple endpoints.
End-to-end testing: Testing the entire user journey is simpler because you can run the whole stack on a single machine without complex orchestration.

The microservices shift

Microservices break the application into small, independent services that communicate over a network. Each service focuses on a specific business domain, such as billing, user management, or inventory. They are often containerized using Docker and managed with orchestrators like Kubernetes or Google Kubernetes Engine (GKE).

The primary driver for microservices is scalability and team autonomy. When your team grows beyond 15 or 20 developers, a monolith can become a bottleneck. Microservices allow different squads to own specific parts of the system. One team can update the billing service in Go while another updates the Shopify sync engine in PHP. This isolation prevents a bug in one module from taking down the entire application.

When to consider microservices

Independent scaling needs: If your Shopify webhook processing requires massive CPU resources but your admin dashboard is lightly used, microservices allow you to scale only the heavy components.
Technology diversity: You might need a Python service for AI-driven RAG systems while keeping your core business logic in Laravel.
Fault isolation: A crash in the reporting service should not prevent customers from checking out.

Monolith vs microservices: comparing the trade-offs

The choice between monolith and microservices is always a trade-off between simplicity and flexibility. There is no silver bullet. You weigh operational cost against developer experience.

Feature	Monolith	Microservices
Operational complexity	Low	High
Development speed	Fast (early stage)	Slow (early stage)
Scalability	Vertical / horizontal (whole)	Independent per service
Data consistency	Strong (ACID)	Eventual consistency
Network latency	Minimal	Significant (API hops)
Testing	Simple	Complex distributed testing

The hidden cost of distribution

Microservices introduce "network tax." Every time one service calls another, you add latency. You also have to handle partial failures. If the user service is down, how does the order service react? Implementing patterns like circuit breakers and retries becomes mandatory. This adds a layer of code that has nothing to do with your business logic. It is pure infrastructure overhead.

Laravel and Shopify context

For most Shopify development or Laravel projects, the "Majestic Monolith" is the superior choice. Shopify provides a robust platform-as-a-service (PaaS) foundation. Your backend's primary job is often to handle OAuth, process webhooks, and manage a custom database.

Splitting a Shopify app into microservices prematurely often leads to "distributed monolith" syndrome. This is where you have the complexity of microservices but the components are still tightly coupled. If you cannot deploy Service A without also deploying Service B, you have failed to achieve the benefits of the architecture. You have only added network latency and deployment pain.

Cloud strategy on GCP

Google Cloud Platform (GCP) offers excellent tools for both patterns. For a monolith, Cloud Run is an exceptional choice. It abstracts away the server management and scales your container based on request traffic. It is cost-effective because you only pay when your code is running.

For microservices, you might utilize GKE or a series of Cloud Run services connected via Pub/Sub. This setup allows for asynchronous communication. When a Shopify order is created, the "Order Service" publishes an event to Pub/Sub. The "Shipping Service" and "Email Service" both listen for that event and act independently. This architecture is powerful but requires significant investment in observability tools like Cloud Logging and Cloud Trace to debug issues across service boundaries.

The hybrid approach: modular monolith

You do not have to choose between a "big ball of mud" and a complex mesh of services. The modular monolith is an effective middle ground. In this pattern, you maintain a single codebase and database, but you strictly enforce boundaries within the code.

In Laravel, this means using separate namespaces or even local packages for different domains. Your "Billing" code should not directly call the "Inventory" models. Instead, it should use internal interfaces or events. This approach gives you the deployment simplicity of a monolith while making it easy to extract a specific module into a standalone microservice later. I go deeper on the mechanics — contracts, schema-per-module, and the friction signals that justify a split — in modular monoliths first. It is a path of "deferred decision making" which is often the most strategic move in software engineering. When the time finally comes to carve a module out, my guide on going from monolith to microservices walks through the strangler-fig migration step by step.

Takeaways

Start with a monolith. Unless you are building for a massive organization with multiple teams, the operational overhead of microservices will slow you down.
Enforce boundaries early. Use a modular structure within your monolith to prevent spaghetti code. This makes future scaling possible.
Leverage managed services. Use GCP Cloud Run for hosting and Cloud SQL for your database to minimize the DevOps burden.
Scale components, not just apps. Use queues (Laravel Horizon) and background workers to handle heavy tasks before splitting into full microservices.
Monitor and trace. Regardless of architecture, invest in centralized logging and performance monitoring to identify bottlenecks before they impact users.

Are you finding that your current monolithic deployment is hitting performance ceilings that vertical scaling can no longer solve? If you're weighing a split, here's how I help teams make that call.

Prompt engineering vs context engineering

Wed, 10 Jun 2026 00:00:00 GMT

You spent three hours tweaking a system prompt to make your LLM stop hallucinating about customer orders. It worked for ten minutes. Then a user asked a question about a return policy from 2024, and the model confidently invented a 90-day cash-back guarantee that doesn't exist. You have hit the instruction ceiling. No matter how many "You are a helpful assistant" or "Think step-by-step" phrases you add, the model cannot reason its way out of a lack of data.

The problem is that you are treating a data problem as a linguistic one. Prompt engineering is about the "how." Context engineering is about the "what." As we move from simple chatbots to complex agentic systems, the focus is shifting away from how we talk to models and toward how we feed them.

The instruction ceiling

Prompt engineering was the first discipline of the AI era. It involves crafting precise instructions, examples, and formatting rules to steer a Large Language Model (LLM). You might spend days testing different verb phrases or adding few-shot examples to get the output exactly right. This works well for creative writing or basic text transformation.

However, prompt engineering is fundamentally stateless and limited. You are trying to squeeze logic, data, and constraints into a finite context window. When the window gets too crowded, the model loses track of earlier instructions. This is the "lost in the middle" phenomenon. Relying solely on prompts means you are forcing the model to rely on its training data, which is static and often outdated.

In a production environment, especially for Shopify development or custom enterprise software, static instructions are dangerous. If your model doesn't know the real-time stock levels or the specific technical specs of a new product, no amount of clever phrasing will prevent a hallucination.

The infrastructure shift: what is context engineering?

Context engineering is the programmatic management of the entire informational environment surrounding the model. It is not just about the text you send; it is about the architecture that decides what data, tools, and memories are available to the model at any given moment.

If prompt engineering is writing a script for an actor, context engineering is building the entire stage, providing the props, and hiring the research team that whispers facts into the actor's earpiece.

Context engineering involves several moving parts:

Retrieval pipelines: Dynamically fetching relevant data from external sources.
Tool governance: Deciding which APIs or functions the model can call.
Memory management: Storing and retrieving past interactions to maintain continuity.
State orchestration: Tracking where the user is in a specific workflow or business process.

By shifting from "telling" to "showing," you reduce the cognitive load on the model. Instead of asking it to "remember all our policies," you build a system that finds the one relevant policy and places it directly in front of the model.

RAG: the context delivery engine

Retrieval-augmented generation (RAG) is the most common implementation of context engineering. It solves the "knowledge gap" by connecting your LLM to a vector store — Postgres with the pgvector extension, or a dedicated database like Pinecone, Weaviate, or Qdrant.

When a user asks a question, the system doesn't just pass the question to the model. First, it converts the query into an embedding (a mathematical representation of meaning). It then searches a database for the most semantically similar documents. These "context snippets" are then injected into the prompt.

The difference is subtle but massive. In prompt engineering, you might say: "Answer questions based on our manual." In context engineering, you say: "Here are the three specific paragraphs from our manual that answer the user's question. Use them." This significantly reduces the chance of the model making things up. However, even RAG has pitfalls. To avoid common errors, you need to understand the nuances of RAG mistakes in production.

MCP: the universal data plumbing

One of the most useful developments in context engineering is the Model Context Protocol (MCP). Introduced by Anthropic in November 2024 and since adopted as an open standard by OpenAI and Google, MCP serves as a standardized bridge between models and the systems where data lives.

Imagine you are building an AI agent that needs to check GitHub issues, look up a customer in a CRM, and then write a technical summary. In a traditional setup, you would have to write custom integration code for every single data source. With MCP, you can use "context servers" that expose these data sources in a format the model understands natively.

MCP allows the model to "pull" context as needed. It transforms the model from a passive receiver of a prompt into an active explorer of a data ecosystem. This is a core part of building a modern API gateway for AI stacks. It turns context from a static block of text into a dynamic, queryable interface.

Feature	Prompt Engineering	Context Engineering
Focus	Phrasing and Tone	Data and Tools
Tooling	Text Editors, Prompt Playgrounds	Vector DBs, MCP, RAG Pipelines
State	Mostly Stateless	Stateful and Persistent
Scalability	Hard to maintain as docs grow	Built for millions of documents
Primary Goal	Better behavior	Better accuracy

Memory and state management

A major part of context engineering that prompt engineering ignores is the concept of long-term memory. Prompting usually focuses on the "now." Context engineering looks at the "always."

In a Laravel-based application, you might use a database or a Redis store to maintain a "memory" of user preferences or past interactions. When the user returns, the context engineering layer retrieves these fragments and summarizes them for the model.

This is more than just passing the last five messages. It involves:

Summarization: Condensing long histories into high-density tokens.
Metadata filtering: Only pulling memories relevant to the current topic.
Hierarchy: Deciding which memories are "core" and which are "ephemeral."

Engineering the future: agents vs chatbots

The shift to context engineering is what separates a basic chatbot from a true AI agent. A chatbot waits for a prompt and responds. An agent lives within a context. It has access to tools (via MCP), knowledge (via RAG), and history (via memory stores).

When you build with a context-first mindset, your code looks different. You spend less time in the OpenAI playground and more time building robust data connectors. You focus on the purity of your data rather than the cleverness of your adjectives.

For developers working with stacks like Laravel and Vue.js, context engineering means building a "context layer" in your middleware. This layer is responsible for gathering all the necessary "props" for the AI before it ever sees the user's input.

// Example of a simple context orchestrator in Laravel
class AIContextManager
{
    public function buildContext(User $user, string $query): array
    {
        $knowledge = $this->vectorStore->search($query);
        $history = $this->memory->getRecent($user->id);
        $tools = $this->mcp->getAvailableTools(['inventory', 'shipping']);

        return [
            'system_prompt' => view('prompts.system')->render(),
            'retrieved_docs' => $knowledge,
            'user_history' => $history,
            'available_tools' => $tools,
            'user_query' => $query,
        ];
    }
}

Takeaways

Context engineering is the professional evolution of prompt engineering. While knowing how to talk to a model remains useful, knowing how to build the infrastructure that informs the model is what creates value.

Prompts are instructions; context is knowledge. Stop trying to teach the model your entire business logic inside a system prompt.
Invest in RAG early. A vector store like Postgres with pgvector gives you a scalable way to handle growing documentation and data.
Adopt MCP for tool-calling. Using the Model Context Protocol standardizes how your AI interacts with your existing APIs and databases.
Manage state outside the prompt. Use your application backend (Laravel, Node, etc.) to handle memory and session state rather than relying on the LLM's limited window.
Focus on data quality. A perfect RAG system with bad data will still produce bad results. Context engineering is, at its heart, a data engineering discipline.

How are you balancing complex system prompts against external retrieval pipelines in your current AI implementation? If you're building that context layer for production, here's how I help teams ship it.

ML engineer vs AI engineer

Tue, 09 Jun 2026 00:00:00 GMT

You are ready to ship AI features, but your hiring roadmap is a mess of overlapping buzzwords and conflicting job descriptions. Hiring a researcher to build a production chatbot often results in a month of experiments with zero shipped code. Conversely, asking a standard full-stack developer to optimize a vector search index usually ends in a high-latency disaster. The gap between training a model and orchestrating a system is wider than most founders realize. The choice between an ML engineer and an AI engineer determines whether you are building a proprietary brain or a high-performance application powered by existing intelligence.

The model scientist: defining the ML engineer

The machine learning engineer lives in the world of weights, biases, and data distributions. Their primary goal is to create, train, or fine-tune models that solve specific predictive or generative tasks. They don't just consume an API. They build the logic that lives inside the API.

In a typical day, an ML engineer might be working with PyTorch or TensorFlow to design a custom architecture. They handle the "dirty work" of data: cleaning massive datasets, managing feature stores, and dealing with training drift. Their mental model is rooted in applied statistics and experimental iteration. If you need a model to predict fraudulent transactions based on proprietary financial data, you need an ML engineer. They ensure the model generalizes well and doesn't overfit the training set.

Their technical stack is heavy on the backend of the data world. You will see them using tools like Spark for data processing, Weights & Biases for experiment tracking, and NVIDIA GPUs for heavy lifting. The output of their work is a serialized model file or a dedicated inference service that other systems can call. This is a deep-tech role focused on the "how" of intelligence — the distinction between the training and inference phases shapes most of their day.

The systems architect: defining the AI engineer

The AI engineer is a relatively new breed of developer. They treat the model as a black-box service. Their focus is not on training the LLM, but on building the infrastructure around it to make it useful for users. They are the bridge between raw intelligence and a functional product.

An AI engineer spends their time on system design and software engineering. They work with foundation models like Claude, GPT, and Gemini through APIs and focus on RAG (retrieval-augmented generation) and agentic workflows. Instead of tweaking hyperparameters, they are tweaking system prompts and designing tool-use schemas.

The AI engineer is responsible for the user experience of AI. This includes managing latency, implementing guardrails, and ensuring the output is structured correctly for the frontend. If you are building a custom support bot on Shopify, you want an AI engineer. They know how to connect the store's data to the LLM and handle the complexities of multi-turn conversations.

Technical stack: a side-by-side comparison

Understanding the differences requires looking at the tools used in 2026. While there is overlap, the primary focus areas are distinct.

Feature	ML Engineer	AI Engineer
Core Models	Custom PyTorch/TensorFlow, XGBoost	Claude, GPT, Llama, Gemini APIs
Primary Task	Training, Fine-tuning, Evaluation	Prompt Engineering, RAG, Agents
Data Focus	Feature engineering, labeling, drift	Chunking, indexing, retrieval quality
Programming	Python (heavy), C++, CUDA	Python, TypeScript, PHP
Infrastructure	Kubernetes, GPUs, Feature Stores	Vector DBs (pgvector), MCP, Serverless
Success Metric	F1 Score, Accuracy, Loss curves	Latency, Hallucination rate, User NPS

The ML engineer owns the pipeline from raw data to a deployed model. The AI engineer owns the pipeline from a user query to a relevant, cited response. One builds the engine; the other builds the car and chooses the best fuel.

The RAG bridge: where the roles meet

Retrieval-augmented generation (RAG) is the most common point of collision between these two roles. A robust RAG system requires high-quality embeddings and a fast, scalable vector database.

An ML engineer might be the one training a domain-specific embedding model or a custom reranker to improve the relevance of search results. They look at the mathematical similarity between vectors and optimize the distance functions.

However, the AI engineer is usually the one who implements the end-to-end RAG system. They decide how to chunk the documents, how to manage metadata, and how to implement hybrid search using tools like pgvector or Pinecone. They also handle the critical task of context management: ensuring the LLM gets exactly what it needs without exceeding its context window or blowing the budget. If you are just starting, avoid common RAG mistakes in production by focusing on retrieval quality before model size.

Agentic systems: the new frontier

In 2026, the focus has shifted from simple chatbots to agentic systems. These are AI agents that can use tools, browse the web, and execute code to complete complex tasks.

AI engineers are the primary drivers of this shift. They use frameworks like LangGraph or the Claude Agent SDK to build multi-step workflows. They are the ones implementing the Model Context Protocol (MCP) to give their agents access to internal databases, local files, and external APIs. This requires deep software engineering skills, as agents need reliable error handling and human-in-the-loop checkpoints to be useful in a business context.

ML engineers support this by providing the specialized tools that agents call. An agent might call a custom fraud-detection model built by an ML engineer as part of its reasoning loop. The AI engineer orchestrates the logic, while the ML engineer provides the specialized prediction capabilities.

DevOps and deployment: from MLOps to LLMOps

The deployment cycle for these roles looks very different. ML engineers deal with MLOps — see DevOps vs MLOps for how that discipline diverges from classic ops. This involves setting up specialized infrastructure for model training, managing GPU clusters, and monitoring for model drift over time. They often use tools like Docker and Kubernetes to ensure their models can scale to handle millions of inference requests.

AI engineers focus on LLMOps, or "AI DevOps." Their concerns are more about API reliability, cost management, and caching. They need to ensure that their AI applications stay performant and that they can swap out a model version (e.g., bumping a Claude or GPT model to a newer release) without breaking the entire system. Tools like Coolify or specialized cloud setups on Google Cloud are common here for hosting the middleware that connects the LLM to the world.

How to choose the right path for your project

The decision to hire or specialize depends on the "intelligence" you need. If your problem is unique and there is no pre-trained model that can solve it, you need an ML engineer. This is true for niche medical imaging, high-frequency trading, or specialized sensor data analysis.

If your problem can be solved by a very smart assistant that has access to your company data, you need an AI engineer. Most modern software applications fall into this category. You don't need to train a new model to build an AI-powered project management tool. You need to build a great system around a foundation model. This often comes down to a RAG vs fine-tuning decision — and the answer is usually RAG.

In many ways, AI vs traditional development is becoming less about the code and more about the data orchestration. The AI engineer is essentially a full-stack developer who has mastered the art of managing non-deterministic outputs.

Takeaways

ML engineers are model builders who focus on training, data science, and applied statistics.
AI engineers are system builders who focus on app development, RAG, agents, and model orchestration.
Technical overlap exists in Python and data fundamentals, but the daily toolsets are diverging.
RAG is the primary intersection point where both roles contribute to a single production feature.
Agents represent the future of AI engineering, requiring strong backend logic and API integration skills.
Choosing the right role prevents wasted resources and ensures your AI features actually reach production.

When you look at your current roadmap, is your biggest bottleneck the lack of a custom model, or the inability to make an existing model work reliably with your data? If you're building that AI layer for production, here's how I help teams ship it.

Load balancer vs reverse proxy: scale vs security

Mon, 08 Jun 2026 00:00:00 GMT

Your server is gasping for air. A sudden traffic spike from a new marketing campaign or a successful product launch on Shopify has pushed your single Laravel instance to its absolute limit. CPU usage is pinned at 99 percent. Requests are timing out. The database is struggling to keep up with the sheer volume of open connections. You know you need to scale. You know you need a buffer between the public internet and your application. But when you look at the architectural diagrams, you see two terms used almost interchangeably: load balancer and reverse proxy.

Choosing the wrong one — or failing to understand how they work together — leads to "Frankenstein" architectures. You might end up with redundant layers that add latency without adding value. Or worse, you might leave your application exposed to security risks that a proper proxy would have mitigated. To build a robust Laravel application or a high-performance Shopify app, you must understand the technical nuances between these two critical infrastructure components.

The gatekeeper: understanding the reverse proxy

A reverse proxy is a server that sits in front of one or more web servers and intercepts requests from clients. It acts as a shield and a middleman. When a user tries to access your website, they talk to the reverse proxy first, then it decides how to handle that request before passing it along to your backend Laravel or Node.js application. (If you are fuzzy on which direction it faces, see forward proxy vs reverse proxy — they sit on opposite ends of the connection.)

In the world of Coolify and self-hosted SaaS, Nginx is the most common reverse proxy. Its primary job is to simplify the management of incoming traffic. Instead of exposing your application server directly to the wild internet, the reverse proxy handles the "dirty work" of HTTP communication.

Key functions of a reverse proxy

SSL termination: Encrypting and decrypting HTTPS traffic is CPU-intensive. A reverse proxy handles the SSL certificates and offloads this work from your application server. This allows your Laravel workers to focus on executing business logic rather than processing handshakes.
Caching: A reverse proxy can store copies of static assets or even dynamic responses. When a second user requests the same data, the proxy serves it straight from its cache instead of hitting your application. (Nginx, for example, keeps cached responses on disk with the keys held in shared memory.) This drastically reduces the load on your backend.
Request routing: You can route traffic based on the URL path. For example, your reverse proxy can send all requests starting with /api to one service and everything else to a different frontend application.
Security and anonymity: By hiding the IP addresses of your backend servers, a reverse proxy makes it much harder for attackers to target your infrastructure directly. It can also act as a basic Web Application Firewall (WAF) to block malicious traffic patterns.

The traffic controller: understanding the load balancer

While a reverse proxy focuses on how a request is handled, a load balancer focuses on where it goes. The primary mission of a load balancer is high availability and horizontal scaling. If you have five identical Laravel servers running in a Docker cluster, the load balancer ensures that no single server gets overwhelmed while others sit idle.

Load balancers operate at different levels of the networking stack. Layer 4 load balancers work at the transport level (TCP/UDP), making decisions based on IP addresses and ports without looking at the actual content of the request. Layer 7 load balancers work at the application level (HTTP/HTTPS), allowing for much more granular routing based on headers, cookies, or URL parameters.

How load balancers distribute work

Load balancers use specific algorithms to decide which server gets the next request. Common strategies include:

Round robin: Requests are sent to servers in a sequential loop. It is simple but assumes all your backend servers have the same capacity.
Least connections: The load balancer tracks how many active requests each server is handling. It sends new traffic to the server that is currently the least busy.
IP hash: The client's IP address is used to determine which server receives the request. This ensures that a specific user stays connected to the same server, which is vital for applications that store session data locally rather than in Redis.

Technical nuances: comparing the two

The confusion often arises because modern tools like Nginx, HAProxy, and Traefik can perform both roles. However, the conceptual difference remains important for system design.

Feature	Reverse Proxy	Load Balancer
Primary Goal	Security, routing, and efficiency	Availability and throughput
Backend Pattern	Usually one logical service	A pool of identical nodes
Caching	Excellent support for static + dynamic	Usually minimal or none
Health Checks	Basic (is the backend up?)	Advanced (latency, error rates, load)
OSI Layer	Mostly Layer 7 (Application)	Layer 4 (Transport) or Layer 7

Both are really reverse-proxy roles wearing different hats: a load balancer emphasizes distribution (spreading traffic across a pool), while a reverse proxy emphasizes transformation (SSL, caching, routing, security). The same tool — Nginx, HAProxy, Traefik — can do both. In a sophisticated API gateway, these roles are merged into a single entry point that manages both the security and the distribution of traffic across your microservices.

Real-world implementation in Laravel and Shopify

When building custom web solutions, you rarely choose just one. You layer them. For a production-grade Laravel application, your architecture typically looks like a "sandwich" of these components.

The Laravel DevOps stack

In a typical cloud infrastructure setup on GCP or AWS, the request flow looks like this:

The cloud load balancer: This is your public entry point. It receives traffic and spreads it across multiple virtual machine instances or Kubernetes nodes.
The local reverse proxy (Nginx): Each node runs an Nginx instance. This proxy terminates the SSL, serves static CSS and JS files from the disk, and forwards the PHP requests to PHP-FPM.
The application (Laravel): Laravel receives the cleaned-up request from Nginx.

This multi-layer approach provides redundancy. If one Nginx instance fails, the cloud load balancer detects the failure through a health check and stops sending traffic to that specific node. This keeps your service available to users.

The Shopify app context

If you are developing a Shopify app, your infrastructure requirements are unique. During major events like Black Friday, webhook traffic can spike hard and bursty, and Shopify gives you only a 5-second window to acknowledge each delivery before it counts as failed and gets retried (up to 8 times over roughly 4 hours). You cannot ride that out on a single server.

You should use a load balancer to ingest these webhooks and distribute them across a fleet of worker nodes, acknowledging fast and processing the payload asynchronously. A reverse proxy at the edge can help you implement rate limiting. This prevents a single store from monopolizing your app resources and ensures that your agentic commerce systems remain responsive for all merchants.

Why "both" is usually the answer

Modern web development has moved away from the "one server" model. Even for small startups, the cost of a managed load balancer is negligible compared to the cost of downtime. Using a reverse proxy like Nginx or Traefik is standard practice because it simplifies your application code. You do not want to write SSL handling logic inside your Laravel controllers. You want the infrastructure to handle that for you.

When you combine a load balancer and a reverse proxy, you gain the ability to perform blue-green deployments. You can spin up a new version of your app, test it, and then tell the load balancer to slowly bleed traffic from the old version to the new one. If something breaks, you flip the switch back. This level of control is impossible without these two components working in tandem.

Takeaways

Use a reverse proxy if you have a single server but need to handle SSL, caching, and basic security.
Add a load balancer as soon as you need to scale horizontally across multiple servers to handle more traffic or ensure high availability.
Leverage Nginx or HAProxy to fulfill both roles in a single software layer for smaller to medium-sized projects.
Offload SSL termination to the proxy layer to keep your Laravel or Node.js application responsive.
Implement health checks in your load balancer to automatically remove unhealthy server instances from the rotation.
Choose Layer 7 balancing if you need to route traffic based on specific HTTP headers or URL paths.

What is your current bottleneck — scaling the number of concurrent connections, or managing the complexity of your request routing? If you're hardening an infrastructure layer for production, here's how I help teams ship it.

Logging vs monitoring: a guide for scaling

Mon, 08 Jun 2026 00:00:00 GMT

Your production environment is failing and your customers are reporting 500 errors. You check your dashboard and see a spike in latency but the graph does not tell you why the database connection is timing out. You dive into your text files to find the specific stack trace but the logs are unstructured and impossible to search during a crisis. This gap between knowing something is wrong and knowing why it is wrong is the fundamental divide between logging and monitoring. Engineering teams routinely conflate these two pillars of observability, and the result is slow incident response and fragile systems.

Understanding the distinction is not just about choosing tools. It is about building a robust strategy for your DevOps solutions that ensures high availability and fast debugging. While both involve data collection, they serve different masters. One is the pulse of your system. The other is the forensic record.

Logging vs monitoring: what vs why

Monitoring is the process of tracking metrics over time to understand the state of a system. It answers the question "Is the system healthy?" by looking at numbers. You monitor CPU usage, memory consumption, and request latency. If a metric crosses a certain threshold, your monitoring system triggers an alert. It provides a high-level view of performance and availability.

Logging is the act of recording discrete events that occur within an application or infrastructure. It answers the question "What exactly happened?" by providing context. A log entry might contain a user ID, a timestamp, and a specific error message from a failed Laravel job. Logs are granular. They provide the narrative of a single request journey through your stack.

Feature	Monitoring	Logging
Data type	Metrics (numbers/counters)	Events (text/structured data)
Purpose	Detection and health	Diagnosis and forensics
Frequency	Aggregated over time	Recorded per occurrence
Alerting	Threshold-based (e.g., CPU > 80%)	Event-based (e.g., Fatal Error)
Storage	Time-series databases	Log aggregators/search engines

Monitoring: the pulse of your infrastructure

Monitoring focuses on quantitative data. It is the first line of defense in any production environment. By observing trends, you can predict failures before they happen. For example, a slow increase in memory usage over 48 hours might indicate a memory leak in a long-running Docker container.

In a modern stack using tools like Coolify and Docker, monitoring ensures your containers are performing as expected. You should focus on the "Four Golden Signals" of monitoring: latency, traffic, errors, and saturation. Latency measures the time it takes to service a request. Traffic measures the demand placed on the system. Errors measure the rate of requests that fail. Saturation measures how "full" your service is.

Effective monitoring requires meaningful thresholds. An alert that fires every time CPU usage hits 70% is noise if your application is designed to be CPU-intensive. You must define Service Level Objectives (SLOs) that align with user experience. If your users do not notice a 100ms delay, do not wake up an engineer for it.

Logging: the black box recorder

If monitoring tells you the plane is losing altitude, logging tells you why the engine stalled. Logs provide the forensic evidence needed to debug complex issues. In a distributed system, a single user action might touch multiple services. Without a centralized logging strategy, finding the root cause of a failure is like finding a needle in a haystack.

The biggest mistake developers make is using unstructured logs. Standard text logs like [2026-06-21] Error: something went wrong are difficult for machines to parse. Modern engineering teams use structured logging. This involves formatting logs as JSON objects. This allows you to filter and query logs based on specific fields like user_id, request_id, or environment.

{
  "timestamp": "2026-06-21T14:30:05Z",
  "level": "error",
  "message": "Payment gateway timeout",
  "context": {
    "user_id": 4502,
    "order_id": "ORD-9921",
    "gateway": "stripe",
    "attempt": 3
  },
  "request_id": "req-a1b2c3d4"
}

By including a request_id in every log entry, you can trace a single request across your entire infrastructure. This is essential for modern Shopify development where webhooks and API calls often chain together.

Observability in the Laravel ecosystem

Laravel provides a powerful logging system built on the Monolog library. Out of the box, it supports various "channels" such as single files, daily rotated files, syslog, and Slack, plus stack channels that fan a single message out to several of them at once. For production environments, configure Laravel to ship logs to a centralized service. Sending logs to a service like Logstash, Sentry, or Datadog ensures you do not lose data if a server instance is terminated.

Monitoring a Laravel application involves more than just checking if the web server is up. You must monitor the health of your background queues. If your Redis queue is backing up, your customers might not receive order confirmation emails or account activation links. Tools like Laravel Pulse or Horizon provide real-time monitoring specifically for these application-level metrics.

A common pattern is to log exceptions to a dedicated tracker while monitoring the error rate through a dashboard. This creates a feedback loop where a spike in the "Error Rate" metric in your monitoring tool prompts you to check the "Exception Logs" for the actual stack trace.

Scaling Shopify apps with metrics and logs

Building high-scale Shopify apps requires a specialized approach to logging and monitoring. Shopify apps live at the mercy of external API rate limits and webhook delivery speeds. If your app handles thousands of webhooks per minute, you cannot afford to log every single successful event to a text file. You will quickly run out of disk space.

Instead, use monitoring to track the "Webhook Success Rate" and your API rate-limit consumption. Shopify's GraphQL Admin API meters calls by calculated query cost using a leaky bucket (on a Standard plan, a 1,000-point bucket that refills at 100 points per second), while the REST Admin API uses a request-per-second bucket. Watch how close you run to those ceilings, then use logging to investigate the specific failed payloads when the success rate drops. This is especially important for agentic commerce applications where AI agents perform autonomous tasks on behalf of a merchant. If an agent fails to update an inventory count, you need the specific log to understand the logic failure.

For Shopify Plus merchants, performance is critical. Monitoring the "Time to First Byte" (TTFB) of your app's embedded components ensures that you are not slowing down the merchant's admin experience.

The DevOps synergy: linking logs and metrics

The most mature engineering organizations do not treat logging and monitoring as separate silos. They link them together. When an alert fires in your monitoring tool, it should provide a direct link to the logs associated with that specific timeframe and service.

This is often achieved through "Correlation IDs." When a request enters your system, you assign it a unique ID. This ID is attached to every metric collected and every log entry generated during that request. This allows you to jump from a high-level metric spike directly to the low-level events that caused it.

Furthermore, you should monitor your logs. By counting the frequency of certain log patterns, you can create new metrics. If you see the log message "Database connection lost" appearing more than five times in a minute, that log event should be converted into a metric that triggers a high-priority alert.

Best practices for technical teams

Automate everything: Your monitoring agents and logging drivers should be part of your base server image or Dockerfile.
Log levels matter: Use debug for local development, info for general production events, and error or critical for things that require human intervention.
Protect PII: Never log personally identifiable information like passwords, credit card numbers, or auth tokens. Use log masking to strip sensitive data.
Set retention policies: Metrics are small and can be kept for months. Logs are large and expensive. Set a retention policy that balances cost with your need for historical data.
Monitor the monitors: Ensure your monitoring system itself is healthy. A silent monitoring system is a dangerous liability.

Takeaways

Monitoring detects that a problem exists. Logging explains why the problem occurred.
Metrics are numerical data points. Logs are detailed event records.
Use structured JSON logging to make your data searchable and machine-readable.
In Laravel, prioritize queue monitoring to ensure background tasks are completing.
In Shopify apps, track API rate limits as a primary health metric.
Link logs and metrics using Correlation IDs to reduce the Mean Time to Resolution (MTTR).
Monitoring should be based on user-centric SLOs to avoid alert fatigue.

How do you differentiate between a noisy alert and a critical system failure in your current production stack? If you're building that observability layer for production, here's how I help teams ship it.

Load balancer vs API gateway

Sun, 07 Jun 2026 00:00:00 GMT

Two boxes sit at the front of almost every production system, and engineers constantly confuse them. One spreads traffic across servers so nothing falls over. The other inspects each request, checks who is calling, and decides where it should go. They look similar on an architecture diagram, but they solve fundamentally different problems.

Pick the wrong one and you either bolt fragile business logic onto a component that was built to be dumb and fast, or you pay for an expensive policy engine to do a job a simple round-robin could handle. The load balancer vs API gateway decision shapes how you scale, secure, and observe everything behind it.

This guide breaks down what each component actually does, where they differ, and why mature systems almost always run both.

What a load balancer actually does

A load balancer has one job: take incoming traffic and spread it across a pool of identical backends so no single server gets overwhelmed. It is the component that lets you run three copies of your app instead of one and survive a traffic spike.

Load balancers operate at one of two layers. An L4 (transport layer) balancer routes by IP and port. It does not look inside the request — it just forwards TCP/UDP packets, which makes it extremely fast. An L7 (application layer) balancer understands HTTP, so it can route based on the path or host header and terminate SSL/TLS. Algorithms like round-robin, least-connections, and IP-hash decide which backend gets the next request.

The key trait is that a load balancer is largely stateless and content-agnostic. It cares about availability and distribution, not about who you are or whether you are allowed to make this call. That ignorance is a feature: it keeps the component simple, fast, and reliable. If you have ever wondered how this differs from a reverse proxy, the two overlap heavily — see load balancer vs reverse proxy for where they diverge.

What an API gateway actually does

An API gateway is the opposite kind of component. It is opinionated, aware, and full of business rules. It sits in front of your services and acts as a single, managed front door for every API call.

A gateway handles the cross-cutting concerns you do not want duplicated in every microservice: authentication and JWT validation, rate limiting and quota enforcement, request/response transformation, protocol translation (exposing internal gRPC services as REST/JSON, for example), caching, and per-client logging. Instead of each service re-implementing auth, the gateway enforces it once at the edge.

Crucially, a gateway routes by intent, not just availability. It maps /orders to the orders service and /users to the users service, applies the right policy to each, and stitches a fleet of microservices into one coherent API. That makes it a natural fit once you move from a monolith to microservices and need one stable front door over many services. It is also the foundation of a clean API gateway for an AI stack, where the gateway governs which model endpoints and tools a request can reach.

Key differences at a glance

The two components overlap on the surface — both sit at the front, both can route HTTP — but their purpose, intelligence, and state could not be more different.

Aspect	Load Balancer	API Gateway
Primary job	Distribute traffic across servers	Enforce policy + route by intent
Layer	L4 (TCP/UDP) or L7 (HTTP)	L7 (HTTP/API aware)
Awareness	Content-agnostic	Inspects auth, headers, payload
Core features	Health checks, SSL, algorithms	Auth, rate limiting, caching, transforms
State	Mostly stateless	Tracks clients, quotas, sessions
Optimizes for	Availability + throughput	Security + control

The rule of thumb: reach for a load balancer when you need raw distribution and uptime, and an API gateway when you need to apply rules — who can call this, how often, and in what shape.

The ultimate architecture: using them together

In a professional production environment, it is common to see both components working in tandem. This is not redundant. It is a layered defense and distribution strategy.

A typical request flow looks like this:

The L4/L7 load balancer: Sits at the absolute edge of your network. It handles global traffic distribution and terminates SSL/TLS. It passes clean HTTP traffic to the API gateway.
The API gateway: Receives the traffic from the load balancer. It checks the user's JWT token, validates that they haven't exceeded their rate limit, and routes the request to the correct microservice.
The backend services: These are often fronted by their own internal load balancers. For example, your Laravel API might have three pods. A simple internal load balancer (often built into Docker or Kubernetes) distributes the traffic from the gateway across those three pods.

This separation of concerns lets you scale your infrastructure independently of your business rules. You can rewrite authentication logic in the gateway without touching load balancer configuration, and you can add or remove backend replicas without the gateway noticing.

Implementing traffic control with Laravel and Docker

When developing with Laravel, you often don't need a dedicated hardware appliance. You can implement these patterns using open-source software like Nginx, Traefik, or Kong. Using Docker containerization makes this setup highly portable.

For instance, if you are using Traefik as an API gateway in a Docker Compose file, you can define your routing and middleware logic directly in the labels. This keeps your configuration close to your code.

services:
  laravel-api:
    image: ansezz/laravel-app:latest
    labels:
      - "traefik.http.routers.api.rule=Host(`api.example.com`)"
      - "traefik.http.middlewares.api-auth.forwardauth.address=http://auth-service"
      - "traefik.http.middlewares.rate-limit.ratelimit.average=100"
      - "traefik.http.routers.api.middlewares=api-auth,rate-limit"

In this example, Traefik is performing the role of an API gateway by checking with an external auth service and enforcing rate limits before the request ever reaches the Laravel application.

Shopify and the gateway pattern

For Shopify developers, the API gateway pattern is vital when building "headless" storefronts. Since you are communicating with both the Shopify Storefront API and your own custom backend, a gateway can unify these disparate sources. It can cache frequent Shopify queries to reduce API consumption and improve performance for the end user.

A gateway also lets you implement logic Shopify doesn't support natively: transforming payloads or merging multiple sources into a single response, which cuts the number of round trips the browser has to make. That pattern is foundational to building agentic workflows in modern commerce.

Takeaways

Understanding the specific strengths of load balancers and API gateways will save you from infrastructure debt.

Choose a load balancer for simple traffic distribution, high throughput, and maximum availability at the network layer.
Choose an API gateway for complex routing, security enforcement, protocol translation, and providing a unified entry point to microservices.
Layer your stack by putting an L4/L7 load balancer at the edge and an API gateway behind it to handle business logic.
Leverage automation with tools like Docker and Coolify to manage these components without the overhead of manual server configuration.
Focus on observability by using the gateway's ability to log per-client metrics, which helps in debugging and billing.

How do you handle cross-cutting concerns like rate limiting and authentication across your current microservice fleet? If you're untangling an infrastructure layer for production, here's how I help teams ship it.

Horizontal vs vertical scaling

Sat, 06 Jun 2026 00:00:00 GMT

Your application is slowing down. Users are reporting latency, your database is hitting 90% CPU usage, and your background workers are lagging. You know you need more power. But should you buy a bigger server or start adding more of them? Choosing the wrong scaling path can lead to wasted budget, unnecessary architectural complexity, or a hard ceiling on your growth.

Engineering for scale is not just about adding hardware. It is about understanding the trade-offs between vertical and horizontal strategies. If you wait too long to scale out, you risk a single point of failure. If you scale out too early, you drown in the complexity of distributed systems. This guide breaks down the technical substance of both approaches.

Vertical scaling: the "bigger box" strategy

Vertical scaling, or "scaling up," is the process of adding more power to your existing server. This typically means increasing the CPU, RAM, or storage capacity of a single instance. In a cloud environment like Google Cloud or AWS, this is as simple as changing your machine type from a small instance to a high-memory or high-compute instance.

This is the path of least resistance. Since the application still lives on one machine, you do not need to change your code. There is no need for load balancers, service discovery, or complex networking. Your Laravel application or monolith works exactly as it did before, just faster.

However, vertical scaling has a hard ceiling. Every hardware generation has a limit. Eventually, you will find that the "biggest box" available is either too expensive or simply not enough. More importantly, vertical scaling does not solve the problem of redundancy. If that one big server goes down, your entire system goes down with it.

Horizontal scaling: building the "fleet"

Horizontal scaling, or "scaling out," involves adding more machines to your infrastructure. Instead of one giant server, you have a fleet of smaller servers working in parallel. A load balancer sits in front of this fleet, distributing incoming traffic across the available nodes.

This is the gold standard for high availability and modern cloud infrastructure. When one server fails, the load balancer simply routes traffic to the healthy ones. It also offers extreme elasticity. With auto-scaling, you can add nodes during a traffic spike and remove them when things quiet down, ensuring you only pay for what you use.

The catch is that horizontal scaling requires architectural changes. Your application must be stateless. If a user uploads a file to Server A, Server B must be able to access it. If you store session data in the local memory of Server A, the user will be logged out if their next request hits Server B. You must externalize state to shared databases or object storage.

Key differences at a glance

Choosing between these two depends on your current stage and technical requirements. Here is how they compare across critical engineering metrics.

Feature	Vertical Scaling (Scale Up)	Horizontal Scaling (Scale Out)
Primary Action	Add CPU/RAM to one node	Add more nodes to the pool
Complexity	Low (No code changes)	High (Distributed system)
Fault Tolerance	Low (Single point of failure)	High (Redundancy by design)
Scalability Limit	Hard limit (Hardware ceiling)	Virtually unlimited
Maintenance	Requires downtime for resizing	Zero-downtime rolling updates
Cost	Expensive at the high end	More efficient through auto-scaling

The challenge of distributed state

When you move to a horizontal model, the database becomes the most significant bottleneck. Scaling an application layer is relatively easy because app servers are usually stateless. Scaling a database is harder because data must remain consistent across multiple nodes.

For many Shopify apps or custom web platforms, the first step into horizontal scaling is adding read replicas. You keep one "primary" database for writes and multiple "replica" databases for reads. This offloads the heavy lifting from the main node.

If your data grows beyond the capacity of a single primary node, you might look into sharding. This involves splitting your data across different database clusters. It is a powerful technique but introduces massive complexity in how you query and join data.

Scaling in practice: Laravel and DevOps

In the Laravel ecosystem, scaling often starts with vertical upgrades. I have seen many projects stay on a single powerful VPS for years. As traffic grows, the transition to horizontal scaling usually follows a specific pattern.

Externalize Sessions: Move sessions from the file driver to redis or database.
Centralize Files: Move local storage to an S3-compatible object store.
Add a Load Balancer: Use Nginx or a cloud-provider load balancer to distribute traffic.
Decouple Workers: Move queue workers to their own dedicated instances to avoid competing for resources with the web server.

Tools like Coolify or Docker Swarm make managing multiple containers easier. They allow you to define your infrastructure as code, making it simple to spin up new nodes as needed.

How to choose your strategy

There is no one-size-fits-all answer. Your choice should be a pragmatic balance of cost, time, and reliability.

Choose Vertical Scaling if:

You are in the early stages of a startup or MVP.
Your traffic is predictable and stable.
You have a small team with limited DevOps resources.
Your application architecture is tightly coupled or legacy.

Choose Horizontal Scaling if:

You need 99.9% or higher availability.
Your traffic is bursty or growing rapidly.
You are building a cloud-native application from scratch.
You want to avoid the "all-or-nothing" risk of a single server.

In reality, most modern architectures use a hybrid approach. You might scale your database vertically as much as possible while scaling your application layer horizontally. This gives you the reliability of a fleet with the simplicity of a single data source.

Takeaways

Vertical scaling is about making a single server more powerful through CPU and RAM upgrades.
Horizontal scaling adds more servers to a pool and uses a load balancer to manage traffic.
Vertical scaling is simpler and requires no code changes but has a performance ceiling and no redundancy.
Horizontal scaling offers high availability and elasticity but requires a stateless application architecture.
For most web applications, the transition to horizontal scaling starts by externalizing sessions, files, and background jobs.
Databases are the hardest part to scale horizontally, often requiring replicas or sharding.

At what point does the cost of managing a distributed horizontal system outweigh the cost of simply buying a larger server for your specific workload? If you're planning a scaling path for your stack, here's how I help teams ship it.

LLM vs AI agent: from prompts to action

Sat, 06 Jun 2026 00:00:00 GMT

Most developers start their AI journey by sending a prompt to an API and waiting for a text response. This workflow works for simple summaries or creative writing but fails when the task requires real-world actions. You quickly realize that a single chat completion cannot manage a multi-step refund process in a Shopify store or navigate a complex database schema to generate a report.

The limitation is not the intelligence of the model. The limitation is the architecture. Relying solely on Large Language Models (LLMs) is like having a genius professor who has no hands, no memory of yesterday, and no access to a computer. You get great answers but zero execution.

AI agents solve this by wrapping the LLM in a system of tools, memory, and planning logic. This shift from "talking to a model" to "building an autonomous system" is one of the biggest changes in how we architect software today.

The LLM as a prediction engine

A Large Language Model is essentially a stateless next-token predictor. When you send a prompt, the model uses its training data to calculate the most probable sequence of words to follow your input. It does not "think" in the human sense. It performs a single forward pass through a massive neural network.

The core characteristics of a standalone LLM include:

Statelessness: The model does not remember previous interactions unless you include them in the current prompt.
Knowledge cutoff: It only knows what was in its training set up to a certain date.
No external interaction: By default, it cannot check your email, query your production database, or browse the web.
Single-turn logic: It produces one output for one input. Any multi-step reasoning must happen within that single output.

For simple applications, this is sufficient. If you are building a basic API gateway for AI, you might only need a thin wrapper around a model. However, as soon as you need the system to take initiative, the LLM alone is not enough.

Defining the AI agent: the reasoning loop

An AI agent is an autonomous system that uses an LLM as its central reasoning engine. Unlike a standard LLM call, an agent operates within a loop. It observes the environment, thinks about what to do next, takes an action using a tool, and then observes the result of that action to decide its next step.

This loop allows the agent to correct its own mistakes. If a database query fails, a standalone LLM would simply report the failure in its final response. An agent, however, sees the error, analyzes what went wrong, and tries a different query. This pattern of interleaving a reasoning step with an action and then observing the result is the ReAct (Reasoning + Acting) approach introduced by Yao et al. in 2022.

The four pillars of agency

To transform an LLM into an agent, you must provide four critical layers of infrastructure.

1. Memory

While LLMs have a "context window," this is temporary and expensive. Agents use external memory systems to maintain state across sessions. This includes short-term memory for current task steps and long-term memory for user preferences or historical data. We often use vector databases like pgvector to store and retrieve these memories efficiently — the distinction between the context window and persistent memory is what separates a toy from a production agent.

2. Tools

Tools are the hands of the agent. These are external functions, APIs, or scripts that the agent can choose to execute. When an agent identifies that it needs information it doesn't have, it generates a structured command (typically a JSON object that conforms to the tool's schema) to call a tool. This is what lets agents act on modern stacks like Laravel or a Shopify store.

3. Planning

Complex goals need to be broken down into smaller, manageable tasks. An agent uses the LLM to create a roadmap. This might involve task decomposition where a high-level request like "Audit our cloud spend" is split into sub-tasks like "List all AWS instances," "Query pricing API," and "Generate CSV report."

4. Reasoning

This is the logic that governs how the agent uses the other three pillars. It is the control loop that keeps the system running until the goal is achieved or a stopping condition is met.

Technical comparison

Feature	Large Language Model (LLM)	AI Agent
Execution	Passive (prompt-response)	Active (goal-oriented)
Persistence	None (stateless)	Persistent (external memory)
Capabilities	Text generation and analysis	Tool use, API calls, web browsing
Reasoning	One-shot internal logic	Multi-step iterative loop
Connectivity	Isolated	Integrated with external systems
Architecture	Model-centric	System-centric

Transitioning from RAG to agentic workflows

Retrieval-Augmented Generation (RAG) was the first step toward more capable AI. In a standard RAG setup, you retrieve relevant documents from a vector store and stuff them into the LLM prompt. This is a linear process.

Agentic RAG takes this further. Instead of a fixed retrieval step, the agent decides when to search, what keywords to use, and whether the retrieved information was actually useful. If the first search results are poor, the agent refines its query and searches again. I cover this evolution in more depth in traditional vs agentic vs corrective RAG.

For example, when dealing with 7 common RAG mistakes, an agentic approach can mitigate issues like "hallucinated retrieval" by cross-referencing multiple sources or validating facts against a structured database.

Building agents in production

Building an agentic system requires more than just an API key. You need a robust backend to manage the state and execute the tools. Frameworks like LangGraph and CrewAI are popular for Python developers. However, for those in the PHP ecosystem, you can build powerful agentic backends using Laravel and tools like Claude MCP.

The Model Context Protocol (MCP) is particularly exciting for agent development. It provides a standardized way for agents to connect to local and remote data sources. Instead of writing custom connectors for every tool, you can use MCP to give your agent immediate access to your filesystem, GitHub repos, or database schemas.

// Example of a tool definition in a Laravel-based agent
public function getTools(): array
{
    return [
        [
            'name' => 'query_shopify_orders',
            'description' => 'Retrieves order details from Shopify using GraphQL.',
            'parameters' => [
                'type' => 'object',
                'properties' => [
                    'order_id' => ['type' => 'string'],
                ],
            ],
        ],
    ];
}

By defining tools clearly, you allow the agent to understand exactly what it can do. The LLM then acts as the router, deciding which tool to trigger based on the user's intent.

When to choose an agent over an LLM

Not every feature needs to be an agent. Agents are more complex to build, harder to test, and can be more expensive due to multiple LLM calls.

Use a standalone LLM when:

You need immediate, low-latency text generation.
The task is simple and doesn't require external data.
The workflow is linear and predictable.

Use an AI agent when:

The task requires multiple steps or logic branches.
You need the system to interact with external APIs or databases.
The goal is open-ended (e.g., "Research this topic and find three competitors").
You need the system to learn and adapt over time using memory.

Takeaways

LLMs are engines, not drivers. They provide the reasoning power but require a system around them to perform real work.
Agency is architectural. You build agency by adding memory, tool-use, and planning layers to your model.
Reasoning loops are key. The ability to observe and correct actions is what makes agents autonomous.
Start with RAG, then move to agents. Agentic RAG is a natural evolution for teams already using vector databases.
Standardize your tools. Protocols like MCP make it easier to give agents access to the data they need without custom boilerplate.

Is your current AI implementation stuck in a passive prompt-response loop, or are you ready to build systems that actually take action? If you want help making that jump, here's how I work with teams shipping agents.

DevOps vs MLOps: key technical differences for 2026

Fri, 05 Jun 2026 00:00:00 GMT

Shipping application code to production is difficult. Shipping a machine learning model that continues to perform accurately over time is significantly harder. You might have a perfectly automated pipeline that builds your Docker images and deploys them to a cluster in seconds. However, if your model starts making incorrect predictions because of a change in consumer behavior, your automated deployment of "correct" code is effectively shipping a broken product. This is the core friction between traditional software operations and the emerging world of machine learning operations.

That gap is what the DevOps vs MLOps comparison is really about. DevOps focuses on the reliability and speed of software delivery. It treats code as the primary artifact. MLOps takes those same principles and adds two volatile new variables: data and models. While DevOps solves the problem of "it works on my machine," MLOps solves the problem of "it worked on last month's training data."

Understanding the technical divide between these two disciplines is essential for any team moving beyond simple heuristic-based software and into the world of AI engineering.

The core philosophy of DevOps

DevOps is built on the foundation of the continuous integration and continuous delivery (CI/CD) pipeline. The primary goal is to shorten the development life cycle and ship changes continuously with high software quality. In a standard DevOps environment, like one running a Laravel application on Docker, the process is relatively deterministic.

If the source code passes its unit tests, the integration tests succeed, and the environment configuration is correct, the application should behave predictably in production. The artifacts are static. Once a binary or a container image is built, it does not change its internal logic based on the data flowing through it.

Technical teams use DevOps to manage:

Source code: Versioning application logic in Git.
Build automation: Compiling code and packaging it into artifacts.
Infrastructure as Code (IaC): Using tools like Terraform or Pulumi to define servers and networks.
Testing: Running automated suites to ensure no regressions in logic.

The emergence of MLOps

MLOps, or Machine Learning Operations, is a set of practices that aims to deploy and maintain machine learning models in production reliably and efficiently. It is not just "DevOps for AI." While it borrows the automation mindset, the artifacts in MLOps are fundamentally different.

A machine learning system is composed of three distinct components: code, data, and the model. In DevOps, you only really care about the code. In MLOps, a change in the data can break the system even if the code remains untouched. This introduces a level of non-determinism that traditional CI/CD pipelines are not designed to handle.

If you are building agentic commerce solutions on Shopify, for example, your recommendation engine might fail not because of a bug in the Python script, but because the underlying distribution of customer purchases shifted during a holiday sale. This phenomenon, known as data drift, requires a lifecycle that includes continuous monitoring and retraining.

Key technical differences at a glance

Here are the primary technical distinctions between the two methodologies.

Feature	DevOps	MLOps
Primary artifact	Source code and binaries	Code, datasets, and model weights
Lifecycle	Build, test, deploy	Data prep, train, evaluate, deploy, monitor
Testing	Unit and integration tests	Model validation, accuracy metrics, bias checks
Deployment	Static (service/binary)	Dynamic (model endpoint or batch job)
Monitoring	Latency, CPU, error rates	Data drift, model decay, precision, recall
Feedback loop	Code bug fixes	Continuous retraining (CT)

The CI/CD/CT pipeline

The most significant architectural difference is the introduction of a third loop. While DevOps relies on CI (Continuous Integration) and CD (Continuous Delivery), MLOps introduces CT (Continuous Training).

Continuous Integration (CI) in MLOps

CI in this context is no longer just about testing code. It involves testing the data. You must validate the schema of incoming datasets and ensure that feature engineering logic is consistent between the training environment and the production environment. A mismatch here leads to training-serving skew, a common reason for model failure.

Continuous Delivery (CD) in MLOps

CD involves the automated deployment of the model service. This often means deploying a prediction API or updating a weights file in a running inference engine. Because models are large and computationally expensive, MLOps pipelines often use canary deployments or shadow testing to verify performance on live data before full rollouts.

Continuous Training (CT)

This is the unique signature of MLOps. A CT pipeline automatically triggers a retraining job when certain conditions are met. This might be a scheduled interval or a trigger based on performance degradation. The pipeline pulls new data, runs the training script, evaluates the new model version against a benchmark, and registers it in a model registry if it passes.

Monitoring and the problem of drift

In traditional DevOps, monitoring is centered on system health. You look at memory usage, response times, and HTTP 500 errors. If the server is up and the code is executing, the system is usually considered "healthy."

In MLOps, system health is only half the story. You also need to monitor statistical health. A model might be returning a "200 OK" status code with 50ms latency, but if the predictions it provides are nonsensical, the system is failing.

There are two main types of drift that MLOps engineers must track:

Data drift: The input data distribution changes. For example, a model trained on high-end fashion data might struggle if the store expands to include budget streetwear.
Concept drift: The relationship between input and output changes. For instance, what was considered a "normal" credit card transaction in 2019 might look very different during a global supply chain crisis in 2026.

Detecting these requires sophisticated logging of every prediction and its eventual outcome, creating a feedback loop that informs the next training cycle. This is a critical step often missed in early-stage AI development.

Tooling and infrastructure

The toolsets for these two fields are diverging. While there is overlap in the use of Docker and Kubernetes, the specialized needs of machine learning have given rise to a new stack.

Standard DevOps tools include:

GitHub Actions / GitLab CI: Pipeline orchestration.
Docker: Containerization.
Terraform: Infrastructure provisioning.
Prometheus / Grafana: System monitoring.

MLOps expands this list with:

MLflow / Weights & Biases: Experiment tracking and model versioning.
Kubeflow / Vertex AI: ML-specific orchestration.
Feature stores: Centralized repositories for pre-processed data features.
Evidently AI / Arize: Statistical monitoring and drift detection.

Building a bridge between these tools is the hallmark of a mature technical organization. You need the stability of DevOps to host the infrastructure and the flexibility of MLOps to manage the intelligence layer.

Bridging the gap in production

For teams managing complex web applications, the goal is not to choose one over the other. It is integration. A modern stack might use a Laravel backend for user management, hosted via a Coolify-managed VPS, while calling an MLOps-managed inference endpoint for personalized content.

One practical way to start is by implementing versioning for your datasets. Just as you would never deploy code without a commit hash, you should never train a model without knowing exactly which version of the data was used. This ensures reproducibility, which is the first step toward a functional MLOps workflow.

The same rigor applies to retrieval systems. Treat vector databases and retrieval pipelines as managed infrastructure inside your DevOps workflow rather than ad-hoc scripts. That discipline alone heads off many of the RAG failures teams hit in production.

Takeaways

Managing the technical transition from code-centric to model-centric operations requires a shift in how you view automation.

DevOps is about code reliability: Focus on CI/CD pipelines, automated testing, and deterministic deployments.
MLOps is about model reliability: Focus on data validation, experiment tracking, and statistical monitoring.
The CT loop is essential: Continuous training prevents your models from becoming obsolete as real-world data evolves.
Monitoring must be dual-layered: Track both system metrics (latency/errors) and model metrics (drift/accuracy).
Tooling is specialized: Use standard DevOps tools for the hosting layer and MLOps tools for the training and registry layers.
Data is an artifact: Treat your training data with the same versioning rigor you apply to your source code.

How do you plan to handle the statistical monitoring of your models once they transition from a static environment to the unpredictable flow of production data? If you're standing up an MLOps practice, here's how I help teams build it.

Context window vs memory: building AI that remembers

Thu, 04 Jun 2026 00:00:00 GMT

Large language models have a memory problem that costs you money and performance. You spend thousands of tokens feeding the same documentation, user history, and context into every single prompt. Yet the moment the session ends, the model forgets everything. It is like hiring a genius consultant who suffers from total amnesia the instant they walk out the door.

This cycle of "context stuffing" is unsustainable for production systems. Relying solely on a massive context window leads to high latency and the "lost in the middle" phenomenon where models ignore data buried in the center of a large prompt. To build truly intelligent agentic systems, you must distinguish between the ephemeral context window and persistent long-term memory.

Building a robust AI architecture requires a strategic mix of RAG, vector databases, and efficient context management. This guide breaks down the technical differences between context and memory, and how to implement a hybrid approach that scales.

Understanding the context window

The context window is the model's immediate working memory. It represents the total number of tokens (words or parts of words) the model can process at one specific moment. When you send a prompt to a frontier model like Claude or GPT, the context window includes your current instruction, the previous conversation history, and any files you have attached.

Think of the context window as a physical desk. You can only fit so many papers on it at once. If you add a new stack of documents, you have to push the old ones off. Once a token falls out of this window, the model loses all awareness of it. It does not matter if the information was vital. It is gone.

Modern models offer massive context windows — Claude is at one million tokens and Gemini reaches up to two million. While impressive, these are still temporary. They are not a replacement for a database. Using a large context window for everything is an expensive way to handle data that should be stored permanently. Bigger is not automatically better, either: accuracy and recall degrade as the window fills, a problem the field now calls "context rot."

The illusion of long-term memory

Many developers mistake a long context window for long-term memory. It is a dangerous technical shortcut. If you are building for Shopify Plus, for example, you might be tempted to dump your entire product catalog into the prompt.

This creates three immediate problems:

Cost: You pay for those tokens every time the user asks a question.
Latency: The more tokens you send, the longer the model takes to reason and respond.
Accuracy: Large context windows are prone to noise. The model may hallucinate because it is overwhelmed by irrelevant data.

True long-term memory is persistent. It lives outside the model. It allows an AI agent to remember a user's preference from three months ago without needing that preference to be included in every single API call. This is where Retrieval-Augmented Generation (RAG) becomes the hero of your architecture.

RAG: the external brain for AI

Retrieval-Augmented Generation (RAG) is the technical bridge between a stateless LLM and a persistent knowledge base. Instead of stuffing everything into the context window, you store your data in a vector database. When a query comes in, you perform a semantic search to find only the most relevant "chunks" of information.

These chunks are then injected into the context window. This keeps the prompt lean and the model focused. RAG turns the "desk" (context window) into a tool for reasoning over a "library" (vector database).

For technical teams using the Laravel ecosystem, implementing RAG has become significantly easier with tools like pgvector. You can store embeddings directly in your PostgreSQL database, allowing for seamless integration between your relational data and your AI logic.

Feature	Context Window	Long-Term Memory (RAG)
Duration	Session-based (Temporary)	Persistent (Permanent)
Capacity	Limited (1M–2M tokens)	Virtually Unlimited
Cost	High per-request cost	Low per-request (fixed storage)
Update Speed	Instant for the session	Requires indexing/embedding

The economics of tokens vs infrastructure

Choosing between a larger context window and a RAG pipeline is an economic decision. For a small internal tool with ten users, context stuffing is fine. The engineering hours required to build a RAG pipeline would exceed the token savings.

However, for a SaaS application or a high-volume e-commerce store, the math shifts quickly. Sending 100,000 tokens per request at scale will destroy your margins. A well-optimized RAG system might only send 2,000 tokens per request.

The infrastructure cost of a vector database like Pinecone or a self-hosted pgvector instance is often a fraction of the cost of wasted tokens. The trade-offs between managed and self-hosted stores are worth weighing up front — see picking the right RAG stack. Either way, you avoid the common RAG mistakes in production by focusing on retrieval quality rather than just prompt size.

Implementing persistent memory with pgvector

If you are running a Laravel application, you do not need a separate, complex vector database for basic memory. PostgreSQL with the pgvector extension is often the best choice for mid-sized applications. It allows you to perform similarity searches alongside your standard Eloquent queries.

Imagine a user searching for "shoes for rainy weather." In a traditional database, you would look for the keyword "rainy." With embeddings and pgvector, the system understands the semantic relationship between "rainy" and "waterproof."

// Example of a semantic search in Laravel using pgvector
$queryEmbedding = AI::generateEmbedding("shoes for rainy weather");

$products = Product::query()
    ->selectRaw('name, description, embedding <=> ? as distance', [$queryEmbedding])
    ->orderBy('distance')
    ->limit(5)
    ->get();

By storing these embeddings, you create a persistent memory of your product catalog that is always ready for the LLM to access. You only pull the relevant products into the context window when they are needed.

Claude MCP and the future of context

The Model Context Protocol (MCP) by Anthropic is a game-changer for how we handle context. It allows models to connect directly to external data sources like Google Drive, Slack, or your local filesystem.

Instead of you manually managing what goes into the context window, the model uses Claude MCP servers to fetch what it needs on demand. This blurs the line between context and memory. The model "remembers" where to find information and retrieves it dynamically.

This is the foundation for agentic systems. An agent that can query its own database or read its own logs via MCP doesn't need a massive context window. It needs a high "reasoning capacity" to know which piece of memory to grab at the right time.

Hybrid strategies for agentic systems

The most advanced AI systems do not choose one over the other. They use a tiered memory strategy.

Short-term context: The last 5–10 messages of the conversation for immediate flow.
Episodic memory: A RAG-based retrieval of previous conversations with the specific user.
Semantic knowledge: A RAG-based retrieval of the general knowledge base (manuals, docs, catalogs).
Tool-based memory: Using circuit breakers and vector DBs to ensure the system doesn't spiral when a tool fails.

This multi-layered approach ensures the model has exactly what it needs to solve a problem without the bloat of an oversized prompt.

Takeaways

Managing the boundary between context and memory is the difference between a toy and a production-grade AI application.

Stop context stuffing: If your prompt is consistently over 50k tokens, you are likely wasting money and reducing accuracy.
Use RAG for persistence: Move static or long-term data into a vector database like pgvector or Pinecone.
Optimize for latency: Smaller prompts result in faster response times and a better user experience.
Leverage MCP: Use the Model Context Protocol to give your agents a standardized way to "reach out" to their memory stores.
Monitor token counts: Track how many tokens actually contribute to the final output versus how many are just noise.

As models get smarter, the "size" of the desk becomes less important than the "organization" of the library. Are you building a bigger desk, or a better library? If you're designing memory for a production agent, here's how I help teams ship it.

Data engineer vs data scientist: roles, tools, and overlap

Thu, 04 Jun 2026 00:00:00 GMT

Your business is drowning in data, but your AI models are still hallucinating or returning irrelevant results. You have invested in the latest Large Language Models and vector databases, yet the output remains inconsistent because the underlying data is a fragmented mess of raw logs and poorly formatted JSON. Without a robust foundation, even the most advanced neural network is just a sophisticated guessing machine. The solution lies in understanding the distinct but complementary roles of the Data Engineer and the Data Scientist.

While these two roles often share the same office space and use similar programming languages like Python and SQL, their core missions are fundamentally different. One builds the factory, while the other refines the product. In the modern technical landscape, especially when deploying agentic systems or RAG architectures, the distinction between infrastructure and inference is the difference between a project that scales and one that stays in the prototyping phase.

The architect vs. the detective

To understand the difference, consider the construction of a smart city. The Data Engineer is the civil architect and utility provider. They design the power grids, the water filtration systems, and the high-speed transit tunnels. Their goal is reliability, throughput, and structural integrity. If the water stops flowing or the lights flicker, the city ceases to function.

The Data Scientist is the urban planner and behavioral psychologist. They look at the traffic patterns, the energy consumption rates, and the population growth to decide where to build the next park or how to optimize the public transport schedule. They do not build the pipes. They use the resources flowing through the pipes to make the city smarter and more efficient.

In a technical stack, this means the Data Engineer manages the flow of information from source to storage. The Data Scientist then extracts that information to train models, run experiments, and generate business insights.

The role of the data engineer: building the pipeline

The Data Engineer is responsible for the design, construction, and maintenance of the systems that collect, store, and move data. They operate at the "upstream" end of the lifecycle. Their primary focus is on the "three Vs": Volume, Velocity, and Variety.

Core responsibilities

Pipeline Development: Creating ETL (Extract, Transform, Load) or ELT processes that move data from diverse sources like Shopify APIs, Google Cloud buckets, or internal PostgreSQL databases into a centralized warehouse.
Infrastructure Management: Setting up and managing data warehouses (Snowflake, BigQuery) and data lakes. This often involves working with Docker and Coolify for self-hosted data tools or managing managed services on AWS.
Data Modeling: Designing the schema and architecture of the data to ensure it is optimized for high-performance querying.
Reliability and Scaling: Ensuring that the data infrastructure can handle spikes in traffic without crashing and that the data remains consistent across all systems.

Data Engineers spend a significant amount of time thinking about system architecture and DevOps principles. They are the ones who implement circuit breakers for vector databases and ensure that your RAG pipeline does not fail because of a sudden surge in API requests.

The role of the data scientist: extracting the value

Once the data is clean, formatted, and accessible, the Data Scientist takes over. They operate "downstream," using the curated datasets to solve specific business problems or create predictive features.

Core responsibilities

Exploratory Data Analysis (EDA): Investigating datasets to find hidden patterns, outliers, or correlations that can inform business decisions.
Machine Learning Development: Building and tuning models for classification, regression, or recommendation systems. This might involve using frameworks like PyTorch or TensorFlow.
A/B Testing and Experimentation: Designing and running tests to see how changes in a web application or Shopify store affect user behavior and conversion rates.
Data Storytelling: Communicating complex mathematical findings to non-technical stakeholders through visualizations and reports.

Data Scientists are the ones who ask "Why is our churn rate increasing?" or "What is the optimal price point for this new subscription service?" They rely heavily on the Data Engineer to provide high-quality data. If the data is corrupted, the model will be biased or inaccurate.

Data engineer vs data scientist: a side-by-side view

The tools and skill sets overlap, but the application differs. Below is a breakdown of how these roles compare in a production environment.

Feature	Data Engineer	Data Scientist
Primary Goal	Build and maintain data systems	Analyze and model data for insights
Common Languages	SQL, Python, Java, Scala	Python, R, SQL
Key Tools	Spark, Kafka, Airflow, dbt, Docker	scikit-learn, PyTorch, Jupyter, Tableau
Main Output	Cleaned datasets, APIs, pipelines	Predictive models, insights, reports
Mindset	Engineering and reliability	Statistics and experimentation
Cloud Focus	Infrastructure (GCP, AWS, Terraform)	Managed ML services (SageMaker, Vertex AI)

While a Data Scientist might use SQL to pull a specific cohort of users for analysis, a Data Engineer uses SQL to optimize a transformation job that processes millions of rows per second.

The synergy in modern AI stacks

In the era of LLMs and generative AI, the lines between these roles are becoming more blurred, yet the need for specialization is higher than ever. A similar boundary is being redrawn between the ML engineer and the AI engineer. Consider a Retrieval-Augmented Generation (RAG) system.

The Data Engineer builds the ingestion pipeline that scrapes documentation, cleans the text, generates embeddings, and stores them in a vector database like pgvector. They ensure the API gateway is secure and that the index stays fresh, whether through scheduled batch jobs or near-real-time streaming.

The Data Scientist then steps in to evaluate the performance of the RAG system. They experiment with different embedding models, adjust the "top-k" retrieval parameters, and fine-tune the prompts to ensure the AI provides the most accurate and helpful responses.

Without the engineer, the scientist has no data to query. Without the scientist, the engineer has a very expensive pipeline that delivers technically correct but practically useless results. Both are essential for moving beyond basic chatbots and into agentic commerce solutions.

Which role does your project need?

If you are a startup or an established business looking to modernize your digital presence, you might wonder which hire to make first.

You need a Data Engineer if:

Your data is scattered across multiple SaaS platforms and spreadsheets.
Your existing reports are slow or frequently crash.
You want to build a real-time data streaming platform or a scalable AI infrastructure.
You are migrating to the cloud (GCP or AWS) and need a custom pipeline.

You need a Data Scientist if:

You have a large amount of clean data but do not know how to use it.
You want to build recommendation engines or churn prediction models.
You need to run complex experiments to optimize your marketing spend.
You want to leverage AI to find specific insights that are not obvious through standard reporting.

Often, the best approach is to build the engineering foundation first. It is impossible to do science on a pile of broken pipes.

Takeaways

Data Engineers focus on the "how" of data movement and storage. They are software engineers specialized in distributed systems and infrastructure.
Data Scientists focus on the "what" and "why" of the data. They are statisticians and analysts specialized in extracting meaning and building models.
Collaboration is key for AI success. A successful RAG or agentic system requires high-quality engineering to feed high-quality science.
Tooling overlaps in Python and SQL, but engineers lean toward orchestration (Airflow, dbt) while scientists lean toward modeling (scikit-learn, PyTorch).
Foundation First: You cannot perform meaningful data science without a robust data engineering infrastructure.

How are you currently handling the gap between your raw data infrastructure and your analytical insights? If you're building that foundation for production AI, here's how I help teams ship it.

Cloud engineer vs DevOps engineer in 2026

Wed, 03 Jun 2026 00:00:00 GMT

The cloud engineer vs DevOps engineer question trips up almost every team that outgrows a single server. The titles overlap, the job posts blur them together, and hiring the wrong specialty has a real cost: infrastructure that is over-engineered and expensive, or fast to ship but prone to outages. The two roles solve different problems. This guide breaks down where they diverge, where they overlap, and which one to hire first.

The cloud engineer: designing the foundation

A Cloud Engineer acts as the architect of your digital workspace. Their primary responsibility is to design, implement, and manage the cloud infrastructure where your applications reside. This role focuses on the "where" and the "what" of your technical stack. They spend their time navigating the vast catalogs of providers like AWS, Google Cloud Platform (GCP), or Azure.

Cloud Engineers specialize in building the environment itself. This includes designing Virtual Private Clouds (VPCs), configuring subnets, and managing identity and access management (IAM) policies. They ensure that your database clusters are highly available and that your storage solutions are cost-effective. By 2026, Cloud Engineering has evolved to include sophisticated FinOps practices. They monitor resource consumption to prevent surprise bills from unoptimized cloud usage.

When you need to migrate a legacy system to a modern cloud-native architecture, the Cloud Engineer leads the way. They translate business requirements into technical blueprints. For instance, they might design an API gateway architecture to manage traffic for a distributed AI application. Their focus is on the resilience, security, and scalability of the infrastructure layer.

The DevOps engineer: automating the lifecycle

While the Cloud Engineer builds the foundation, the DevOps Engineer builds the machinery that moves code onto that foundation. DevOps is a methodology focused on the software delivery lifecycle. A DevOps Engineer is the bridge between development and operations teams. Their goal is to maximize the speed and reliability of software releases through automation.

The core of a DevOps engineer's toolkit is the CI/CD pipeline — continuous integration and continuous delivery. They use tools like GitHub Actions, GitLab CI, or Jenkins to automate the building, testing, and deployment of code. If a developer pushes a change, the DevOps Engineer's systems ensure that code is automatically scanned for vulnerabilities and deployed to a staging environment without manual intervention.

Reliability is another major pillar. DevOps Engineers implement observability stacks using Prometheus and Grafana. They set up sophisticated alerting systems to catch issues before they affect end users. In modern setups, they often leverage tools like Docker and Coolify for hosting to simplify deployment workflows. They care deeply about the "how" of software delivery.

Side-by-side comparison: skills and focus

To better understand which professional fits your current needs, it helps to compare their daily priorities. While there is a significant overlap, the center of gravity for each role is different. Both rely heavily on infrastructure as code (IaC) using tools like Terraform or Pulumi — the same tooling I weigh up in Terraform vs Ansible.

Feature	Cloud Engineer	DevOps Engineer
Primary Goal	Infrastructure design and management	Automation and software delivery
Key Focus	Networking, Security, Storage, Cost	CI/CD, Deployment, Monitoring, Culture
Cloud Expertise	Deep (multi-service architecture)	Functional (deployment targets)
Coding Focus	Infrastructure scripts (Terraform, HCL)	Glue code and automation (Bash, Python)
KPIs	Uptime, Cost efficiency, Security	Deployment frequency, Mean Time to Recovery
Tools	AWS/GCP/Azure, VPC, IAM, RDS	GitHub Actions, Docker, Kubernetes, Ansible

Cloud Engineers are often the ones who decide whether to use a managed database service or a self-hosted one. DevOps Engineers are the ones who ensure that the migration to that database happens seamlessly with zero downtime.

The overlap: platform engineering in 2026

The line between Cloud and DevOps has become increasingly blurred. In high-growth startups and mature enterprises, these roles often merge into what is known as Platform Engineering. The platform team builds an "Internal Developer Platform" (IDP). This allows developers to self-serve their own infrastructure needs within pre-defined guardrails.

Platform engineering combines the architectural knowledge of a cloud engineer with the automation mindset of a DevOps engineer. They use Kubernetes (EKS, GKE, or AKS) as the base layer. By abstracting away the complexity of the cloud, they enable product teams to move faster. If this sounds adjacent to site reliability, it is — I unpack the boundaries in SRE vs platform engineer.

For companies running Laravel applications, this might involve setting up a standardized Docker-based environment, so the code runs the same way on a local machine as it does in a production cluster on GCP. Browse the DevOps category to see how these workflows are structured in practice.

Choosing the right hire for your business

Determining which role to hire first depends on your current technical debt and business stage. If you are starting from scratch or moving away from a single-server setup, you need a Cloud Engineer. They will ensure your architecture is secure and scalable from day one. Without this foundation, your automation efforts will be built on top of a fragile environment.

If you already have a functional cloud setup but your developers are burning hours on manual deployments and firefighting, you need a DevOps engineer. They will untangle your release process and implement the guardrails necessary for rapid iteration. They focus on developer experience and velocity.

Large-scale e-commerce businesses using Shopify Plus often find that their needs are hybrid. They might need custom middleware hosted on cloud infrastructure while maintaining a rigid CI/CD process for their custom Shopify apps. In these scenarios, having a specialist who understands both the infrastructure and the automation pipeline is vital.

Takeaways

Cloud Engineers specialize in infrastructure architecture, cloud-native services, security, and cost optimization.
DevOps Engineers focus on the software delivery pipeline, automation, CI/CD, and system reliability.
Tools overlap heavily, with both roles requiring proficiency in Terraform, Docker, and at least one major cloud provider.
Platform Engineering is the modern synthesis of both roles, aimed at providing self-service infrastructure to developers.
Hire a Cloud Engineer when you need to build or modernize the "hardware" of your digital business.
Hire a DevOps Engineer when you need to speed up your release cycle and automate manual operational tasks.

How does your current team balance the need for architectural stability with the demand for rapid feature delivery? Here's how I help teams strike that balance.

CDN vs cache: why your high-traffic site needs both

Tue, 02 Jun 2026 00:00:00 GMT

High-traffic applications often collapse under the weight of redundant data requests. Every time a user in London requests a file from a server in New York, the latency kills the user experience and drains your server resources. If you do not optimize how data is stored and delivered, your infrastructure costs will skyrocket as your performance plateaus.

The solution lies in understanding the distinct roles of Content Delivery Networks (CDNs) and general caching. While many developers use these terms interchangeably, they serve different masters in the architecture stack. The CDN-vs-cache decision is rarely either/or: mastering the synergy between a global CDN and local caching is what lets a high-traffic site stay fast under load.

The fundamental speed gap

Latency is the silent killer of conversion rates. A standard request involves multiple round-trips between the client and the origin server. If the data has to travel across the Atlantic, the physical distance imposes a speed limit that no amount of code optimization can fix. This is a latency problem, not a bandwidth one — a wider pipe won't fix the lag when the bottleneck is round-trip distance.

Caching solves this by keeping data closer to the execution point. A CDN solves this by keeping that cache closer to the user. When these two work together, they create a multi-layered shield that protects your origin server from unnecessary load.

Understanding the cache hierarchy

Caching is a broad technical concept that refers to the temporary storage of data for faster retrieval. It is not limited to a single location. In a modern stack, caching happens at multiple layers to ensure that the most expensive operations are never repeated.

The most common layers include:

Browser cache: Assets like CSS, JS, and images are stored on the user's device. This makes repeat visits feel instantaneous.
Server cache: Tools like Redis or Memcached store database query results and computed objects in memory. This prevents the application from hitting the database for every single request. The same in-memory layer powers more advanced patterns too, like semantic caching in RAG pipelines.
Application cache: Modern frameworks like Laravel have built-in mechanisms to cache entire HTML fragments or API responses.

The primary goal of caching is to reduce the workload on your primary infrastructure. By storing the result of a complex calculation or a heavy database query, you trade a small amount of memory for a massive gain in response time.

The global reach of CDNs

A CDN is a specialized type of cache that lives at the "edge" of the network. While a standard cache might live on your main server, a CDN is a globally distributed network of servers designed to host your content in dozens of geographical locations simultaneously.

When a user visits your site, the CDN intercepts the request — acting as a reverse proxy sitting in front of your origin. If the requested asset is already stored at the edge server closest to the user, it is served immediately. This bypasses the need to travel back to your origin server entirely. This is particularly critical for static assets like images, video files, and large JavaScript bundles.

For businesses running on Shopify, the platform handles much of this CDN logic automatically — its CDN (backed by Cloudflare) ships on every plan, not just Plus. Even so, understanding how to manage cache headers and purge cycles remains a vital skill for custom development.

Technical comparison: CDN vs cache

To choose the right tool for the job, you must understand where each one excels. The following table breaks down the core technical differences between a standard internal cache and a global CDN.

Feature	Local/Server Cache	Content Delivery Network (CDN)
Primary Goal	Reduce CPU and database load.	Reduce network latency and distance.
Location	On or near the origin server.	At the network edge (Points of Presence).
Scope	Often specific to a single server or user.	Shared across many users globally.
Ownership	Part of your application infrastructure.	Typically a third-party service provider.
Best For	DB queries, session data, fragments.	Images, JS, CSS, static HTML, video.

Caching is about how the data is stored. A CDN is about where that data is distributed. You use a cache to stop the server from doing the same work twice. You use a CDN to stop the data from traveling across the world twice.

Implementation in Laravel and Shopify

Implementing these concepts varies depending on your tech stack. In a Laravel environment, you often manage caching through a unified API that supports multiple drivers.

// Example of caching a database query in Laravel
$users = Cache::remember('active_users', 3600, function () {
    return DB::table('users')->where('active', true)->get();
});

This code snippet ensures that the database is only queried once per hour for this specific data. To take this a step further, you would configure your web server to set Cache-Control headers that a CDN like Cloudflare or Akamai can interpret.

In the world of Shopify development, you rely heavily on the platform's native CDN. Shopify uses a robust edge network to serve product images and storefront assets. However, when building custom apps or headless storefronts, you must manually manage how your API responses are cached to prevent performance bottlenecks.

Synergy: using both for maximum scale

The most resilient architectures use a "cache-aside" pattern combined with an edge delivery strategy. This creates a multi-step defense for your origin server.

The edge shield: The CDN handles the majority of incoming traffic for static files and common public pages.
The server shield: For requests that reach the origin, a server-side cache (like Redis) provides immediate data without hitting the database.
The database shield: Proper indexing and internal database caching provide a final layer of optimization.

This layered approach is essential for modern DevOps practices. It ensures that even during a massive traffic spike, such as a Black Friday sale or a viral product launch, your core application remains responsive.

Common pitfalls to avoid

Managing two different caching systems introduces the challenge of cache invalidation. If you update a product price in your database but the CDN is still serving a cached version of the page, you will face customer service issues.

Always implement a clear "purge" strategy. When data changes on your origin, you must have a mechanism to clear both your internal cache and the corresponding edge cache on your CDN. Many developers use webhooks or event listeners to automate this process. This ensures that your users always see the most accurate data without sacrificing speed.

Takeaways

Caching is the technique of storing data temporarily to avoid repeating expensive operations.
CDN is a network of servers that use caching to deliver content from a location physically close to the user.
Distance matters: A CDN reduces the physical travel time of data, while a local cache reduces the processing time.
Use both: Implement server-side caching for database results and a CDN for static assets to achieve the best performance.
Invalidation is key: Ensure your system can purge outdated data from all layers simultaneously to maintain data integrity.

How do you handle cache invalidation across multiple edge locations when your application data changes in real-time? If you're wiring edge delivery and caching into a high-traffic build, here's how I help teams ship it.

CI vs CD: automating quality and delivery

Tue, 02 Jun 2026 00:00:00 GMT

Shipping a broken build to production is an expensive way to realize your local environment isn't a mirror of reality. For developers working on Laravel backends or Shopify storefronts, the gap between "it works on my machine" and a stable production release is often filled with manual steps that invite human error. Manual FTP uploads, SSHing into servers to run migrations, or manually publishing Shopify themes are risks that modern engineering cannot afford.

Continuous Integration (CI) and Continuous Delivery (CD) are the two pillars that eliminate this uncertainty. By automating the path from a code commit to a live environment, teams can ship faster while actually increasing the stability of their applications. This guide breaks down the core differences between CI and CD and how to apply them to modern software stacks.

Defining Continuous Integration (CI)

Continuous Integration is the practice of merging all developer working copies to a shared mainline several times a day. In a Laravel or Vue.js environment, this means that every time you push code to a branch, an automated system builds the application and runs a suite of tests.

The goal of CI is to identify "integration hell" before it happens. Instead of waiting for a weekly release to find out that two developers changed the same core service, the CI pipeline flags the conflict within minutes. A standard CI pipeline for a Laravel application typically includes several automated steps.

Dependency management: Installing Composer and NPM packages to ensure the environment is fresh.
Static analysis: Running tools like PHPStan or Laravel Pint to enforce code quality and style.
Automated testing: Executing unit and feature tests using PHPUnit or Pest.
Security audits: Scanning for known vulnerabilities in third-party dependencies.

By the time a pull request is ready for review, the CI system has already provided a "green light" confirming that the code is syntactically correct and doesn't break any behavior your tests cover.

Defining Continuous Delivery and Deployment (CD)

While CI focuses on the quality of the code, Continuous Delivery (CD) focuses on the delivery of that code. There are two distinct flavors of CD that are often confused: Continuous Delivery and Continuous Deployment.

Continuous Delivery ensures that every build that passes the CI pipeline is ready to be deployed to production. However, the actual release to the live environment requires a manual trigger. This is common in regulated industries or for high-stakes storefronts where a marketing manager might want to time a release.

Continuous Deployment takes this a step further by removing the manual trigger. Every change that passes the pipeline is automatically pushed to the production environment. This demands deep confidence in your test suite and the observability to catch regressions fast — without it, a bad commit reaches users before anyone notices.

For developers using Coolify for self-hosted SaaS, CD becomes the engine that powers rapid iteration. Once the CI passes, Coolify can automatically pull the latest Docker image and update the running containers with zero downtime.

CI vs CD: the core differences

The primary difference lies in the scope and the ultimate goal. CI is about the developer's experience and code integrity. CD is about the user's experience and the release process.

Feature	Continuous Integration (CI)	Continuous Delivery (CD)
Primary goal	Detect bugs and integration issues early.	Ensure code is always in a releasable state.
Trigger	Triggered by every code commit or push.	Triggered after CI passes successfully.
Key output	A validated code base and test reports.	A deployable artifact (Docker image, ZIP, etc.).
Manual step	Fully automated process.	Manual approval (Delivery) or fully automated (Deployment).

In 2026, the lines are blurring as tools become more integrated. Most teams treat them as a single, fluid pipeline where code flows from a developer's IDE directly into a staging or production environment.

Implementing CI for Laravel applications

Laravel provides a robust foundation for CI because of its built-in testing capabilities. When setting up a pipeline, you should aim for a "clean room" environment. This means using Docker to ensure the CI environment exactly matches your production environment.

A typical GitHub Actions workflow for Laravel might look like this:

name: Laravel CI

on: [push, pull_request]

jobs:
  laravel-tests:
    runs-on: ubuntu-latest
    services:
      mysql:
        image: mysql:8.0
        env:
          MYSQL_DATABASE: testing
          MYSQL_ALLOW_EMPTY_PASSWORD: "yes"
        ports:
          - 3306:3306
        options: >-
          --health-cmd="mysqladmin ping"
          --health-interval=10s --health-timeout=5s --health-retries=5

    steps:
      - uses: actions/checkout@v4
      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: "8.3"
      - name: Install Dependencies
        run: composer install --prefer-dist --no-interaction
      - name: Execute Tests
        run: vendor/bin/phpunit

This simple script ensures that no code can be merged into the main branch unless it passes every test case. It creates a safety net that allows the team to innovate without the fear of breaking the core application logic.

CD best practices for Shopify storefronts

Shopify development has traditionally been a manual process of editing themes in the browser. However, with the rise of agentic commerce on Shopify, the need for professional CI/CD has skyrocketed.

For Shopify, CD is about managing "theme versions" rather than server binaries. Using the Shopify CLI, you can automate the deployment of theme changes to different environments.

Staging stores: Always deploy to a development or staging store first.
Theme checks: Use shopify theme check in your CI pipeline to catch Liquid errors before they go live.
Atomic deploys: Push your code to a new, unpublished theme ID. Once verified, use the CLI to publish it as the live theme. The cutover is instant, so customers never see a half-deployed storefront — a blue-green flavor of deployment for e-commerce.

A broken layout or a missing "Add to Cart" button caused by a Liquid syntax error never reaches the live store.

The bridge: automation and quality

The real power of CI/CD is realized when you move beyond simple tests and start incorporating advanced checks. Modern pipelines in 2026 often include visual regression testing, where the system takes screenshots of the UI and compares them to the previous version to detect unintended layout shifts.

For teams building API gateways for the AI stack, CI/CD is non-negotiable. When your application relies on LLMs or external APIs, the pipeline must include integration tests that verify these connections are still active and behaving as expected.

Takeaways

CI is for quality: Use Continuous Integration to run tests, lint code, and check for security vulnerabilities on every push.
CD is for delivery: Use Continuous Delivery to automate the packaging and deployment of your app to staging or production.
Speed is a feature: Keep your pipelines fast. A CI pipeline that takes 30 minutes to run is a pipeline that developers will try to bypass.
Immutable artifacts: Build your application once (e.g., a Docker image) and promote that same artifact through staging and production.
Zero downtime: Use strategies like blue-green deployments or symlink swaps to ensure users aren't interrupted during a release.
Shift left: Move security and quality checks as early in the process as possible to reduce the cost of fixing bugs.

If your deployment process still involves a "deployment checklist" that a human has to follow, you aren't doing CD. Automation is the only way to scale a modern software business without scaling the frequency of production outages.

How much time does your team spend manually verifying releases before they go live? If you want a pipeline that does it for you, here's how I help teams automate delivery.

API vs MCP: connecting AI systems

Mon, 01 Jun 2026 00:00:00 GMT

Your AI agents are currently trapped in a silo of brittle, custom-coded API integrations that break the moment you update a schema. You spend weeks writing boilerplate glue code just to give a Large Language Model (LLM) access to a single database or a CRM. This manual mapping of endpoints to prompts is the hidden tax of modern AI engineering. It creates a maintenance nightmare where every new tool requires a fresh round of documentation reading and prompt tuning.

The friction is real. While APIs have powered the internet for decades, they were never designed for the non-deterministic, reasoning-heavy nature of AI agents. We are moving from a world of hard-coded connections to a world of dynamic capability discovery. This is where the Model Context Protocol (MCP) enters the chat.

The API era: the power grid of the web

Traditional APIs (Application Programming Interfaces) are the foundation of modern software. Whether it is a RESTful endpoint, a GraphQL query, or a gRPC stream, the core concept is the same. It is a defined contract for software-to-software communication. You know exactly what input to send, and you get a predictable output in return.

In the context of AI development, APIs are like the power grid. They provide the raw energy and data your application needs to function. If you are building a Shopify application, you use the Shopify Admin API to fetch orders or update inventory. The logic is rigid, the schemas are fixed, and the developer is responsible for knowing exactly which endpoint to call at which time.

The problem arises when you want an LLM to use these tools. You have to write "tool definitions" or "function schemas" that describe the API to the model. You are essentially translating the API documentation into a format the model can understand. This works for one or two tools, but it does not scale to an entire ecosystem of internal data sources and external services.

What is Model Context Protocol?

The Model Context Protocol (MCP) is an open standard introduced by Anthropic to solve the "M x N" integration problem. In a traditional setup, if you have M different AI clients (like Claude, ChatGPT, and an internal agent) and N different tools (like GitHub, Slack, and your internal DB), you have to build M x N individual integrations.

MCP changes this to an M + N problem. By creating a standardized "universal plug," any MCP-compatible AI client can connect to any MCP-compliant server. Think of it as the USB-C of the AI world. Instead of writing custom code to explain how to search your database, you host an MCP server that describes its own capabilities. When the AI agent connects, it "discovers" what the server can do without you having to hard-code the instructions.

This protocol uses JSON-RPC 2.0 under the hood. It allows for bidirectional communication, meaning the server can provide tools, resources (like files or data), and even prompt templates to the model. This is a massive shift from the stateless, request-response nature of most web APIs.

Structural differences: discovery and consumers

The fundamental difference between API and MCP lies in who consumes the interface and how they find what they need.

Feature	Traditional API	Model Context Protocol (MCP)
Primary Consumer	Human Developers	AI Agents & LLMs
Discovery	Manual (Reading Docs)	Automatic (Self-describing)
Interface	Heterogeneous (REST/GraphQL)	Standardized (JSON-RPC)
State	Mostly Stateless	Stateful Sessions
Flexibility	Rigid / Pre-scripted	Dynamic / Reasoning-based

APIs are built for humans to read and implement. You look at a Swagger UI, understand the authentication, and write a fetch request. MCP is built for models to navigate. An MCP server provides a list of tools and resources along with natural language descriptions. The model uses its reasoning capabilities to decide which tool to call based on the user's intent.

If you are comparing AI vs traditional development, this is a prime example of the shift. Traditional development is about building the pipes. AI engineering with MCP is about building the connectors that allow the model to choose its own pipes.

Why AI agents need MCP for scale

Agentic systems require a level of autonomy that traditional APIs struggle to provide efficiently. When an agent is tasked with "researching a company and drafting a proposal," it might need to hit a search tool, a CRM, a file system, and a PDF generator.

Using standard APIs, you would need to feed the descriptions of all those endpoints into the model's context window. This eats up tokens and increases the risk of the model getting confused. With MCP, the client negotiates capabilities at connection time and the agent calls tools on demand, so you can surface only the tools relevant to the task instead of pre-loading every schema. The result is less wasted context and fewer irrelevant choices for the model to wade through.

Furthermore, MCP defines a "resource" primitive. Unlike an API endpoint that just returns data on request, an MCP resource can be subscribed to, so the server pushes a notification when the underlying file or record changes. For lightweight retrieval-augmented generation (RAG) cases, an MCP server can expose your local files or database directly to the model in a standardized way, sparing you a custom ingestion layer for every experiment. It does not replace a vector store for large-scale semantic search, though — get that wrong and you hit the usual production RAG mistakes.

Implementation: how they work together

It is important to realize that MCP does not replace APIs. In fact, MCP usually wraps existing APIs. Your business logic, security constraints, and data persistence still live in your core services.

Consider a scenario where you have a Laravel backend. You have a set of REST endpoints for managing customer orders. To make these accessible to an AI agent, you would build a small MCP server (perhaps using Node.js or Python) that sits between the agent and your Laravel API.

The MCP server handles the "translation" layer. It describes the get_order_history tool in a way that an LLM understands. When the LLM calls that tool through the MCP protocol, the MCP server executes the actual REST call to your Laravel backend, receives the JSON, and passes the relevant context back to the model.

This separation of concerns allows your core engineering team to focus on building robust APIs while your AI team focuses on creating the MCP wrappers that enable agentic behavior.

Choosing the right tool for the job

When should you stick to direct API calls, and when should you implement MCP? The answer depends on the complexity of your integrations and the role of the LLM.

Use direct APIs when:

You have a simple request-response flow with no AI reasoning involved.
You need absolute minimum latency for high-throughput systems.
You are performing deterministic tasks like processing payments or bulk data migrations.
You only have one or two integrations that rarely change.

Use MCP when:

You are building complex agents that need to use three or more tools.
Your tools and data sources change frequently.
You want your tools to be reusable across different AI clients (e.g., Claude Desktop and custom IDE tools).
You need to expose local data or specialized resources to an LLM without building a custom backend for every experiment.

One boundary worth drawing early: MCP covers the agent-to-tool axis only. The moment two agents need to delegate work to each other, you are in a different protocol's territory — see MCP vs A2A vs ACP for how the two layers stack.

Takeaways

APIs are the "what" (the data and logic), while MCP is the "how" (how the AI interacts with that data).
MCP eliminates the M x N integration problem by providing a universal protocol for AI tool discovery.
Traditional APIs are designed for deterministic software-to-software paths; MCP is designed for non-deterministic AI-to-tool reasoning.
Implementing MCP often involves wrapping existing REST or GraphQL APIs to make them self-describing for LLMs.
Using MCP reduces token waste and prompt complexity by standardizing how context is shared with the model.
For modern AI engineering, MCP is becoming the standard layer for building scalable agentic workflows.

What is the biggest friction point you face when giving your AI agents access to your internal production databases? If you're wiring MCP into a real product, here's how I help teams ship it.

Ditch expensive cloud providers for self-hosted SaaS

Sat, 30 May 2026 00:00:00 GMT

Most SaaS founders are quietly getting robbed by their own cloud provider.

I have spent over a decade building and scaling web applications, and if there is one thing I have learned, it is that the "cloud tax" is the most effective way to kill your margins before you even find product-market fit. We have been conditioned to believe that unless our small CRUD app is running on a multi-region, auto-scaling AWS EKS cluster, we are doing it wrong.

That is a lie designed to keep you paying for complexity you do not need.

The architecture of a trap

It starts innocently enough. You sign up for AWS or GCP because they give you $1,000 in credits. You spin up an RDS instance for your database, a few S3 buckets for storage, and maybe a managed Kubernetes service because it feels "professional."

Then the credits run out.

Suddenly, you are paying $200 a month for a database that is 99% idle. You are paying for NAT gateways, provisioned IOPS, and "management fees" for services that could easily run on a $5 VPS. You are stuck in a web of proprietary APIs and IAM roles that require a full-time DevOps engineer just to update an environment variable.

This is the agitation: managed services feel like a superpower at the start, but they become a golden cage as you scale. The complexity overhead alone is enough to slow your development velocity to a crawl. When I look at how AI is changing traditional development, it becomes clear that we need to move faster, not get bogged down in infrastructure molasses.

Enter Coolify: Heroku's open-source soulmate

The solution I have moved my entire stack to is Coolify.

Coolify is an open-source, self-hostable alternative to Vercel, Heroku, and Netlify. It gives you that same "git push to deploy" experience we all love, but it runs on your own hardware. Whether you have a small ARM VPS on Hetzner (the CAX11 starts around €6/month) or a free ARM instance on Oracle Cloud, Coolify turns it into a private PaaS.

I recently wrote about how Coolify and Docker are changing SaaS hosting, but the shift is deeper than just a tool change. It is a mindset shift toward technical sovereignty.

Here is what makes Coolify a game-changer for a senior engineer:

Zero vendor lock-in — your configurations are stored on your server. If Coolify disappeared tomorrow, your Docker containers would keep running.
Automatic SSL — it handles Let's Encrypt out of the box. No more messing with Nginx configs or certbot.
Database management — you can spin up Postgres, MySQL, Redis, or MongoDB in one click. They run as containers on your server, meaning you pay $0 in additional managed service fees.
Pull request deployments — it creates temporary environments for every PR, just like Vercel, but without the "team seat" tax.

The magic of ARM (Graviton and OCI)

Once you have self-hosting in place, ARM is the multiplier that takes the bill from "cheap" to "almost free." Stop renting x86 and start renting ARM.

AWS pegs its Graviton instances at up to 20% lower cost and up to 40% better price-performance than comparable x86 instances. But the real "cheat code" right now is Oracle Cloud Infrastructure (OCI). Its "Always Free" tier gives you 2 ARM Ampere A1 OCPUs and 12 GB of RAM at no cost, forever (Oracle halved this from 4 OCPUs / 24 GB in mid-2026, so size accordingly).

I can run a small production workload — frontend, backend, database, and Redis — on that single free instance using Coolify.

When you pair ARM efficiency with a self-hosted orchestrator, the math changes. A startup that was paying $500/month on AWS can often move that entire workload to a sub-$15/month ARM instance on Hetzner — or to OCI's free tier outright. That difference goes straight back into your runway or your marketing budget.

Docker and Nix: the engine room

Coolify relies heavily on Docker, which is the industry standard for a reason. It ensures that what works on my machine works on the server. But as I move deeper into the "vibe coding" era, I'm also looking at how technologies like Nix can further stabilize our environments.

By using Nix flakes to define our development environment and Docker to package the runtime, we create a bulletproof deployment pipeline. When I use tools like the Model Context Protocol (MCP), I want my AI agents to have a clear, reproducible environment to work within. Self-hosting doesn't mean "unprofessional" — it means having total control over the stack.

Comparison: the hidden cost of "easy"

Let's look at the numbers for a standard Laravel or Node.js app with a database and a background worker.

The managed path (Vercel + Supabase + AWS S3):

Vercel Pro: $20/month per user
Supabase Pro: $25/month
AWS S3 + bandwidth: $15/month
Total: $60+/month (and rising with every user/teammate)

The Coolify path (Hetzner VPS):

4 vCPU ARM / 8GB RAM (CAX21): ~$12/month
Backups to S3-compatible storage: $1/month
Coolify: $0 (open source)
Total: ~$13/month

The "managed" path costs roughly 5x more before you even have your first 100 users — and that gap widens with every teammate and every GB of egress. For a senior engineer, the half hour it takes to install Coolify on a fresh Linux box is worth the thousands of dollars saved over the life of the project.

Practical steps to a self-hosted SaaS stack

If you are tired of the cloud tax, here is my recommended path to freedom:

Grab a VPS — I recommend Hetzner for raw performance/price or OCI for their insane free tier. Pick an ARM-based instance (Ubuntu 24.04).
Install Coolify — run the one-line install command from their documentation. It takes about 5 minutes.
Connect your Git — link your GitHub or GitLab account.
Dockerize your app — if you are using Laravel, it is as simple as adding a Dockerfile. For Vite or Next.js, Coolify has built-in builders that don't even require a Dockerfile.
Move your DB — export your managed DB and import it into a Coolify-managed container. Set up S3 backups immediately.

The bottom line

We are entering a cycle where efficiency is the only thing that matters. The days of "VC-subsidized" infrastructure are over. Whether you are building a small tool or a massive enterprise SaaS, you owe it to your bottom line to look at self-hosting.

Coolify has matured to the point where the developer experience is indistinguishable from the big players. The only difference is who owns the keys to the castle. And when you do outgrow a single box, the platform scales with you — I cover that in advanced Coolify deployment strategies.

I am curious: what is the most "expensive" mistake you have ever made on a cloud bill — a forgotten NAT gateway or a runaway Lambda function? Drop a note via contact. 🤘

Machine learning vs generative AI

Sat, 30 May 2026 00:00:00 GMT

Your data is likely sitting idle in a warehouse while competitors ship agentic systems that write code and predict churn in the same stack. Choosing the wrong architectural path between traditional machine learning and generative AI burns GPU credits and ships models that hallucinate when they should be calculating.

Marketing hype blurs the line between these two technologies, and stakeholders use the terms interchangeably. That mismatch breeds technical debt. Build a generative model for a task that demands strict mathematical precision and you set yourself up for failure. Rely on traditional models for creative automation and your product feels rigid and outdated.

The fix is understanding the engineering differences between predictive and creative systems. This guide breaks down machine learning vs generative AI so you can build scalable, high-performance applications with confidence. If you want to zoom out first, my breakdown of AI vs machine learning shows where both sit in the broader AI hierarchy.

Machine learning: the logic of prediction

Traditional Machine Learning (ML) is the backbone of modern data science. It is primarily a discriminative technology. This means its job is to distinguish between different types of data or to predict a numerical value based on historical patterns. When you use an ML model, you are essentially asking it to categorize an input or forecast a trend.

Machine Learning models thrive on structured data. They look at rows and columns in a database to find correlations. For instance, a regression model might analyze thousands of Shopify transactions to predict next month's revenue. A classification model might look at server logs to identify a potential DDoS attack.

The architecture of traditional ML is often task-specific. You train a model for one specific purpose. If you want to detect fraud, you train a fraud detection model. That model cannot suddenly start recommending products. It is a precision tool designed for a single objective. This specialization makes ML highly efficient for high-stakes environments where accuracy and predictability are the metrics that matter most.

Generative AI: the architecture of creation

Generative AI (GenAI) represents a paradigm shift. While traditional ML analyzes data to make a choice, GenAI uses data to create something entirely new. It is built on deep learning architectures, specifically Transformers and Diffusion models. These systems do not just classify data. They learn the underlying probability distribution of their training set to generate novel outputs.

When you prompt a frontier Large Language Model (LLM) like Claude or GPT, you are interacting with a generative system. It predicts the next most likely token in a sequence, but the result is a coherent piece of text, a code snippet, or an image. This creative capability is what makes GenAI so versatile for building agentic commerce solutions on Shopify.

GenAI models are often foundation models. They are trained on massive, unstructured datasets and carry billions of parameters. This allows them to perform a wide variety of tasks without needing to be retrained from scratch. A single model can summarize a legal document, write a Python script, and brainstorm marketing copy. This flexibility is its greatest strength, but it also introduces the risk of hallucinations.

Machine learning vs generative AI: discriminative vs generative models

The fundamental technical difference between machine learning and generative AI lies in their mathematical objectives. To understand which one to deploy, look at how each one processes information.

Discriminative models (traditional ML)

Discriminative models learn the boundary between classes. Mathematically, they model the conditional probability P(y | x). This means "given the input x, what is the probability of the label y?"

Focus: Determining the difference between data points.
Output: A discrete label (Spam/Not Spam) or a continuous value (Price).
Efficiency: Typically requires less computational power for inference.
Example: A Random Forest algorithm identifying fraudulent credit card transactions.

Generative models (GenAI)

Generative models learn how the data itself is distributed. They model the joint probability P(x, y) or the probability of the input itself P(x). This means "what does a typical example of this data look like?"

Focus: Understanding the structure of the data to replicate it.
Output: New data samples (Text, Image, Audio).
Efficiency: Highly resource-intensive, requiring specialized GPUs.
Example: A Transformer model generating a new Laravel controller based on a prompt.

Feature	Machine Learning (Discriminative)	Generative AI (Generative)
Primary Goal	Classify or Predict	Create New Content
Data Type	Structured (Tables, Logs)	Unstructured (Text, Images)
Output Type	Numbers, Labels, Scores	Content, Code, Media
Model Complexity	Low to Medium	Very High
Training Data	Task-Specific, Labeled	Massive, Unlabeled/Self-Supervised

Use cases: when to choose one over the other

Choosing the right tool depends on your business goals and the nature of your data. Using an LLM to predict a stock price is an expensive mistake. Using a linear regression model to write a blog post is impossible.

When to use Machine Learning

Machine Learning is superior for tasks requiring high precision and deterministic logic. If you are working through complex technical challenges in a real product, ML is often the right choice for the "back-office" logic.

Fraud Detection: Identifying anomalies in financial transactions where false positives must be minimized.
Inventory Forecasting: Predicting stock levels for an e-commerce store based on seasonal trends.
Recommendation Engines: Ranking products for a user based on their previous browsing history.
Medical Diagnostics: Analyzing lab results to flag specific health markers.

When to use Generative AI

Generative AI shines when you need to bridge the gap between human language and machine logic. It is the perfect tool for building intuitive interfaces and automating creative workflows.

Code Generation: Automating the creation of boilerplate code or converting legacy code to modern frameworks like Laravel and Vue.js.
Content Personalization: Generating unique product descriptions or email subject lines for thousands of customers.
Search and Retrieval: Using Retrieval-Augmented Generation (RAG) to allow users to "chat" with their own documentation. You can learn more about this in our guide on common RAG mistakes.
Prototyping: Quickly generating UI mockups or synthetic data to test a new application.

The hybrid future: combining ML and GenAI in production

In 2026, the most successful engineering teams are not choosing one over the other. They are building hybrid architectures. These systems use traditional ML for the "heavy lifting" of data processing and Generative AI for the user-facing interaction layer.

Consider a modern customer support system. A traditional ML model can be used to perform sentiment analysis and route the ticket to the correct department based on urgency. Once the ticket is routed, a Generative AI agent can draft a response using internal knowledge bases. This combination ensures that the system is both efficient and empathetic.

Another example is in the realm of AI vs traditional development. We often see systems where an ML model predicts which users are likely to churn. A Generative AI model then creates a custom discount offer and a personalized email specifically tailored to that user's interests to keep them engaged.

DevOps and deployment considerations

Deploying these systems requires different infrastructure strategies. Traditional ML models are often small enough to run on standard CPUs or even on edge devices. They are easy to containerize using Docker and can be hosted cheaply on platforms like Coolify or AWS.

Generative AI models are a different beast. Even "small" LLMs require significant VRAM, and the cost profile of training vs inference shapes every hardware decision you make. If you are self-hosting, you need robust GPU orchestration. Many businesses opt for API-based solutions like Claude or OpenAI to avoid the overhead of managing hardware. However, for those concerned with data privacy or high-volume usage, deploying open-weights models on Google Cloud or AWS with specialized inference servers is the standard approach.

Whichever technology you choose, keep the architecture clean: containerize for environment consistency, and monitor the right failure mode. Track model drift in ML and hallucination rates in GenAI. That rigor is what keeps your AI solutions scalable and maintainable over time.

Takeaways

Define your goal first: Use Machine Learning for prediction and classification. Use Generative AI for content creation and reasoning.
Data type matters: ML excels with structured, tabular data. GenAI is built for unstructured data like text, images, and code.
Cost and latency: Traditional ML is generally cheaper and faster to run. GenAI requires significant computational power and has higher latency.
Hybrid is better: Combine the precision of ML with the flexibility of GenAI to build robust, modern applications.
Infrastructure: Plan your deployment early. Use containerization and cloud-native services to handle the specific hardware requirements of each technology.
Avoid the hype: Don't use an LLM just because it is trending. Choose the model that solves the engineering problem most efficiently.

Is your current data strategy focused on predicting what will happen next, or are you ready to start creating the outcomes you want to see? If you're wiring either into a real product, here's how I help teams ship it.

Laravel Octane for high-traffic PHP apps

Fri, 29 May 2026 00:00:00 GMT

Standard PHP is a bit like a restaurant that fires its entire staff and rebuilds the kitchen from scratch for every single customer order. You walk in, they hire a chef, buy a stove, cook your meal, and then demolish the building as soon as you leave. It's consistent and safe, but it's a massive waste of energy when you're trying to serve thousands of people at once.

This is the PHP-FPM lifecycle. Every request boots the entire Laravel framework, loads your service providers, parses your config, and instantiates your objects. For low-traffic sites, it's fine. But when you hit real scale — say, a busy multi-tenant SaaS — those milliseconds of "boot time" become a wall you can't climb without throwing excessive amounts of expensive hardware at the problem. Horizontal scaling buys you room, but it doesn't fix the underlying latency.

The solution is to stop rebuilding the kitchen. Laravel Octane changes the game by booting your application once, keeping it in memory, and then feeding requests to it through a high-performance worker pool. It transforms PHP from a "short-lived script" language into a "long-lived process" powerhouse.

Why your app feels heavy without Laravel Octane

The overhead of traditional PHP isn't just about speed; it's about efficiency. In a standard request, your CPU spends a significant chunk of time just getting the application ready to do work. Once it finally starts execution, it does the database query, renders the view, and then dies.

If you're running a complex Laravel monolith with dozens of packages and custom service providers, your boot time might be 30ms to 50ms before a single line of your actual business logic even runs. Under high traffic, this leads to CPU thrashing. You're paying for the "setup" over and over again.

Laravel Octane removes this boot cycle. By using high-performance application servers like Swoole or RoadRunner, your app stays resident in memory. The first request boots the framework, and subsequent requests hit a "warm" application. We're talking about moving from 50ms responses to sub-10ms responses just by changing how the process is managed.

Choosing your application server

Octane runs on top of a high-performance application server. It supports four: FrankenPHP, Swoole, Open Swoole, and RoadRunner. FrankenPHP (a Go-based server built on Caddy) is the server Octane recommends first when octane:install prompts you, and it's the easiest path to HTTP/2, HTTP/3, and automatic HTTPS. But the two I reach for most in production are Swoole and RoadRunner, and they solve the "persistent state" problem differently.

Swoole

Swoole is a C extension for PHP. It's essentially a high-performance networking engine that allows PHP to handle asynchronous tasks, coroutines, and long-lived connections.

Pros — it is incredibly fast. Because it lives as an extension, it has deep access to PHP's internals. It also unlocks the Octane cache, an in-memory store (backed by Swoole tables) that the docs clock at up to 2 million reads/writes per second, plus concurrent tasks, ticks, and intervals.
Cons — it can be a bit of a nightmare to install and debug. Because it's a binary extension, you have to compile it or find the right package for your OS. Xdebug doesn't always play nice with it, and it can be picky about your environment.

RoadRunner

RoadRunner is written in Go. It acts as a load balancer and process manager that communicates with your PHP workers via a high-speed binary protocol (Goridge).

Pros — no extensions required. It's a single binary you drop into your project. It's much easier to set up in a Docker container and generally feels more "cloud-native."
Cons — it's slightly slower than Swoole because of the communication overhead between the Go binary and the PHP processes, though for 99% of apps, this difference is negligible.

For most developers starting out, I'd pick FrankenPHP at the install prompt and not overthink it — it's the smoothest setup and ships HTTP/3 for free. RoadRunner is the easy pick if you want a single Go binary with no PHP extension to manage. Reach for Swoole only when you're chasing every last millisecond or need its concurrency features like async task workers, ticks, and the Octane cache.

Tuning your worker pool

The secret sauce of Octane is the "worker pool." Instead of one process per request, you have a fixed number of workers waiting to handle incoming traffic. If you misconfigure this, you'll either leave performance on the table or crash your server.

A general rule of thumb for sizing your worker pool depends on whether your app is CPU-bound or I/O-bound.

CPU-bound apps — if you're doing heavy data processing or image manipulation, set your worker count to the number of CPU cores you have. Adding more workers will just cause context switching and slow things down.
I/O-bound apps — most web apps spend 90% of their time waiting for a database, Redis, or an external API. In this case, you can scale your workers to 2x or even 4x your core count. This allows one worker to wait for the DB while another handles a new request.

# Starting Octane with 16 workers for an I/O-heavy app
php artisan octane:start --server=swoole --workers=16

Don't forget about task workers if you're using Swoole or Open Swoole. Sized separately with the --task-workers flag, these run in their own processes and are perfect for offloading slow work like sending emails or fanning out concurrent queries without blocking the main request cycle.

The danger of persistent state

The biggest hurdle when moving to Octane is the shift in mindset. In traditional PHP, "leaky" code doesn't matter much because the process dies after 100ms. In Octane, a memory leak is a ticking time bomb.

If you have a static array in a service provider that you append to on every request, that array will grow until your server runs out of RAM. You have to be extremely careful with:

Static properties — avoid using them for request-specific data.
Singletons — if you register a singleton in your app container, it stays alive. If that singleton caches data, you need to make sure that data is cleared or managed properly between requests.
Global state — avoid global variables at all costs (which you should be doing anyway).

Laravel helps you by "resetting" some core services between requests, but it can't catch everything. If you're migrating an old codebase from monolith to microservices, you'll want to audit your service providers for any long-lived state.

Protecting yourself with max-requests

The best insurance policy against memory leaks is the --max-requests flag. This tells Octane to gracefully restart a worker after it has handled a certain number of requests. Octane already does this every 500 requests by default; tune the number to match how fast your workers accumulate memory.

# Restart workers every 1000 requests to prevent memory bloat
php artisan octane:start --max-requests=1000

This keeps your memory usage predictable while still giving you the performance benefits of a warm application.

Real-world optimization tips

Once you have Octane running, there are a few technical levers you can pull to squeeze out even more performance.

Database connections — in Octane your workers stay alive, so each one holds its own DB connection open between requests instead of reconnecting every time. That's a win, but watch the math: more workers means more open connections, so check your database.php config and make sure the worker count doesn't blow past the max connection limit on your DB server. This matters even more once you add read replicas to the mix.
Octane cache — if you're using Swoole, reach for Cache::store('octane'). It's an in-memory Swoole table that's blistering fast and shared across every worker on the box. Use it for frequently accessed configuration or small datasets that don't change often. Just remember it's wiped when the server restarts.
Bytecode caching — make sure OPcache is enabled and tuned. Set opcache.validate_timestamps=0 in production since your code won't be changing while the server is running.
Graceful reloads — when you deploy new code, use php artisan octane:reload. This will gracefully restart the workers without dropping current connections. It's essential for zero-downtime deployments.

Takeaways for the high-traffic dev

Transitioning to Octane isn't just about installing a package; it's about maturing your infrastructure.

Identify the bottleneck — only use Octane if your boot time is the problem. If your database queries take 2 seconds, Octane won't help you.
Test for leaks — watch how your app behaves under sustained load and profile its memory growth over time.
Monitor workers — keep an eye on your CPU and RAM usage to find the "sweet spot" for your worker count.
Leverage concurrency — on Swoole, use Octane::concurrently() to run independent operations in parallel via task workers and return their results together, cutting total response time for complex pages.

Octane takes PHP to a level where it can compete with Node.js and Go for high-concurrency applications while keeping the developer experience of Laravel intact. If you're building a SaaS that expects a lot of noise, this is your jet engine.

Are you running Octane in production yet, or is the fear of memory leaks keeping you on PHP-FPM? Drop a note via contact — let's talk worker counts. 🤘

Shopify UCP quick-start: make your store agent-ready

Thu, 28 May 2026 00:00:00 GMT

Your store is effectively invisible to the biggest spenders of 2026. I'm not talking about Gen Z or Alpha. I'm talking about AI agents.

If Google's AI Mode or the Gemini app can't find a machine-readable map of your Shopify store, it won't recommend your products. It definitely won't buy from you.

Traditional SEO was built for humans with eyeballs. The Universal Commerce Protocol (UCP) is built for agents with wallets.

The rollout is moving fast. Until you expose that manifest, you're opting out of the agentic economy.

Here is how to fix that.

Why your legacy SEO is failing

For ten years, we've obsessed over meta tags and JSON-LD schema. That was enough when Google was just a list of links. But we've entered the era of agentic commerce on Shopify.

Agents like Gemini don't "browse" your collections. They don't look at your hero banners. They want to know three things:

What do you sell?
Can I buy it right now?
Which API do I call to checkout?

If your site doesn't answer these questions in a standardized way, the agent moves to a competitor who does. Legacy schema tells an agent what a product is. UCP tells an agent how to transact.

What is the Universal Commerce Protocol?

UCP is an open standard co-developed by Shopify and Google, with backing from a wide cast of retailers and payment providers. It creates a "handshake" between a merchant and an AI agent.

The core of this handshake is the /.well-known/ucp endpoint.

It's a simple JSON file that acts as a discovery manifest. When an agent hits your domain, it looks for this file to understand your capabilities. It's the robots.txt of the AI era, but for money.

Conceptually, the manifest declares which commerce services and capabilities your store exposes and where an agent should call them. The exact schema is still evolving — check the official UCP spec for the current shape — but it looks roughly like this:

{
  "ucp": {
    "version": "2026-04-08",
    "services": {
      "dev.ucp.shopping": ["https://api.yourstore.com/ucp/shopping"]
    },
    "capabilities": {
      "dev.ucp.shopping.checkout": ["create_session", "complete_session"]
    },
    "payment_handlers": {
      "com.shopify.shop_pay": ["https://api.yourstore.com/ucp/pay"]
    }
  },
  "signing_keys": [{ "kid": "store_2026", "kty": "EC", "crv": "P-256" }]
}

This manifest tells the agent exactly which capabilities you support and where to send the request. No scraping required. No "guessing" where the add-to-cart button is.

How to enable UCP on Shopify

If you are running a standard Shopify or Shopify Plus store, the good news is you don't have to write this JSON manually. Shopify is baking this directly into the core.

Shopify auto-enabled Agentic Storefronts for eligible stores, so this is opt-out rather than opt-in — but you should verify it.

To check or change it, open the Agentic sales channel in your Shopify admin (Sales channels > Agentic). By default, Allow Shopify to manage for me is on, which keeps your products in Shopify Catalog and enrolls you in new channels automatically. Turn that off if you want to control Direct checkout and catalog access per channel.

With it enabled, Shopify generates and hosts the manifest under your store's /.well-known/ucp path.

If you are running a headless setup with Hydrogen or a custom frontend, you'll need to ensure your middleware correctly proxies this path back to Shopify's servers. We see a lot of developers break their agentic discovery because their Vercel or Netlify rewrites aren't handling the .well-known directory.

Why this matters now

Search is shifting from links to agents. As Google's "AI Mode" reaches more shoppers and Gemini acts as a default shopping assistant, it will prioritize stores that support the UCP handshake.

This lands alongside Shopify's rollout of MCP context-aware agents. These agents use the Model Context Protocol to link your store's live data directly into the LLM's reasoning loop.

If your manifest is missing, your store is a black box. The agent will see your products in the search index, but it won't be able to fulfill the request "buy me the best hiking boots from a local store." It will choose the store where it can verify the checkout capability instantly.

Auditing your implementation

Don't just flip a switch and hope. You need to verify that your manifest is actually reachable by external bots.

Open a private browser window.
Go to https://yourdomain.com/.well-known/ucp.
You should see a raw JSON object.
If you see a 404 or a redirect to your homepage, your theme or app is blocking the path.

Check your robots.txt file as well. Ensure you aren't accidentally disallowing agents from crawling the .well-known directory.

If you are using a custom Laravel backend to power your Shopify store's logic, make sure your routes file includes a specific entry for this endpoint. At ansezz, we often see custom middleware stripping out these hidden directories for "security" reasons. In 2026, that security is just costing you sales.

Technical takeaways

Here is your agent-readiness checklist:

Enable Agentic storefronts in your Shopify admin.
Verify the /.well-known/ucp path returns valid JSON.
Confirm your payment handlers (Shop Pay, Shopify Payments) are declared in the manifest.
Test your site with an agentic browser or a UCP validator tool.
Check your Coolify Docker SaaS hosting configs if you're hosting custom middleware, to ensure the path isn't being dropped by your reverse proxy.

The transition from a human-centric web to agent-centric commerce is happening whether we're ready or not. UCP is the first real step toward making your store a first-class citizen in the AI economy.

Are you letting agents shop your store, or are you still building only for a world that clicks? If you want help getting your storefront agent-ready, here's how I work with teams.

Claude MCP: connecting my dev tools to LLMs

Wed, 27 May 2026 00:00:00 GMT

Every time I have to build a custom integration for a new tool, a little piece of my developer soul dies. It is a maintenance nightmare that never ends. We have reached a point where building the actual product is often faster than setting up the pipes to make it work with our data — which is exactly the problem Claude's MCP (Model Context Protocol) was built to kill.

If you have spent any time building agentic workflows and vibe coding, you know exactly what I am talking about. You have an LLM like Claude that is incredibly smart but essentially locked in a room with no windows. To give it context, you have to manually copy-paste code, export CSV files, or spend three days writing a brittle wrapper for a third-party API just so your assistant can "see" your work.

This fragmentation is the biggest bottleneck in modern software development. We have powerful models, but they are isolated from our local files, our databases, and our production logs. It is like having a world-class architect who isn't allowed to visit the construction site. They are just guessing based on the photos you decide to send them.

Enter the Model Context Protocol — or, in Anthropic's own framing, a USB-C port for AI applications.

The fragmentation tax is killing your productivity

The problem is simple but massive. Every AI application — whether it is Claude Desktop, a custom agent, or an IDE extension — wants to talk to your data. On the other side, every data source — your GitHub repos, your Postgres databases, your Slack channels — has its own specific API and authentication flow.

Without a standard, we are stuck in an M×N problem. If you have 5 AI apps and 10 data sources, you need 50 different integrations. (If you are weighing whether to expose a plain REST endpoint or an MCP server here, I broke that down in API vs MCP.) This is why most "AI-powered" tools feel shallow. They only support a few basic integrations, and if you want to use your internal company data, you are back to writing custom glue code.

The cost is real. We waste hours rebuilding the same connectors, every new integration is another potential leak, and the "magic" of AI evaporates the moment we hit a data silo.

The solution: MCP as a universal standard

Claude MCP (Model Context Protocol) is the first serious attempt to standardize how AI applications discover and interact with data and tools. Instead of building a specific connector for every model and every tool, you build an MCP server.

This server acts as a translator. It sits between your data and the AI, exposing a consistent interface that any MCP-compliant host (like Claude Desktop) can understand. It is exactly like the USB standard. It doesn't matter if you are plugging in a mouse, a keyboard, or an external drive. The protocol is the same, so it just works.

This shifts the entire paradigm of context-aware agents. Instead of hard-coding logic into the agent, you simply "plug in" the servers you need.

How the architecture actually works

There are three main players in the MCP ecosystem:

The host — this is the environment the user interacts with. It could be Claude Desktop, a terminal, or an IDE like Cursor. The host is responsible for managing the lifecycle of the connection.
The client — this is the part of the host that speaks the protocol. It does the "handshake" with the server to find out what it can do.
The server — this is a lightweight program that provides context (resources), actions (tools), and prompt templates.

For example, if I want Claude to have access to my local project files, I run a local MCP server that exposes those files as "resources." The host (Claude Desktop) asks the server: "what do you have?" The server replies: "I have these 10 files and a tool to run grep searches."

The model can then decide to call the "grep" tool whenever it needs to find a specific function definition. I didn't have to write a single line of logic inside Claude to make that happen. I just connected the server.

Modularity and the MCP server ecosystem

The beauty of this modularity is that once a server is built, anyone can use it. The community has already started building servers for everything you can imagine. I have been using a few in my daily workflow that have completely changed how I code:

A Postgres server — I point Claude at a local or remote database so it can inspect schemas and run read-only queries to help me debug data issues without leaving the chat. Anthropic's original reference Postgres server is now archived, so I lean on a maintained community build.
GitHub's official MCP server — this lets the model search my repositories, list issues, and open pull requests. It is like having a junior dev who actually knows where the code is. GitHub now ships and hosts this itself, with a remote option you authenticate via OAuth.
A Google Drive server — handy when I need to cross-reference technical docs stored in Drive with the actual implementation in my IDE. The reference server is archived too, so I treat it as a starting point rather than something to trust blindly.

Wiring these up is the step that separates chatting with a model from delegating to one — the point where a workflow crosses into the agentic levels instead of staying a faster autocomplete.

This also solves a massive pain point in agentic commerce for Shopify. Imagine an agent that can talk directly to your Shopify store via MCP to check inventory levels or update product descriptions in real-time, all while maintaining a secure, standardized connection.

Security first: the sandbox model

The biggest question I get when I talk about connecting dev tools to an LLM is: "is it safe?"

Security is a first-class concern in MCP's design. The server runs as a separate process that only exposes the specific tools and resources you grant it. (Note: a local stdio server still runs with your normal user privileges — it's process isolation, not a hardened sandbox — so only run servers you trust.)

For local servers, the protocol typically uses stdio (stdin/stdout). This means the server can only talk to the host through a very narrow pipe. It doesn't have open network ports listening for connections. It only exists as long as the host is running it.

For remote servers, MCP standardizes on OAuth 2.1 (with PKCE) for authorization. This allows for fine-grained, scope-based permissions. You can authorize a GitHub MCP server to only read public repositories, or a database server to only access specific tables.

This is a huge improvement over the "give me your master API key" approach that we have seen in the past. We can now treat AI tools with the same "least privilege" mindset we use for any other service in our stack. This is especially important when you are trying to avoid RAG mistakes in production, where data leakage is a top-tier risk.

Why I am betting on MCP

I have been a developer for over a decade, and I have seen plenty of "standards" come and go. What makes MCP different is its simplicity and its backers. Anthropic has made this open source because they realize that the more context a model has, the more valuable it becomes.

We are moving toward a world of "agentic" software development. In this world, we don't just use AI to write snippets of code. We use AI as an orchestrator that can reach into our cloud infrastructure on GCP, check our Docker logs, and suggest fixes for a failing Laravel app.

Without a protocol like MCP, that vision is impossible to scale. It would be too expensive and too risky to build. But with MCP, we are building a world where tools are plug-and-play.

Practical takeaways for senior engineers

If you are ready to start experimenting with this, here is what I recommend:

Install the Claude Desktop app — it is one of the most mature MCP hosts, and a low-friction place to start.
Try the filesystem server — this is the easiest way to feel the power. Give Claude access to a specific folder and watch it navigate your codebase.
Don't build, search first — browse the official MCP Registry before writing anything. The reference repo now keeps only a handful of maintained servers (filesystem, fetch, git, memory, and a few others), and most of the well-known integrations are either archived or maintained by the vendor directly — like GitHub's own server.
Think in tools, not just prompts — start thinking about what "tools" your internal systems could expose. If you have a custom admin panel, could it be an MCP server?

Connecting your dev tools to an LLM isn't just about speed. It is about reducing the cognitive load of switching between tabs, terminals, and documentation. It allows you to stay in the "flow" longer.

Are you ready to stop copy-pasting your code into a chat box and start connecting your tools directly to the brain? What is the one internal tool you wish you could "plug in" to Claude right now? Drop a note via contact — let's figure it out. 🤘

Caching for speed: Redis and semantic layers in RAG

Tue, 26 May 2026 00:00:00 GMT

You finally shipped your RAG pipeline. It works. The retrieval is accurate. The LLM is snappy. But then you look at your cloud bill and your P99 latency. Every single query — even "what are your shipping times?" asked for the tenth time — triggers a full chain of embedding, vector search, and an expensive LLM call.

At scale, this is a disaster. You are essentially paying for the same computation over and over again. Your users are waiting two seconds for answers that should take twenty milliseconds. Your "denial of wallet" risk is through the roof.

The solution isn't a bigger model or a faster vector DB. It's a smarter cache. I'm talking about semantic caching with Redis. It collapses a multi-second chain into a single-digit-millisecond lookup and, at the cache hit rates a busy FAQ bot reaches, can cut your LLM API spend by roughly half.

Here is how I build these systems to handle production traffic.

The two-tier cache architecture

Standard caching relies on exact matches. If a user asks "How do I reset my password?" and another asks "how do i reset my password", they might hit the same key if you normalize the string. But if the second user asks "Can you help me change my password?", a traditional cache fails.

In a modern RAG stack, I use a two-tier approach.

Exact cache — a simple key-value store in Redis. I normalize the query (lowercase, trim, strip punctuation) and hash it. It's your first line of defense. It costs almost nothing and has zero false positives.
Semantic cache — if the exact cache misses, I embed the query and look for "near enough" matches in a Redis vector index. If I find a previous question close enough (roughly 0.9+ cosine similarity, i.e. a cosine distance of 0.1 or less), I serve that cached response instead of hitting the LLM.

This architecture ensures that you never do the heavy lifting twice for the same intent.

Why Redis is the king of semantic caching

Most developers think of Redis as just a key-value store. But with the Redis Vector Library (RedisVL), it becomes a high-performance vector database.

Why use Redis for this instead of your main vector DB like Pinecone or Weaviate?

Latency.

Your main vector DB is likely optimized for searching through millions of document chunks. Your semantic cache is much smaller — it only stores recent queries and answers. By co-locating this cache in Redis, which likely already sits in your application tier, you reduce network hops.

I typically see vector lookups in Redis finish in under 5ms. Compare that to an embedding API call that takes 100ms and an LLM generation that takes 1500ms. The math is simple.

Implementing the semantic layer

The trick to a good semantic cache is the similarity threshold. Too low, and you give users wrong answers (the "semantic trap"). Too high, and you never get a cache hit.

I usually start with a distance threshold of 0.1 for cosine distance, which translates to roughly 90 percent similarity. You can implement this quickly using the RedisVL extensions.

from redisvl.extensions.cache.llm import SemanticCache

# Initialize the cache with a conservative threshold
llm_cache = SemanticCache(
    name="production_rag_cache",
    redis_url="redis://localhost:6379",
    distance_threshold=0.1,
)

# Check for a hit
query = "how do i update my billing info?"
hit = llm_cache.check(prompt=query)

if hit:
    return hit[0]["response"]

# If miss, run full RAG and then store
# response = run_rag_pipeline(query)
# llm_cache.store(prompt=query, response=response)

This simple wrapper handles the embedding of the incoming query, the vector search in Redis, and the logic for returning the most relevant cached response.

Avoid the semantic trap: context and versioning

Semantic caching is powerful but dangerous if you aren't careful. If your underlying data changes, your cache might still be serving old, incorrect information.

I always include a context_version in my cache keys or metadata. If I re-index my product catalog or update my documentation, I bump the version. The cache immediately starts missing for old entries, forcing a refresh with the new data.

Another trap is tenant isolation. If User A asks "what is my balance?", you absolutely cannot serve that cached response to User B. I solve this by partitioning the cache:

Use namespaces — cache:tenant_id:query_hash
Include metadata — add tenant_id to the vector index filters.

This ensures that semantic matches only happen within the correct security boundary. For more on building secure, multi-tenant systems, check out my thoughts on Laravel multi-tenancy which shares similar isolation principles.

Managing TTL and staleness

In a standard cache, you just set an expiry of 3600 seconds and forget it. With a semantic cache, I prefer a tiered TTL strategy.

Exact matches — 1 hour TTL. If the user asks the exact same thing, they probably want the exact same answer.
Semantic matches — 4 hour TTL. These are more expensive to generate, so we want to keep them longer, but we also include a "last validated" timestamp.
Proactive invalidation — if my Shopify store updates a product price, I trigger a Redis worker to purge all cache entries related to that product ID.

This hybrid approach keeps the system responsive without serving stale data. I've written about similar event-driven patterns here if you want to dive deeper into how to handle these updates at scale.

Measuring success: precision and recall

Don't just turn on the cache and walk away. You need to monitor two specific metrics:

Cache hit rate — what percentage of queries are being handled by Redis? I aim for 30–50 percent for general FAQ-style bots.
Semantic precision — are the cached answers actually correct?

I log every semantic hit along with its similarity score. Once a week, I sample hits with scores between 0.85 and 0.92 and manually review them. If I see too many "near misses" that are actually different questions, I tighten the threshold.

Final takeaways for senior engineers

Implementing Redis as a semantic layer isn't just about speed. It's about making your AI systems sustainable. If you are serious about moving from a prototype to a production-ready SaaS, caching is not optional.

Here is your checklist for next week:

Install redisvl and set up a basic vector index in your dev environment.
Implement a two-tier lookup (exact then semantic).
Set your distance threshold conservatively (start at 0.05 or 0.1).
Add a tenant_id or context_version to your metadata to avoid cross-talk.
Monitor your hit rate and watch your API bill drop.

For more technical deep dives into modern architecture, look at 7 RAG mistakes in production to see what else might be slowing you down, or browse the rest of the architecture archive.

What is the one query in your system that keeps hitting your LLM unnecessarily? Drop a note via contact — let's figure out if a semantic cache would have caught it. 🤘

Smart auto-scaling for modern AI apps

Mon, 25 May 2026 00:00:00 GMT

Your AI application is lagging, users are complaining, but your cloud dashboard says everything is fine. Your CPU usage is hovering at a comfortable 20 percent while your inference requests are timing out.

This is the classic scaling trap for AI engineers. Traditional auto-scaling is built for web servers where CPU and memory are the primary bottlenecks. In the world of large language models and vector databases, those metrics are practically useless.

If you wait for your CPU to hit 80 percent before spinning up a new pod, your service will be dead in the water long before the second instance even starts its boot sequence. GPU-bound workloads require a completely different playbook.

To build a resilient, cost-effective AI SaaS, you need to move beyond reactive hardware metrics. You need to scale on intent, queue pressure, and the specific physics of GPU memory.

Why CPU-based auto-scaling lies to you

Most horizontal pod autoscalers (HPA) are configured to watch CPU utilization by default. For a Laravel or Node.js API, this works great. The work is linear — more requests equal more CPU cycles.

AI models are different. The CPU handles the "boring" stuff like tokenization, request routing, and managing HTTP headers. The heavy lifting happens on the GPU.

I have seen production clusters where the GPU is pinned at 100 percent while the CPU sits idle. Kubernetes sees the low CPU usage and thinks the pod is healthy. It might even try to pack more pods onto that node, leading to a catastrophic failure.

GPU utilization vs occupancy: the hardware layer

When you finally switch to monitoring GPUs, you encounter two confusing metrics: utilization and occupancy.

GPU utilization is essentially a duty cycle. It tells you the percentage of time the GPU was active over a sample period. It is a lagging indicator. By the time it hits 90 percent, your request queue has likely been building for 30 seconds.

Occupancy is more granular. It measures how many "warps" or hardware slots are filled within the streaming multiprocessors (SM). You can have high utilization but low occupancy if your batch size is too small.

For scaling, utilization is the baseline, but it isn't the truth. You need to look at what is happening before the request even hits the silicon.

Queue depth: your best leading indicator

If you want to stop fires before they start, monitor your queue depth. In vLLM or SGLang, this is the number of requests waiting for a slot in the inference engine.

Queue depth is a direct predictor of latency. If you know your model can handle 16 concurrent requests before P99 latency starts to climb, set your scaling trigger at 12.

Scaling on queue depth lets you provision capacity while the current hardware is still performing within SLO. It gives you that 60-second head start you need to pull a fresh container and load a 20GB model weights file into memory.

Token velocity and the KV cache

In generative AI, not all requests are created equal. A 10-token summary request is light. A 4,000-token RAG retrieval analysis is a heavyweight.

This is where token velocity and KV-cache usage come in. The KV cache is the GPU memory that stores attention keys and values for in-flight sequences. If your KV cache is nearly full, the engine has to preempt a request to free blocks. In current vLLM (V1), the default recovery is recompute — the victim's cache is discarded and its prompt plus generated tokens are reprocessed from scratch when it resumes. Older vLLM (V0) swapped blocks out to host memory over PCIe instead. Either way you pay for it.

Latency will skyrocket. Your P99 will look like a mountain range.

I recommend scaling based on a combination of:

Token velocity — total tokens per second across all active instances.
KV-cache pressure — the percentage of available cache blocks currently occupied.

When the cache is full, it doesn't matter how low your GPU utilization is. You cannot fit more work onto that chip. You must scale.

Predictive scaling with ARIMA

Reactive scaling is always playing catch-up. Even with fast boot times, there is a delay. For enterprise apps with predictable traffic patterns, I use ARIMA (Auto-Regressive Integrated Moving Average) models to forecast load.

If I know traffic historically spikes at 9:00 am every Monday, I don't wait for the queue to grow. I use a time-series forecast to spin up the "base load" pods at 8:55 am.

This turns your infrastructure into a proactive system rather than a reactive one. You pay for what you use, but you ensure the capacity is there before the first user clicks "Generate."

Practical steps for your stack

Implementing this doesn't have to be a nightmare. Here is how I structure it:

Use KEDA — the Kubernetes Event-Driven Autoscaler is the gold standard. It lets you scale based on Prometheus metrics like queue depth or P99 latency instead of just CPU.
Set TTFT SLOs — measure time-to-first-token (TTFT). This is the most critical metric for user perception. If TTFT P99 exceeds 500ms, you need more replicas.
Blur the lines — don't rely on a single metric. Create a composite score of GPU utilization, queue depth, and cache pressure. Once you have multiple replicas, route across them with GPU-aware load balancing so traffic lands on the least-saturated GPU.
Fix your RAG — sometimes the scaling issue is actually a retrieval issue. If your vector search is slow, the inference engine waits longer, hogging the GPU. Check out these common RAG mistakes to ensure your bottleneck isn't upstream.
Optimize the frontend — for Shopify apps or custom SaaS, ensure your agentic workflows handle retries gracefully when the infrastructure is scaling up.

Scaling AI isn't about having the biggest GPUs. It is about having the smartest triggers. By moving to service-level metrics, you save money on idle compute and save your users from the dreaded "thinking..." spinner.

Are you still scaling on CPU, or have you made the jump to queue-based triggers yet? Drop a note via contact — I love this conversation. 🤘

GPU-aware load balancing for AI inference

Sun, 24 May 2026 00:00:00 GMT

You just scaled your RAG application to a hundred concurrent users. Suddenly, your latency spikes. Some users get their answers in two seconds, while others are staring at a loading spinner for thirty. You check your load balancer and it says everything is fine. CPU is at 40%. RAM is stable. But your GPUs are screaming, and your P99 latency is in the gutter. This is the problem GPU-aware load balancing exists to solve.

The problem is that you are treating your AI models like traditional web servers. Sending a 4,000-token prompt to the same GPU that is currently generating a 50-token summary is a recipe for disaster. Round-robin routing is a relic of the past when it comes to LLM inference. If you don't account for the unique way GPUs handle compute and memory, you aren't just wasting money. You are killing your user experience.

The solution isn't just "more GPUs." It is building a load balancer that actually understands what is happening inside the model. We need to talk about GPU-aware routing, prefill vs decode disaggregation, and why your KV cache is the most valuable asset in your stack.

Why round-robin is a trap for LLMs

In traditional software development, a request is a request. Whether it's a GET /users or a POST /orders, the variance in resource consumption is usually predictable and small. Standard load balancers like Nginx or HAProxy work great here. They look at basic health checks and send traffic to the next available worker.

AI is different. A single request to an LLM has a massive variance in "weight." One user might ask "what is 2+2?" while another uploads a 50-page PDF and asks for a deep analysis. If your load balancer sends both to the same GPU, the heavy request will hog the compute resources, forcing the light request to wait in a queue.

This is why CPU-based metrics are useless. A GPU can be at 100% utilization while performing very different types of work. Some work is compute-bound, meaning it needs raw processing power. Other work is memory-bound, meaning it is limited by how fast data can move in and out of VRAM. To solve this, we have to look deeper into the inference lifecycle.

Prefill vs decode: the performance gap

LLM inference happens in two distinct phases. Understanding the difference between them is the "aha!" moment for GPU load balancing.

The first phase is prefill. This is when the model reads your entire prompt and processes all the tokens at once. It is a heavy, compute-intensive task that builds something called the KV cache (key-value cache). Prefill loves big batches and high-performance tensor cores. It is where the "heavy lifting" happens.

The second phase is decode. This is where the model generates the response one token at a time. Each new token only needs to look at the previously generated tokens and the KV cache. This phase is surprisingly light on compute but incredibly heavy on memory bandwidth. It is slow and long-lived.

When you mix these two on the same GPU without a smart scheduler, the "prefill" of a new request will often pause the "decode" of existing requests. This causes the jittery, stuttering text generation that users hate. By using GPU-aware load balancing, we can prioritize these phases differently across our fleet.

Metrics for the real world

To build a better router, you need to stop looking at CPU and start looking at these four metrics:

Token queue depth — how many tokens are waiting to be processed? This is a much more accurate representation of "load" than simple request counts.
KV cache utilization — GPUs have a limited amount of VRAM. The KV cache stores the "memory" of ongoing conversations. If a GPU's VRAM is 90% full of KV cache, it literally cannot accept a large new prompt, even if it's currently "idle."
Time to first token (TTFT) — this measures the latency of the prefill phase. If your TTFT is climbing, your prefill pool is congested.
Inter-token latency (ITL) — this measures the speed of the decode phase. If this is high, your GPUs are likely memory-bandwidth constrained.

I often recommend using tools like vLLM because they expose these metrics out of the box. You can pipe these into a custom gateway that makes routing decisions based on real-time VRAM availability rather than just "is the server up?"

Prefix-aware routing: reuse the KV cache

Here is a secret — the most expensive part of a RAG request is often re-processing the same system prompt or long context over and over again. If you send five consecutive questions about the same document to five different GPUs, each GPU has to perform the "prefill" phase for that document from scratch.

This is where prefix-aware routing (also called KV-cache-aware routing) comes in. Instead of routing randomly, your load balancer tokenizes the start of the prompt and looks for a GPU that already has that specific content in its KV cache.

By matching the prefix of a prompt to a GPU that already holds those tokens, you skip the prefill work for the shared portion and reuse the cached keys and values directly. That can turn hundreds of milliseconds of TTFT into a near-instant first token, and it is one of the highest-leverage optimizations in a production RAG system. I've written before about common RAG mistakes, and ignoring cache locality is definitely one of them. If you want the layer above this — caching whole responses and embeddings — see Redis and semantic caching for RAG.

Splitting the fleet into specialized pools

As you scale, you should stop treating every GPU as a generalist. A senior move is to create disaggregated inference fleets.

I like to split my GPUs into two pools:

The prefill pool — compute-heavy GPUs (like H100s or B200s) optimized for chewing through large prompts fast. These nodes process the initial context, then "hand off" the KV state.
The decode pool — GPUs you size for memory bandwidth and capacity rather than raw FLOPs (think A100s, or cheaper L40S cards) that focus on churning out tokens for existing requests.

This separation lets you scale based on your specific workload. If your users are uploading huge documents but only asking for short summaries, you scale your prefill pool. If they are having long, chatty conversations, you scale your decode pool.

This is the same logic we use in modern DevOps with Coolify. You wouldn't put your heavy database on the same tiny instance as your frontend — why would you mix your heavy prefill work with your light decode work?

Implementing your first GPU-aware router

You don't need to build a custom engine from scratch to start doing this. Here is the practical path I follow when setting this up for a new SaaS:

Centralize your metrics — use Prometheus to scrape vLLM or TGI metrics from every GPU node.
Use a smart gateway — implement a middleware in Go or Rust (or even a heavy-duty Lua script in OpenResty) that queries these metrics before choosing a target.
Prioritize KV cache — route on prefix overlap when you can. A cheap first approximation is session stickiness: if a node served this conversation_id recently and isn't at 100% KV utilization, send the follow-up there so the warm cache gets reused.
Set hard limits — if a GPU reaches 85% VRAM usage, take it out of the rotation for new prompts until some sessions finish.

Managing AI compute is about moving from "black box" infrastructure to "context-aware" infrastructure. When your load balancer knows the difference between a 10-token greeting and a 10,000-token context window, your costs go down and your users stay happy.

It's easy to get lost in the hype of "agentic systems" and context-aware agents, but none of that matters if your underlying infrastructure is buckling under the weight of unoptimized routing.

If you are still using round-robin for your AI models, what is the biggest bottleneck you are seeing in your P99 latency right now? Drop a note via contact — I love this conversation. 🤘

Circuit breakers: stopping vector DB failures

Sat, 23 May 2026 00:00:00 GMT

You built a beautiful RAG pipeline. It works perfectly on your machine with a few hundred vectors. Then you launch. Traffic spikes. Suddenly your managed vector database starts sweating. A single similarity search that used to take 50ms is now taking 5 seconds. Your web workers are all tied up waiting for responses that aren't coming. The database isn't technically down — but it is slow enough to kill your entire application. Your users see spinning loaders until the request finally times out. This is a classic cascading failure — the kind a circuit breaker exists to stop — and it is the fastest way to drain your "innovation budget" and your users' patience.

The problem is that we often treat external APIs and databases as if they are always healthy. We write code that assumes the vector DB will return results. When it doesn't, we wait. And while we wait, we hold onto memory and CPU cycles. The solution is an old-school electrical engineering concept applied to software: the circuit breaker.

This guide shows you how to wrap your AI infrastructure in protective logic so a slow dependency doesn't take your whole SaaS down with it.

How the circuit breaker pattern works

The circuit breaker pattern is a state machine that sits between your application code and your external service. The idea comes straight out of Michael Nygard's Release It! — it monitors every call you make and has three states that dictate how it handles traffic.

Closed — the healthy state. In the closed state, the circuit is complete. Requests flow through to your vector database or LLM provider normally. The breaker is silently watching. It keeps a count of how many requests failed or took too long. As long as the failure rate stays below your threshold, it stays closed. This is the "everything is fine" mode.

Open — the fail-fast state. Once the failure threshold is hit — let's say 50% of requests failed in the last 30 seconds — the breaker "trips" and moves to the open state. Now, every time your application tries to call the vector DB, the breaker immediately throws an error or returns a fallback response without even attempting the network call. This gives your database room to breathe and recover. It also ensures your application doesn't waste time waiting on a service that is clearly struggling.

Half-open — the recovery test. After a cooldown period, the breaker moves to the half-open state. It allows a small number of "test" requests to pass through. If these test calls succeed, the breaker assumes the service is healthy again and moves back to the closed state. If they fail, it immediately goes back to open for another cooldown cycle. This is a controlled way to probe the system before fully re-engaging.

Why your RAG pipeline needs this

RAG pipelines are particularly vulnerable because they usually involve multiple high-latency network hops. You have to embed the query, search the vector DB, and then call the LLM. If any of these pieces fail or slow down, the whole experience breaks.

Most developers make the mistake of only handling hard errors like a 404 or a 500 status code. But in production, "slow" is often more dangerous than "down." A slow vector DB creates a bottleneck that backs up your entire request queue. By the time you realize there is a problem, your server is out of memory because it is holding open thousands of connections.

If you have read my previous post on 7 RAG mistakes in production, you know that reliability is the difference between a demo and a product. The circuit breaker is your insurance policy against these types of outages.

Implementing fallback strategies

Tripping the breaker shouldn't always mean showing an error message to the user. The best AI systems use fallbacks to maintain a level of service even when parts of the stack are failing.

Hot and cold tiers. You can think of your vector DB as your "hot" knowledge tier. If it fails, you should have a "cold" fallback. Maybe you fall back to a standard keyword search in your primary Postgres or MySQL database. The results might not be as contextually relevant as a vector search, but a "decent" answer is always better than a "timed out" error.

Cached responses. Another strong strategy is semantic caching with Redis. If the circuit is open, you can check the cache for similar queries that were answered recently. Even if you can't generate a fresh answer, you might be able to serve a cached one. This keeps the user moving while your backend recovers.

LLM-only mode. If your retrieval step is what's failing, you can still send the user's prompt to the LLM with a note that external knowledge is currently unavailable. The LLM can then answer based on its general training data. It is a degraded experience, but it is still functional. Transparency here is key — tell the user that the "live" data isn't available so they know to verify the response.

Building it in Laravel

Since I spend a lot of time in the Laravel ecosystem, I lean on patterns that make this easy to implement. You don't need to write the state machine from scratch. A community package like ackintosh/ganesha (a PHP circuit breaker), or a small custom wrapper around the illuminate/http client with a Redis-backed failure counter, gets the job done.

The goal is to wrap your API calls in a block that understands these states. Here is a simplified look at how that logic looks in practice.

When you call your vector DB client, you wrap it in the breaker. If the call fails multiple times, the breaker trips. In the catch block, you handle the CircuitBreakerOpenException by returning your fallback data. This keeps your controllers clean and your architecture robust.

You can also integrate this with your SaaS hosting on Coolify to ensure that your containers don't get killed by health checks just because an external API is slow. The breaker prevents the resource bloat that usually triggers those health-check failures.

Live telemetry and smart routing

Senior engineers don't just set a circuit breaker and walk away. They monitor it. You need live telemetry to see how often your circuits are tripping. Tools like Prometheus or even simple logs piped to a dashboard can tell you a lot.

If you see that your primary vector DB in us-east-1 is constantly tripping but your secondary in eu-west-1 is healthy, you can implement smart routing. Your circuit breaker can act as a signal to your load balancer or internal router to shift traffic to the healthy region.

This kind of event-driven architecture makes your system self-healing. It doesn't wait for a human to wake up at 3am to fix a database. It detects the failure, trips the breaker, uses the fallback, and tries to recover automatically.

Practical steps to get started

If you are ready to harden your AI infrastructure, start here:

Identify your weakest links — list every external call in your RAG pipeline. Usually it is the embedding API and the vector DB.
Define your thresholds — how many slow requests are you willing to tolerate? Start with a 50% failure rate over 30 seconds and a 2-second timeout.
Choose your fallbacks — decide what happens when the breaker is open. Do you show an error, use a cache, or switch to keyword search?
Wrap your clients — use a library to wrap your HTTP or database calls. Don't try to build the state machine logic yourself unless you have a very specific use case.
Monitor the trips — set up an alert when a circuit stays open for more than a few minutes. This usually indicates a major provider outage that needs your attention.

The goal is to fail gracefully. Every system has issues, but the ones that survive are the ones that don't let a small fire in a dependency burn down the whole house.

Have you ever had a slow dependency take down your entire application, or are you still relying on long timeouts and luck? Drop a note via contact — I love this conversation. 🤘

Message queues for heavy-duty document processing

Fri, 22 May 2026 00:00:00 GMT

If you are running your document embeddings inside your request-response cycle instead of behind a message queue, you are playing with fire. I have seen too many junior devs build a beautiful RAG application that falls over the second a user uploads a 50MB PDF. The browser spins, the proxy timeout hits, and the database locks up while your worker tries to chunk 500 pages of legal jargon in real time.

This is the classic "heavy lifting" problem in AI engineering. Document processing — OCR, text extraction, semantic chunking, and embedding — is slow, unpredictable, and resource-heavy. Trying to force it into a synchronous web request is a recipe for a bad user experience and a fragile system.

The solution is decoupling. I'm talking about message queues. In this guide, I'll walk you through why async work belongs in a queue and how to build a production-grade ingestion pipeline that doesn't melt your server. If you want the broker-level foundations first, I cover them in scaling with RabbitMQ.

The synchronous trap

Imagine a user uploads a document to your SaaS. Your code receives the file, sends it to an extraction API, waits for the response, loops through the text to create chunks, sends each chunk to an embedding model, and finally saves it to pgvector.

If the whole chain runs long, you hit a timeout somewhere — a proxy gateway timeout (Nginx defaults to 60s), a PHP max_execution_time, or a platform request cap — and the connection drops. If the embedding API has a momentary blip, the whole process fails, and the user has to start over. Worse, while your server is busy doing this heavy work, it's not responding to other users.

This is where we apply the first rule of senior engineering: if it takes more than 100ms, consider making it async. By moving this work to a message queue, you give your users immediate feedback ("we're processing your file!") while the heavy lifting happens safely in the background.

The anatomy of a document pipeline

A robust RAG pipeline isn't just one big function. It's a series of decoupled stages. I like to break it down into modular steps, each triggered by a message in a queue. This lets you scale different parts of the system independently.

Here is how I usually structure it:

Ingestion & discovery — a user uploads a file. You save it to S3 and push a small message to the queue containing the file_path and tenant_id.
Parsing & normalization — a worker picks up the message, downloads the file, and runs it through a parser like pdfplumber or an OCR service. It emits the raw text to the next queue.
Chunking — this worker takes the text and splits it into semantic sections. Doing this in its own stage means you can easily swap chunking strategies (e.g., recursive character vs semantic) without re-running the heavy parsing step.
Embedding & indexing — the final stage batches the chunks, hits your embedding API (like OpenAI or a local model), and pushes the vectors into your vector DB.

This stage-based approach is exactly what I discuss in my post on 7 RAG mistakes to avoid in production. It provides backpressure control — if your vector DB slows down, the "index" queue grows, but the "parsing" workers keep humming along.

Retries and the beauty of dead letters

In the real world, things break. APIs time out. PDFs are malformed. Workers crash.

A message queue like Redis (with BullMQ or Laravel Queues) or SQS gives you retries with almost no code — though you do have to opt in. BullMQ defaults to a single attempt, so set attempts and a backoff strategy explicitly; Laravel queues take --tries and backoff; SQS retries up to maxReceiveCount. When a worker fails, the message goes back onto the queue to be tried again after a delay. Exponential backoff is your best friend here — don't hammer a failing API every 5 seconds. Wait 10, then 60, then 300.

But what happens when a document simply cannot be processed? Maybe it's a password-protected PDF or a corrupted file. You don't want it retrying forever and clogging up your workers.

This is where a dead-letter queue (DLQ) comes in. After a certain number of failed attempts, the message is moved to the DLQ — a "quarantine" zone. SQS gives you this natively via the queue's redrive policy; with BullMQ or Laravel you route exhausted jobs there yourself (listen for the failed event in BullMQ, or use failed_jobs plus a handler in Laravel). I can then inspect these failed jobs, fix the underlying issue, and re-queue them. It's a safety net that keeps your main production line moving.

Batching for efficiency

If you are processing 10,000 chunks, you do not want to make 10,000 individual API calls to your embedding provider. That's slow and expensive.

Most embedding APIs and vector databases perform much better with batches. A good worker pattern involves pulling multiple messages from the queue (or aggregating them in memory) and sending them as a single bulk request.

In a Laravel environment, I often use job batching to track the progress of a large document. I can see exactly when 95% of a PDF is processed and update a progress bar for the user. If you're interested in how this fits into a larger architecture, check out my thoughts on event-driven pub/sub systems.

Event-driven prefetching

Here is a "senior" tip — queues aren't just for ingestion. You can use them for prefetching.

If a user is chatting with an AI agent and the conversation is heading toward a specific topic, you can fire off a background job to fetch related documents and warm up the cache before the user even asks the next question. This makes your AI feel lightning fast because the context is already "ready" when the retrieval step hits.

By using an event bus, you can decouple the chat interface from these optimization tasks. The chat app just emits a user_asked_question event, and a background worker decides whether it should pre-fetch more data or update the semantic cache.

Monitoring your message queue

Once you move to a queue-based system, your most important metric is no longer just "request latency." You need to watch your queue depth.

If the queue depth is growing faster than your workers can clear it, you have a bottleneck. This is where tools like Docker and Coolify make life easy — I can spin up five more worker containers to handle a sudden surge in document uploads. You can read more about how I manage this infra in my Coolify and Docker guide.

Practical takeaways for your pipeline

Never store large files in the queue — only pass references (like an S3 key). Keep messages small for better performance.
Make tasks idempotent — assume a message might be processed twice. Use upsert instead of insert in your vector DB to avoid duplicates.
Use structured logging — every worker log should include the doc_id and tenant_id. Searching for "why did this file fail?" is impossible without it.
Scale on queue depth — set up your autoscaler to add workers based on how many messages are waiting, not just CPU usage.
Separate worker pools — have one set of workers for "fast" tasks (like metadata updates) and another for "slow" tasks (like OCR/embedding). Don't let a huge PDF upload block a simple name change.

Building a document pipeline is about respecting the time it takes to process data. Move that work into a queue and you get a system that is resilient, scalable, and smooth for your users — instead of one that buckles on the first big upload.

How are you currently handling long-running AI tasks? Are you still fighting with request timeouts, or have you embraced the queue? Drop a note via contact — I love this conversation. 🤘

Rate limiting: protecting your AI wallet

Thu, 21 May 2026 00:00:00 GMT

One runaway agent loop is all it takes to wake up to a $5,000 OpenAI bill.

If you're building AI-powered SaaS or RAG systems, your biggest threat isn't a server crash. It's a "denial of wallet" attack. A buggy client, a malicious user, or even your own experimental agent can spam your API endpoints and burn through your tokens (and credits) in minutes.

Traditional web apps care about requests per second to keep the CPU from melting. In the world of LLMs, we care about tokens per minute to keep the bank account from draining. Standard rate limiting isn't enough anymore. You need an architecture that understands cost, context, and the "noisy neighbor" problem before a single prompt even hits your vector DB.

Why requests per second (QPS) is a lie for AI

In a standard Laravel or Node app, a request is a request. Sure, some take longer than others, but they generally consume similar resources. In AI engineering, one request might be a 50-token greeting, while another is a 128,000-token context dump for a RAG pipeline.

If you only limit requests per second, a single user can stay within their "10 requests per minute" limit while still costing you 100× more than everyone else combined. This is where the noisy neighbor problem becomes a financial crisis.

You aren't just protecting your infrastructure. You're protecting your margins. To do this effectively, we have to move from counting "pings" to counting "value."

The anatomy of a denial of wallet (DoW) attack

A denial of wallet attack is the AI equivalent of a DDoS. The goal isn't necessarily to take your site down. It's to exhaust your API quotas or financial budget until your service stops functioning — or you're forced to pay a massive bill.

I've seen this happen in three ways:

The agentic loop — an autonomous agent gets stuck in a logic loop, calling your tool-use functions repeatedly without a "max steps" ceiling.
The scrapers — malicious bots trying to exfiltrate your entire knowledge base by querying every possible permutation of your RAG system.
The dev mistake — a frontend developer accidentally puts an LLM-powered "autocomplete" on a search bar that triggers on every keystroke.

Without token-aware rate limiting, your provider (like OpenAI or Anthropic) will eventually hit you with a 429 error. But by that time, the damage to your wallet is already done.

Solving the noisy neighbor with hierarchical rate limiting

To solve this, I implement a three-layer rate limiting strategy at the API gateway level. This ensures that even if one tenant goes rogue, the rest of the platform stays healthy.

1. The global provider layer

This is your final line of defense. If your OpenAI quota is 500,000 tokens per minute (TPM), set your internal global limit to 450,000. This leaves a safety buffer so you degrade gracefully on your own terms instead of eating a wall of provider 429s — which means failed user requests and a Retry-After you don't control.

2. The tenant layer

Every customer gets their own bucket. I usually tie this to their subscription tier. A "Pro" user might get 50,000 TPM, while a "Free" user is capped at 2,000. This ensures no single company can eat up your entire global quota.

3. The user/session layer

Inside a single tenant, you still need limits. You don't want one single employee at a customer's company hogging all the tokens allocated to that entire organization. I set these at about 20% of the total tenant capacity.

Implementation: the token bucket algorithm

For most of my builds, I use a token bucket algorithm backed by Redis. It refills tokens at a steady rate and lets a request through only if a token is available — which absorbs short bursts while capping the sustained rate. (For the difference between token bucket and leaky bucket, see rate limiting vs throttling.)

Here is the logic: each user has a "bucket" of tokens. Every time they send a prompt, we estimate the total cost (input tokens + expected max_tokens). If the bucket has enough, they proceed and the tokens are deducted. The bucket refills at a constant rate over time.

If you're building a SaaS on the LEMP stack, you can implement this efficiently in Laravel using middleware and a fast in-memory store like Redis, where atomic increment operations make per-tenant counters cheap and race-free.

// A simplified token-bucket check in Laravel middleware
public function handle($request, Closure $next)
{
    $tenantId = $request->user()->tenant_id;
    $estimatedTokens = $this->tokenizer->estimate($request->input('prompt'));

    if (!$this->limiter->consume("tenant:{$tenantId}:tokens", $estimatedTokens)) {
        return response()->json(['error' => 'token budget exceeded'], 429);
    }

    return $next($request);
}

Token-budget routing and adaptive throttling

What happens when a user hits their limit? Most devs just throw a 429 error. But as a senior engineer, I prefer a more graceful degradation. We call this adaptive throttling.

Instead of a hard "no," you can:

Degrade the model — switch the request from GPT-4o to a cheaper, faster model like GPT-4o-mini.
Truncate the context — if the user is over budget, strip out some of the retrieved RAG documents to lower the input token count.
Queue the request — for non-interactive tasks (like background summarization), move the request to a message queue and process it when the token bucket refills.

This keeps the user experience intact while protecting your margins. It's about being smart, not just being a gatekeeper.

The RAG context: limiting the "hidden" calls

In a RAG (retrieval-augmented generation) system, one user query often triggers multiple backend actions:

One embedding call for the query.
One search query to the vector database.
One (or more) LLM calls for the final answer.

If you only rate limit the final LLM call, your vector database might still get hammered by search queries. You need to treat the entire "RAG flow" as a single unit of work with its own combined budget. There are plenty of common RAG production mistakes to trip over, but rate limiting the whole flow rather than just the LLM call is one of the most overlooked.

Practical steps to protect your system today

If you're launching an AI feature this week, do these three things:

Set a budget threshold — but don't trust it as a hard cap — OpenAI's "monthly budget" is now notification-only: when you cross it you get an email and a dashboard alert, but your API keys keep working and the bill keeps climbing. Anthropic similarly relies on user/org spend limits and alerts rather than a default hard ceiling. Treat these as smoke detectors, not circuit breakers. The real cap — daily or monthly — has to be enforced by you, at the application layer.
Enforce max_tokens — never let a user request an uncapped response. Always set a sane default for max_tokens in every API call.
Implement per-request timeout — if an LLM call takes longer than 30 seconds, kill it. Slow calls are often the symptom of a system that is about to spiral out of control.

Rate limiting isn't just a "security" feature. In the AI era, it's a core part of your business model. You can't scale a product that allows a single user to run up a thousand-dollar bill in their first hour.

Build for fairness. Build for cost. Build for the "noisy neighbor."

Have you ever seen a "denial of wallet" happen in the wild, or are you still running on a wing and a prayer with global provider limits? Drop a note via contact — I love this conversation. 🤘

API gateway: the front door of your AI stack

Wed, 20 May 2026 00:00:00 GMT

Stop exposing your models to the wild.

If you are building a production AI app, sending requests directly from your frontend to a RAG orchestrator or — god forbid — straight to an LLM provider is a liability. It is slow. It is insecure. And it is the fastest way to wake up to a five-figure bill you didn't plan for.

I have spent over a decade building software, and if there is one thing I have learned, it is that engineering for "it works" is not the same as engineering for "it scales." In the world of AI, scale isn't just about traffic. It is about cost, latency, and data safety.

Imagine a "denial of wallet" attack where a malicious script spams your completions endpoint. Without a gatekeeper, your API keys are just sitting ducks. Or worse, imagine a multi-tenant app where one user's prompt accidentally retrieves another user's private data from your vector DB.

This is where the API gateway comes in. It is the first line of defense and the brain of your infrastructure. It handles the boring but critical stuff so your RAG logic can stay focused on actually being smart.

The gatekeeper pattern

At its core, an API gateway is a reverse proxy that sits between your users and your backend services. But for an AI stack, it does more than just forward traffic. It acts as a centralized brain for auth, routing, and rate limiting. (If the distinction blurs for you, I break it down in load balancer vs API gateway.)

When a request hits your gateway, it goes through a gauntlet of checks before it ever touches a model. This "gatekeeper" ensures that every millisecond of GPU time or every cent of token cost is intentional.

Authentication and tenant isolation

In a typical SaaS, authentication is about knowing who the user is. In an AI-powered SaaS, it is about data sovereignty.

If you are building a RAG system, your biggest risk is cross-tenant data leakage. If you want to avoid common RAG mistakes, you must handle identity at the very edge.

I prefer using JWTs (JSON Web Tokens) with custom claims. When a request hits the gateway, I validate the token and extract the tenant_id. That ID is then injected into the headers of the request before it is passed to the RAG orchestrator.

This means the orchestrator doesn't have to "guess" who the user is. It receives a verified x-tenant-id header and uses it to apply metadata filters on the vector database. The user only "sees" data they are allowed to see. No tenant ID? No query. Period.

Smart routing for model flexibility

The AI world moves fast. Today you are using GPT-5. Tomorrow, Claude Sonnet 4.6 might be the better play. Next week, you might want to test a fine-tuned Llama 4 model running on your own infrastructure via Docker and Coolify.

If your model logic is hardcoded into your frontend or a single monolithic backend, switching models is a nightmare. An API gateway solves this with smart routing.

I use the gateway to create "model aliases." Instead of the frontend calling a specific model, it calls a generic endpoint like /v1/chat/completions. The gateway then decides where to send that request based on:

User tier — free users get routed to a cheaper, faster model like GPT-5 mini or Claude Haiku 4.5. Pro users get the heavy hitters.
Versioning — run an A/B test by routing 10% of traffic to a new model version without changing a single line of client-side code.
Failover — if OpenAI is having an outage, the gateway can automatically reroute traffic to an Anthropic backup.

This level of abstraction is what separates a weekend project from a resilient SaaS product.

Rate limiting: protecting the wallet

We used to rate limit to protect our CPUs. Now, we rate limit to protect our bank accounts.

AI requests are asymmetric. A user sends a 50-word prompt, and the model might generate a 1,000-word response. The cost difference is massive.

A good API gateway implementation allows for tiered rate limiting. Set global limits to prevent your entire system from being overwhelmed, but also set per-tenant or per-user limits.

I usually implement this using Redis. The gateway checks the user's quota in real time. If they have exceeded their daily token limit or their requests-per-minute (RPM) cap, the gateway returns a 429 Too Many Requests immediately. I go deeper on the token-budget angle in rate limiting to protect your AI wallet.

This saves your backend from doing expensive work that you won't get paid for. It also stops "noisy neighbors" — one user scripting an automated tool that hogs all your capacity and makes the app slow for everyone else.

Handling the AI-specific quirks

Gateways for AI need to handle two things differently than traditional web apps: streaming and long-running requests.

Streaming support

Most modern AI apps use Server-Sent Events (SSE) to stream responses word by word. Some older gateways or load balancers try to "buffer" the entire response before sending it to the client. This kills the user experience.

Make sure your gateway (whether you are using Kong, Tyk, or a custom Laravel solution) is configured to disable buffering for AI routes. The data should flow through the gateway like water through a pipe, not like a bucket that needs to be filled.

Extended timeouts

Traditional APIs expect a response in 1–2 seconds. A complex RAG query involving multiple vector searches and a large model generation might take 30 seconds or more.

You need to adjust your gateway's "upstream timeout" settings. Kong defaults to a 60-second upstream timeout, but managed gateways are far stricter — AWS API Gateway integrations default to a 29-second cap, and you can only raise it beyond that on Regional or private REST APIs by requesting a service quota increase (which may cost you some account throttle headroom). Leave those defaults in place and your users will see 504 Gateway Timeout errors even when your models are working perfectly.

Practical steps for your stack

You don't need a massive team to set this up. Here is how I usually approach it depending on the project size:

For startups — use a cloud-native gateway like AWS API Gateway or Azure API Management. They are serverless, scale automatically, and integrate directly with Cognito or Entra ID for auth.
For self-hosters — Kong is the gold standard. It has a great ecosystem of plugins for rate limiting and auth. If you are comfortable with PHP, a thin Laravel app acting as a gateway works surprisingly well for custom logic.
For Shopify devs — if you are building agentic commerce tools, use the gateway to handle the specific Shopify HMAC validation before passing the request to your AI agents.

Wrapping up

The API gateway isn't just a piece of infrastructure. It is a design philosophy. It says that your AI logic is too valuable — and too expensive — to be left unprotected.

By centralizing auth, routing, and rate limiting, you make your system more modular. You can swap models, change pricing tiers, and update security policies without touching the core code that makes your AI "smart."

Are you still letting your frontend talk directly to your LLM providers? If so, what is the one thing stopping you from putting a gateway in front of it?

Stay sharp. — a senior dev

Actionable takeaways

Centralize auth — never let your RAG orchestrator handle raw user authentication. Do it at the gateway.
Inject tenant context — use the gateway to verify the user and inject a tenant_id header to enforce data isolation.
Implement global + per-user limits — protect your wallet from both malicious attacks and accidental bugs.
Configure for streaming — ensure your gateway doesn't buffer responses, or your "typing" effect will break.
Use model aliases — route to /chat/pro instead of a specific model name to keep your stack flexible.

Shopify Storefront Web Components: headless light

Tue, 19 May 2026 00:00:00 GMT

Headless used to mean hiring a team of six engineers just to show a "Buy" button. Shopify Storefront Web Components change that.

If you wanted a custom Shopify experience outside of their Liquid-based themes, you were usually forced into a big architectural decision. You had to build a full React or Hydrogen app, manage server-side rendering, handle complex routing, and pray your SEO didn't tank. For many startups and established brands, this was like buying a semi-truck when all they needed was a bicycle.

The complexity of traditional headless was a gatekeeper. It prevented simple content-driven sites on platforms like Astro or WordPress from easily selling products without a jarring transition to a subdomain. We've spent years over-engineering solutions for problems that could have been solved with a few custom elements.

Shopify Storefront Web Components have changed the math. Now, adding commerce to any site is as simple as dropping in a script tag.

The headless headache

Building a headless store often feels like building a house from scratch. You have to worry about the foundation (hosting), the plumbing (GraphQL queries), and the wiring (state management).

If you are a senior engineer, you know the drill. You spend weeks configuring Shopify Hydrogen or a custom Next.js setup just to get a cart that actually works. And once it's live, you're the one who has to maintain the Node.js environment and the middleware.

It's expensive. It's slow to deploy. And for 80% of use cases, it is total overkill. We need a way to get the flexibility of headless without the technical debt of a heavy framework.

Entering the era of custom elements

Shopify Storefront Web Components are framework-agnostic. They are standard Web Components (custom elements) that handle the heavy lifting of communicating with Shopify's Storefront API.

You don't need React. You don't need a build step. You just need HTML.

This "headless light" approach lets you embed products, collections, and a fully functional cart directly into your existing stack. Whether you are using a static site generator or a legacy CMS, these components act as bridge-builders. They let you keep your content where it is and pull the commerce in dynamically.

How to get started in 5 minutes

Getting these up and running is refreshing for any developer used to complex APIs. Here is the workflow I use when I want to move fast.

1. Connect your store

The first step is adding the script tag and the <shopify-store> component to your HTML. This establishes the connection to your Shopify domain.

<!-- Load the components script — see the official docs:
     https://shopify.dev/docs/api/storefront-web-components -->
<script src="https://cdn.shopify.com/storefront/web-components.js"></script>

<shopify-store store-domain="https://your-store.myshopify.com"></shopify-store>

If you need inventory counts or custom data, add a public-access-token from the Shopify headless channel. For basic title and price display, you don't even need that.

2. Define the context

The magic happens with <shopify-context>. This tells the page which product or collection it should be looking at. You just pass the handle from your Shopify admin.

<shopify-context type="product" handle="awesome-tshirt">
  <template>
    <!-- your content goes here -->
  </template>
</shopify-context>

3. Display the data

Inside that template, you use <shopify-data> to pull specific fields. It uses dot notation, making it feel very familiar to anyone who has worked with Liquid or JavaScript objects.

<shopify-data query="product.title"></shopify-data>
<shopify-money
  query="product.selectedOrFirstAvailableVariant.price"
></shopify-money>

The secret sauce: llms.txt

Here is the part where it gets interesting for modern developers. Shopify publishes a machine-readable llms.txt file.

If you've been following the rise of agentic workflows and vibe coding, you know that providing context to an AI model is everything. By pointing your AI agent (like Claude or ChatGPT) to this text file, it learns exactly how to write code for these specific Web Components.

This eliminates the hallucination problem. Instead of the AI guessing how a Shopify component should look, it uses the official spec. I've found that including this link in my system prompt lets me generate entire product landing pages in seconds that actually work on the first try.

It turns "development" into "orchestration." For more on how to leverage these tools, check out how MCP context-aware agents are changing the way we handle technical docs.

When to use Web Components vs Hydrogen

As a senior engineer, you have to pick the right tool for the job. Here is my rule of thumb.

Use Storefront Web Components if:

You have an existing marketing site and want to add "buy buttons" or a mini-cart.
You are building a landing page and need speed above all else.
Your team doesn't want to maintain a React/Node.js infrastructure.
You want to stay framework-agnostic.

Use Shopify Hydrogen if:

You are building a mission-critical, full-scale custom storefront.
You need complex server-side logic and deep integrations with multiple APIs.
You require the absolute highest level of performance optimization via streaming and edge rendering.

For most people starting out or modernizing a digital presence, Web Components are the winning choice. They offer the best balance of AI-driven development and production stability. If you're still weighing the bigger architectural call, see Shopify Liquid vs. headless.

Takeaways for the modern dev

Web Components are the "headless light" solution we've been waiting for.
They work anywhere — WordPress, Astro, plain HTML, or even a local static file.
Use the llms.txt file to train your AI assistant for perfect code generation.
Avoid over-engineering — if you don't need a massive React app, don't build one.

Building for the web in 2026 is about reducing friction. Shopify has finally removed the friction from headless.

Are you still building full React apps for simple stores, or are you ready to embrace the simplicity of custom elements? Drop a note via contact — I love this conversation. 🤘

How agentic commerce changes building on Shopify

Mon, 18 May 2026 00:00:00 GMT

Your beautiful Shopify theme is about to become invisible.

For a decade, we have obsessed over conversion rate optimization, pixel-perfect layouts, and fast-loading Liquid templates. We built for human eyes. But a new type of shopper is arriving at the digital storefront. They don't have eyes, they don't click buttons, and they certainly don't care about your hero slider.

They are autonomous AI agents.

The shift from human-centric browsing to agentic commerce is the biggest architectural pivot Shopify has ever seen. If you are still just "the theme guy" or "the Liquid expert," your skillset is about to hit a massive wall. I have been building on the web for over ten years, and I can tell you that the era of building for agents is here. It is time to move from designing pixels to designing protocols.

The problem: the end of the traditional funnel

Most developers are still stuck in the old way of thinking. We build a site, drive traffic to a landing page, and hope the user navigates to the checkout. This is a manual, high-friction process.

Today, buyers are increasingly using tools like ChatGPT, Gemini, or Microsoft Copilot to do the "work" of shopping. They ask for a waterproof hiking boot under $150 with specific shipping requirements. The AI doesn't visit your store to browse. It queries data. If your store isn't built to be "read" by an agent, you simply don't exist in that transaction.

The agitation: why your current apps aren't enough

We have spent years building "utility" apps that handle simple automations. But Shopify is moving fast to pull those features into the core. With tools like Shopify Magic and Sidekick, the basic stuff — copywriting, image editing, simple workflows — is being commoditized.

The real value is moving deeper into the stack. Agents need more than just a product description. They need structured data, real-time inventory logic, and a way to execute a checkout without a browser window. If you are relying on "fake" variants or messy metafields, you are breaking the agent's ability to reason about your store.

When an agent fails to understand your product structure, the buyer gets a "no results found" or a hallucinated alternative. That is a lost sale for your client and a failed project for you.

The solution: welcome to agentic commerce

Agentic commerce is a system where AI agents take over the discovery, comparison, and execution phases of shopping. Shopify is already laying the groundwork for this with three major pillars:

Universal Commerce Protocol (UCP) — the open standard Shopify co-developed with Google for how agents discover, negotiate, and transact with any merchant. It is composable: it defines the conversation, then plugs into MCP for tool access and AP2 for payment authorization. (For a hands-on walkthrough, see my Shopify UCP quick-start.)
Catalog API — UCP's discovery layer. It standardizes products into a universal taxonomy, verifies pricing and inventory in real time, and syndicates that structured data to connected AI surfaces.
Agentic Storefronts — the management layer where you configure product data once in the Shopify admin, then distribute and sell across every AI channel (ChatGPT, Microsoft Copilot, Google's AI Mode, the Gemini app).

As developers, our job is shifting. We are no longer just building visual storefronts. We are building "agent-ready" infrastructure.

Why schema is the new CSS

In the agentic era, your structured data is your most important asset. A perfectly optimized JSON-LD schema or a clean set of Shopify Metaobjects is now more valuable than a fancy hover effect.

Agents rely on clarity. They need to know if a product is compatible with another, what the specific material breakdown is, and exactly when it will arrive. If you want to see how I've helped businesses modernize their digital presence through better architecture, check out some of my previous work.

The focus for developers must move toward:

Native variants only — stop using "split products" or custom Liquid hacks to show variants. Agents need standard ProductVariant records to function.
Rich Metaobjects — use these to build knowledge bases that agents can query. Think compatibility tables, brand story, and detailed technical specs.
GraphQL mastery — the Shopify Admin and Storefront APIs are the primary languages of agents. If you aren't comfortable with complex GraphQL queries, you are already behind.

Building custom agents with MCP and Shopify

The most exciting part of this shift is building our own agents. The Model Context Protocol (MCP) lets us connect AI models to external data sources like the Shopify API — and it's the same binding UCP uses to expose commerce tools to agents.

Imagine building an "inventory agent" for a merchant that doesn't just alert them when stock is low. Instead, it queries recent sales trends via the Admin API, checks lead times from a supplier, and suggests a restock amount — all through a chat interface.

This is where tools like Laravel and Docker come in handy. We can build custom middleware that acts as an MCP server, exposing specific Shopify "tools" to an AI agent. This is the type of deep technical work that differentiates a senior engineer from a freelancer who just installs themes.

The Shopify developer's new roadmap

To thrive in the next five years, I recommend focusing on these specific technical areas.

1. Data hygiene as a service Start offering "agent-readiness" audits. Clean up product data, normalize attributes, and ensure all metadata is machine-readable. This is the new SEO.

2. Headless and API-first builds While Liquid isn't dead, headless architectures using Hydrogen and Oxygen are much more aligned with the agentic future. They force you to think in terms of data and APIs rather than just templates. If you're weighing the trade-offs, I broke them down in Shopify Liquid vs. headless.

3. RAG and vector databases Learn how to use RAG (retrieval-augmented generation) and tools like pgvector. This lets you build agents that can search through thousands of product reviews or support docs to give "expert" advice to shoppers. If you're new to this, start with picking the right RAG stack.

4. Understand agent trust tiers and the Agentic plan Agentic Storefronts gate access by agent trust tier — higher tiers unlock broader capabilities, up to completing checkout directly. There is also a dedicated Agentic plan that lets brands on any platform list products in Shopify Catalog and sell through agentic storefronts. Know where direct checkout is enabled and how to configure it.

Final takeaways for the agentic shift

The change is happening faster than most of us realize. Shopify reports that in Q1 2026, AI-driven traffic to its stores grew roughly 8x year over year, orders from AI-powered searches climbed nearly 13x, and new buyers are ordering through AI channels at close to twice the rate of other channels.

If you want to stay relevant, here is your checklist:

Move your product logic into native Shopify structures.
Double down on GraphQL and API integration.
Start experimenting with MCP servers and local LLMs for internal store operations.
Remember that the agent is your new "user." Optimize for its understanding first.

We are moving into a world where commerce is autonomous and frictionless. It is an incredible time to be a developer if you are willing to learn the new protocols. If you want to learn more about my background in high-quality web applications, you can read more about me.

The question is — are you building a store that only humans can see, or are you building a store that the whole world can buy from?

Are you ready to start building your first AI-native Shopify tool, or are you still holding onto your CSS hacks? Drop a note via contact — I love this conversation. 🤘

7 mistakes wrecking your production RAG stack

Sun, 17 May 2026 00:00:00 GMT

Getting a RAG (retrieval-augmented generation) demo working is easy. You take a few PDFs, throw them into a vector database like Chroma or Pinecone, and ask a question. It feels like magic. If you're still choosing your foundation, my guide to picking the right RAG stack covers the trade-offs before you commit.

But shipping RAG to production is where the magic dies.

I've seen too many teams launch a feature only to realize that their users are getting irrelevant answers, waiting 10 seconds for a response, or worse, getting hit with "I don't know" for questions that are clearly in the documentation. When the "vibe check" fails at scale, your users lose trust.

You're likely making at least one of these seven structural mistakes that turn a cool demo into a production nightmare. I've spent the last few years building custom web applications and AI systems, and I've had to fix these same leaks in my own stacks.

Here is how to bridge the gap between "it works on my machine" and a production-grade AI system.

1. Naive chunking is killing your context

Most people start with a simple character-based or token-based splitter. You tell the library to "give me chunks of 500 tokens with a 50-token overlap."

This is a mistake.

This "naive chunking" treats your data like raw soup. It might cut a sentence in half, split a table in the middle of a row, or separate a coding example from the explanation that precedes it. If the retriever pulls only one of those halves, the LLM has zero chance of giving a correct answer.

The fix: use semantic or structural chunking.

I always recommend chunking based on the actual structure of the document first. Use headers (H1, H2, H3), paragraphs, or even markdown delimiters to ensure related ideas stay together. If you're working with complex data, consider recursive character splitting that respects newlines and punctuation before falling back to raw token counts. Bad chunking is one of the most common reasons your RAG fails in production.

2. Skipping the reranker step

Vector search is great at finding "roughly similar" stuff, but it's not a precision instrument. It relies on cosine similarity, which can be easily fooled by documents that share a similar "vibe" but don't actually contain the answer.

If you're just taking the top 5 results from your vector store and shoving them into your LLM prompt, you're leaving quality on the table.

The fix: add a reranking step.

I look at retrieval as a two-stage process. Stage one is the "fast and broad" search where you pull the top 20 or 50 candidates from your vector database. Stage two is using a cross-encoder or a specialized reranking model (like Cohere's Rerank or BGE-Reranker) to score those 50 candidates against the query more accurately.

The reranker acts like a bouncer at a club. It doesn't care if a document looks "okay." It only lets in the ones that are actually relevant to the question.

3. Ignoring embedding drift and versioning

This is the silent killer. I've seen teams upgrade their embedding model from text-embedding-ada-002 to text-embedding-3-small without re-indexing their entire database.

Suddenly, the vectors being generated for new queries don't "line up" with the vectors stored in the index. The similarity scores go haywire. Even worse is when you change the preprocessing logic (like how you format the chunks) but keep the old vectors.

The fix: pin your models and version your index.

Treat your embedding model like a database schema. If you change the model, you must re-index. I always include the model name and version in the metadata of every index I build. This way, if I need to test a new model, I can run them side-by-side without breaking the production flow. My experience in cloud infrastructure has taught me that consistency is better than a "better" model that doesn't match its data.

4. The "lost in the middle" latency problem

Everyone wants more context. We see context windows of 128k or even 1M tokens and think, "great, I'll just give the LLM everything!"

This is a trap for two reasons. First, latency — feeding tens of thousands of tokens of context into an LLM inflates your time-to-first-token and can push response times into double-digit seconds. Second, models still struggle with the "lost in the middle" effect: they reliably use information at the start and end of a long context but tend to ignore facts buried in the center. A bigger context window is not the same as memory, and stuffing it rarely helps.

The fix: optimize your latency budget.

I start with a "latency budget." If the user expects a response in under 2 seconds, I can't afford to send 20 chunks. I limit my retrieval to the top 3–5 high-quality chunks and use streaming as soon as the first token is ready.

If you need more data, consider using a multi-step approach: use a cheaper model to summarize the retrieved chunks before passing the refined info to your main model.

5. Forgetting about hybrid search

Vector search is terrible at finding specific keywords or unique identifiers. If a user asks for "error code XF-904," a vector search might return documents about "general error handling" because the "vibe" is similar. But it might miss the one specific document that actually mentions "XF-904."

The fix: implement hybrid search.

I always combine dense vector search with traditional sparse search (like BM25). By blending these two results using something like Reciprocal Rank Fusion (RRF), you get the best of both worlds. You get the semantic understanding of vectors and the keyword precision of full-text search. This is non-negotiable for enterprise search or technical documentation. If keyword precision matters more than you expect, it's worth weighing vector search against graph search for your retrieval strategy.

6. Failing to filter by metadata

If your RAG system contains documents for different clients, versions, or dates, pure vector search will betray you. You might ask about "API changes in 2024" and get results from 2022 because they share similar keywords.

Relying on the LLM to "ignore" the wrong dates in the context is a waste of tokens and a recipe for hallucinations.

The fix: use hard metadata filters.

Before the vector search even happens, apply filters. If you know the user is looking for "v2" of your documentation, filter the vector query to only include chunks with version: '2'. This drastically reduces the search space and improves accuracy. I use this heavily when building Shopify apps where data must be strictly siloed by shop ID.

7. Vibe-based evaluation

How do you know your RAG stack is getting better? Most devs just ask a few questions, see that the answer looks okay, and ship it.

This is called "vibe-checking," and it doesn't work. When you change a prompt or a chunk size, you might improve one answer while breaking ten others you didn't check.

The fix: build a golden evaluation set.

I use the Ragas framework or simple LLM-as-a-judge patterns to run automated evals. I maintain a "golden set" of 50–100 questions with ground-truth answers. Every time I change the architecture, I run the eval and look for three metrics:

Faithfulness — is the answer actually derived from the context?
Answer relevance — does it answer the user's question?
Context precision — are the retrieved chunks actually useful?

Practical takeaways for your stack

Start with metadata — don't let the vector database guess. If you have categories or dates, use them as hard filters.
Rerank by default — it's the single biggest quality jump you can make for the lowest effort.
Monitor retrieval, not just generation — if your retriever fails, the best LLM in the world can't save you. Log your top-k retrieval results separately.
Don't over-engineer — sometimes a simple long-context prompt is better than a complex agentic workflow. Measure before you add complexity.

Building production RAG is a game of millimeters. It's about cleaning your data, pinning your models, and actually measuring what's happening under the hood.

I've spent years moving from "it works" to "it's reliable." If you're struggling with a specific part of your AI pipeline, what's the one thing that's currently keeping you from hitting that "deploy" button?

Drop a comment or reach out if you're hitting a wall with your architecture. 🤘

Scaling with RabbitMQ: why message brokers matter

Sat, 16 May 2026 00:00:00 GMT

The monolith is screaming. Every time a user hits the "checkout" button, your server has to generate a PDF, send a welcome email, update the inventory, and ping three different third-party APIs. Your request/response cycle is hanging by a thread. If any of those external services take more than two seconds to respond, your user sees a 504 gateway timeout.

It starts with a small delay. Then it becomes a bottleneck. Before you know it, you are throwing more RAM at a problem that cannot be solved by bigger hardware. This is the "monolith wall." When everything is synchronous, a single failure in a secondary task brings down the entire user experience.

I have been in these trenches. I have watched dashboards turn red during a marketing spike because the database was too busy processing background reports to handle new signups. The solution isn't just "faster code." It is a change in how your services talk to each other. It is about decoupling. It is about RabbitMQ.

Why your request path is too crowded

In a standard web application, we often fall into the trap of doing too much inside the controller. A user makes a request, and we feel the need to finish every related task before sending back a "200 OK." This is fine for a side project with ten users. For a scaling SaaS, it is a recipe for disaster.

Think of it like a coffee shop. If the person taking your order also has to grind the beans, froth the milk, and hand-draw the logo on the cup before taking the next order, the line will wrap around the block. The shop fails because the cashier is "tightly coupled" to the barista's work.

To scale, you need a system where the cashier takes the order, writes it on a slip, and hands it off. They are immediately free for the next customer. The work happens "in the background." That slip of paper is your message. The counter where they put the slips is your message broker.

The RabbitMQ magic: more than just a queue

RabbitMQ is an open-source message broker that acts as the "middleware" for your architecture. It doesn't just store messages — it routes them with surgical precision.

At its core, RabbitMQ uses a few key concepts:

Producers — your web applications or APIs that create a task.
Exchanges — the "post office" that decides which queue a message should go to based on rules.
Queues — the temporary storage where messages sit until they are processed.
Consumers — the background workers (often running in Docker containers) that actually do the heavy lifting.

By putting RabbitMQ in the middle, your web tier only needs to do one thing: tell RabbitMQ that a task needs to be done. This takes milliseconds. The user gets an instant confirmation, while the heavy work happens whenever your workers are ready.

Smoothing out the spikes

One of the biggest pains in scaling is handling "noisy neighbors" or sudden traffic bursts. If a large enterprise client uploads a 100,000-row CSV for processing, you don't want that to slow down the login page for everyone else. This is exactly the kind of workload message queues for heavy document processing are built to absorb.

With RabbitMQ, those 100,000 rows become 100,000 individual messages in a queue. Your workers will chew through them at a steady pace. If the queue gets too long, you don't need to scale your entire application — you just spin up more worker instances.

This is horizontal scaling in its purest form. Since the workers are decoupled from the web server, you can scale them independently based on the specific load. In Laravel, you manage these background jobs through its queue system — and while Laravel ships drivers for Redis, SQS, and the database, talking directly to RabbitMQ uses a community package like vladimir-yuldashev/laravel-queue-rabbitmq.

How to move from sync to async

You don't have to rewrite your entire codebase overnight. I usually recommend the "strangler pattern." Pick one slow, non-critical process. Maybe it is the "forgot password" email or an image resize task.

Here is a simplified look at how you might dispatch a job in a modern PHP environment:

// instead of sending the email directly
// $emailService->sendWelcome($user);

// we dispatch a job to RabbitMQ
ProcessWelcomeEmail::dispatch($user)->onQueue('high-priority');

// the user gets a response instantly
return response()->json([
    'message' => 'welcome! check your inbox soon.',
]);

Now, even if your email provider (like SendGrid or Mailgun) is having a bad day, your application stays up. The message stays safely in the RabbitMQ queue until the service is back online.

Building for the future

Moving to a message-broker-first mindset is the first step in the journey from a monolith to microservices. Once your monolith starts publishing "events" (like order.placed or user.registered), other services can start listening to those events without you ever changing the original code.

It creates a system that is resilient, observable, and significantly easier to debug. You can look at the RabbitMQ management UI and see exactly how many tasks are pending and how fast they are being processed. No more guessing why the server is slow.

Already running on GCP? The same patterns apply with Google Pub/Sub — pick the broker that matches your hosting stack, not the trend cycle.

Key takeaways for your next build

Don't block the user. If a task takes more than 100ms, it probably belongs in a queue.
Decouple early. Use RabbitMQ to separate your "thinking" (web tier) from your "doing" (workers).
Idempotency is key. Since messages can sometimes be delivered twice, make sure your workers can handle the same task more than once without causing errors.
Monitor your queues. A massive queue is a leading indicator that you need more workers or that a service is failing.

Scaling a SaaS isn't about working harder. It is about working smarter by giving your data room to breathe. RabbitMQ is that breathing room.

What is the slowest part of your application right now? Could it be a background job instead? Tell me — I bet we can move it off the request path.

Event-driven architecture with Google Pub/Sub

Sat, 02 May 2026 00:00:00 GMT

Building a modern web application usually starts simple. You have a request and you send a response. But as your business grows, that simple flow starts to feel heavy. Maybe you need to send a welcome email, update a CRM, and trigger a data warehouse sync all at once. If you do this synchronously, your users are stuck staring at a loading spinner. If one service fails, the whole request dies. Your system becomes a house of cards. An event-driven architecture breaks that chain, and Google Pub/Sub is one of the cleanest ways to build it.

This is the problem of tight coupling. Your application logic is tangled like old headphones in a pocket. Every new feature adds more risk and more latency. You want to scale, but your monolithic approach is holding you back. You need a way to let your services talk without being glued together.

The solution is event-driven architecture (EDA). And in the Google Cloud world, the heart of that architecture is Google Pub/Sub. It is a globally distributed messaging service that decouples the services that produce events from the services that consume them. It allows you to build systems that are truly scalable, resilient, and ready for the future of AI and big data. If you'd rather self-host the broker, the same patterns translate directly to scaling with RabbitMQ.

Understanding topics and subscriptions

At its core, Google Pub/Sub is built on two main concepts: topics and subscriptions. I like to think of a topic as a radio station. It broadcasts information out into the void. It doesn't care who is listening or what they do with the music. It just plays the hits.

On the other side, you have subscriptions. These are the listeners. A subscription represents a stream of messages from a specific topic. The beauty of this system is the decoupling. The service sending the message (the publisher) only needs to know about the topic. It doesn't need to know if there are ten consumers or zero.

This is the heart of the shift from synchronous to asynchronous communication. When a user signs up on your site, you publish a UserSignedUp event to a topic. Your main app is done. It returns a success message to the user immediately. Meanwhile, various subscribers pick up that event and do their jobs in the background.

The power of fan-out

One of the most effective patterns in Google Pub/Sub is the fan-out. This is where you publish a single message to a topic, but multiple subscriptions receive a copy of that message.

Imagine you are running an e-commerce store. When an order is placed, you might have three different services that need to act:

An inventory service to update stock levels.
A shipping service to generate a label.
An analytics service to track revenue.

Instead of your checkout service calling three different APIs, it sends one message to an order-events topic. Three separate subscriptions (one for inventory, one for shipping, one for analytics) each get their own copy of that order message. They process it at their own pace. If the analytics service is down for maintenance, it doesn't stop the shipping label from being created. The messages just wait in the queue until the service is back online.

Pull vs push delivery

When you set up a subscription, you have to decide how you want to receive messages. Google Pub/Sub gives you two main options: pull and push.

Push subscriptions are great for serverless architectures. Google Cloud will literally "push" the message to a webhook URL you provide. This is perfect for cloud infrastructure built on Cloud Run or Cloud Functions. It scales automatically and you only pay for what you use. However, you have to make sure your endpoint can handle the sudden spikes in traffic.

Pull subscriptions work differently. Your consumer service asks Google Pub/Sub for messages when it is ready. This gives you much more control over backpressure. If your worker is busy, it doesn't ask for more work. This is the preferred method for long-running services or when you are using tools like Laravel's queue workers. Pull delivery is generally more robust for heavy processing tasks where you want to fine-tune concurrency — exactly the model I use for message queues in document processing.

Building resilient systems with DLQs

In a distributed system, things will fail. A database might time out or an external API might be down. If a message can't be processed, you don't want to lose it. This is where Dead Letter Queues (DLQs) come in.

A DLQ is just another topic where Google Pub/Sub sends messages that have failed to be acknowledged after a certain number of attempts. Instead of retrying forever and clogging up your main pipeline, the "poison" message is moved aside.

I always recommend setting up a DLQ for every critical subscription. It acts as a safety net. You can then build a separate dashboard or a small script to inspect these failed messages, fix the underlying issue, and replay them. It is a professional approach to error handling that prevents data loss and keeps your system moving.

Integrating Google Pub/Sub with Laravel

For those of us in the PHP and Laravel ecosystem, integrating Google Pub/Sub is smooth. Laravel ships with solid queue support for Redis and SQS, but the google/cloud-pubsub client lets you tap into GCP's global scale. This kind of decoupling is exactly what makes the move from a monolith to microservices tractable instead of terrifying.

You can treat Google Pub/Sub as a custom queue driver. Here is a quick look at how you might publish a message in a typical service class:

use Google\Cloud\PubSub\PubSubClient;

$pubsub = new PubSubClient([
    'projectId' => 'your-gcp-project-id',
]);

$topic = $pubsub->topic('user-events');

$topic->publish([
    'data' => json_encode([
        'user_id' => 123,
        'action' => 'signup',
    ]),
    'attributes' => [
        'event_type' => 'UserSignedUp',
        'priority' => 'high',
    ],
]);

By using attributes, you can even filter messages at the subscription level. This means a subscriber can choose to only listen for messages where event_type is UserSignedUp. This saves compute power and money because your worker never even sees the messages it doesn't care about.

Monitoring and cost management

Monitoring is not an afterthought. It is a requirement. Google Cloud provides deep integration with Cloud Monitoring for Google Pub/Sub. You should keep a close eye on your "unacked message count." If this number is climbing, it means your subscribers can't keep up with the producers.

Cost is another factor to watch. Google Pub/Sub is cheap for low volumes, but as you scale to millions of messages, those bytes add up. Use batching on the publisher side to reduce the number of API calls. Also be mindful of message retention: the default is seven days, and you can configure anywhere from 10 minutes up to 31 days. If you don't need a long replay window, shorten the retention period to cut storage costs.

Wrap up and takeaways

Moving to an event-driven architecture with Google Pub/Sub is a major step toward building senior-level systems. It gives you the flexibility to grow your application without it becoming a tangled mess. It is the backbone of many high-performance systems I build for clients today.

Here are the key takeaways for your next project:

Start by identifying "facts" in your system (e.g., OrderPlaced) and turn them into events.
Use the fan-out pattern to keep your services decoupled and focused on one task.
Always implement a Dead Letter Queue to handle failures gracefully.
Use message attributes for efficient filtering at the subscription level.
Design your consumers to be idempotent. If they receive the same message twice, it doesn't cause errors or double-charges.

Building these kinds of systems takes a bit more planning upfront, but the payoff in stability and scalability is worth every second.

Are you still using synchronous API calls for everything, or have you started moving toward an event-driven flow? Let me know what's stopping you from making the switch.

Self-hosted SaaS with Coolify and Docker

Sun, 19 Apr 2026 00:00:00 GMT

Shipping a SaaS is hard enough without the constant anxiety of a "surprise" bill from your hosting provider. I have seen developers start a project on a managed platform only to find that as soon as they add a second team member or cross a certain bandwidth threshold, their costs skyrocket. You are trapped between paying a "convenience tax" that eats your margins or spending your entire weekend fighting with Nginx configurations and manual SSH commands. It feels like you are either overpaying for simplicity or overworking for control.

The agitation grows when you realize that most managed platforms are essentially wrappers around the same open source tools you could run yourself. You are paying for a pretty dashboard and an easy git-push flow. But when you try to leave, you find yourself deep in vendor lock-in. Your databases, your environment variables, and your build pipelines are all tied to a proprietary ecosystem. If the platform goes down or changes its pricing, your business is at the mercy of their support team.

There is a better way. Coolify combined with Docker gives you the same developer experience as high-end managed platforms, but on your own infrastructure. You get the one-click deploy feel and a clean dashboard while keeping full control over your servers. If you want the business case first, I make it in why I ditch expensive cloud providers for self-hosted SaaS; this guide is the hands-on build.

Why the cloud is getting more expensive

In the early days of a startup, a $20-per-month plan feels reasonable. But as you grow, those costs don't just add up — they multiply. Many platforms now charge per seat. If you have a team of five engineers, you might be paying a hundred dollars a month before you even deploy a single line of code. Then come the usage fees. Bandwidth, image optimization, and serverless function execution costs are often opaque and difficult to predict.

I have worked with clients who moved their entire stack from managed services to a self-hosted Coolify setup and saw their monthly infrastructure bill drop by eighty percent. We are talking about moving from $500 a month down to $50 a month while maintaining the same performance and reliability. When you own the server, you own the resources. There are no "hidden" charges for extra build minutes or database connections.

What exactly is Coolify?

Think of Coolify as an open source, self-hosted version of Heroku or Vercel. It is a control plane that sits on your server and manages everything for you. It handles your deployments, your reverse proxies, your SSL certificates, and your databases. It turns a raw Linux VPS into a powerful hosting platform.

One of the best parts about Coolify is that it is built on Docker. Every application you deploy is containerized. This means your environment is consistent across development, staging, and production. No more "it works on my machine" excuses. If it runs in a container on your laptop, it will run exactly the same way on your Coolify server.

The power of Docker containerization

Docker is the silent engine that makes this entire workflow possible. Instead of installing PHP, Node.js, or Python directly on your server, you package them into a container image. This approach has several key benefits for SaaS founders:

Isolation. Each app runs in its own sandbox. A memory leak in one app won't crash your entire server.
Portability. You can move your containers from Hetzner to DigitalOcean to AWS in minutes.
Version control. Your infrastructure is defined as code. You can version your Dockerfile just like your application code.
Scalability. Adding more instances of your app is as simple as spinning up another container.

I prioritize Docker on every build I ship. It makes the handoff to the client seamless: they don't need to worry about the underlying server configuration, just a Docker-compatible environment. Coolify deliberately stays at the single-host Docker layer rather than orchestrating clusters — if you're weighing that trade-off, see Docker vs Kubernetes: containers vs orchestration.

Setting up your control plane

Getting started is surprisingly simple. Coolify's documented minimum is 2 CPU cores, 2 GB of RAM, and 30 GB of storage — though I'd budget 4 GB if you plan to run more than a couple of apps alongside it. I typically recommend Ubuntu for the operating system. Once you have your server, you run the single installation command from the Coolify documentation.

# the only command you need to bootstrap Coolify
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

This script takes care of installing Docker, setting up the Traefik reverse proxy, and launching the Coolify dashboard. Within minutes, you can log in to your own private hosting panel. From there, you can connect your GitHub or GitLab account. Coolify will listen for webhooks and automatically trigger a new build whenever you push code to your main branch.

It feels magical. You get the same feedback loop as the big-name platforms. You see the build logs in real time. You get a preview URL for your feature branches. And you do it all on a $5 VPS.

Handling databases and state

One of the biggest pain points of self-hosting is managing databases. Nobody wants to manually configure Postgres clusters or worry about backing up Redis instances. Coolify solves this by offering "one-click" services.

You can spin up a Postgres, MySQL, MongoDB, or Redis instance in seconds. Coolify automatically generates secure credentials and provides you with the connection strings. It also handles persistent volumes, so even if your container restarts or you update the image, your data stays safe. Persistent volumes are not a backup strategy, though — schedule automated dumps and keep them off-box, because replication and backup solve different failure modes.

For a SaaS, I usually recommend a dedicated server for your databases once traffic climbs. Coolify makes this easy because it supports multi-server setups. You can have one server acting as your control plane and several other servers acting as worker nodes where your apps and databases actually live. (I cover that scaling pattern in more depth in scaling SaaS with advanced Coolify deployment strategies.)

Security and SSL by default

Security shouldn't be an afterthought. In the old days, setting up SSL with Let's Encrypt required cron jobs and manual certificates. With Coolify and Traefik, it is entirely automated.

When you point a domain to your server and add it to your app configuration, Coolify automatically requests and installs an SSL certificate. It also handles the renewal process. Your SaaS is always served over HTTPS without you ever touching a terminal.

Beyond encryption, Coolify helps you manage your environment variables securely. You don't need to hardcode secrets in your git repository. You can define them in the dashboard, and they are injected into your containers at runtime. This is a standard best practice that many developers skip when they are in a rush.

The senior engineer's workflow

If you want to do this the "pro" way, here is how I structure my deployments.

Use a Dockerfile

While Coolify can automatically detect many frameworks like Laravel or Node.js, I always recommend writing your own Dockerfile. It gives you total control over the build process. You can optimize your image size by using multi-stage builds. This makes your deployments faster and saves disk space.

Leverage Nixpacks

If you don't want to write a Dockerfile, Coolify supports Nixpacks. It is a tool built by Railway that inspects your code and builds an optimized container image automatically, with detection for 20-plus languages. Railway itself has since moved to a successor called Railpack, but Nixpacks remains a solid zero-config option inside Coolify.

Set up health checks

Never deploy without a health check. You want to make sure your app is actually responding before the reverse proxy starts sending traffic to it. Coolify allows you to define a health check endpoint. If the check fails, the old container stays running, and the new one isn't promoted. This is the foundation of zero-downtime deployments.

Is self-hosting right for you?

Self-hosting isn't for everyone. If you are a solo developer with zero interest in learning how a server works, then paying the "convenience tax" might be worth it. Your time is valuable, and if a managed platform saves you five hours of frustration a month, it might pay for itself.

However, if you are building a real business, you need to understand your stack. Owning your infrastructure is about more than just saving money. It is about autonomy. It is about knowing that no matter what happens to a specific provider, you can move your business elsewhere in a heartbeat.

At Ansezz, I focus on building robust, scalable systems that empower clients. Whether the work is a complex e-commerce engine on Shopify or a custom Laravel application, the goal is always the same: high performance and long-term stability.

Final takeaways for your deployment strategy

Hosting shouldn't be a source of stress. By moving to a Docker-based workflow with Coolify, you reclaim your time and your budget. You get the professional features of a top-tier PaaS without the enterprise price tag.

Here is your checklist for a successful transition:

Start with a clean VPS and install Coolify using the official script.
Containerize your application using a Dockerfile for maximum control.
Use one-click services for your databases and enable automatic backups.
Set up your domain and let Coolify handle the SSL certificates.
Implement health checks to ensure zero-downtime updates.

When you stop worrying about the "how" of deployment, you can spend more time on the "what" of your product. That is where the real value is created.

What is the one thing stopping you from moving your SaaS to a self-hosted setup today? Tell me about it — happy to share war stories.

MCP tool-use: building context-aware agents

Sun, 05 Apr 2026 00:00:00 GMT

Building context-aware agents is harder than it should be, because the current state of AI tooling is a mess of fragmented integrations. Every time I want to give an LLM access to a new data source or a specific tool I find myself writing custom glue code that breaks the moment an API version changes. It is a frustrating cycle of brittle wrappers. We are effectively forcing highly intelligent models to peer through a keyhole when they should have a wide-open window into our data ecosystems.

This fragmentation creates massive technical debt. You spend most of your time on plumbing and only a sliver on the actual intelligence of the agent. Without a unified way to share context the model often hallucinates because it lacks the grounding of real-time data. It is stuck in a loop of "I don't have access to that" or worse "I'll guess what that data looks like" — which leads to unreliable outputs and a poor user experience.

The Model Context Protocol (MCP) changes this dynamic entirely. It is an open standard, created by Anthropic and donated in late 2025 to the Agentic AI Foundation under the Linux Foundation, that lets me build context-aware agents that connect to any data source using a universal language. By standardizing how servers and clients communicate I can focus on building sophisticated logic rather than managing endless API endpoints. If you want the bigger picture on how this fits the wider toolbox, I broke down API vs MCP separately — MCP is the missing link in the agentic workflow.

Why MCP matters for developers

I have spent years building custom web applications and one of the biggest hurdles has always been data silos. When I work on complex technical challenges the goal is usually to make data actionable. Traditional tool-use requires the developer to define every schema and every function call manually for the model. MCP flips this script.

MCP acts as a bridge. It defines a clear boundary between the AI application (the client) and the data sources (the servers). This separation of concerns means I can swap out the underlying model without rebuilding the entire data integration layer. If I move from Claude to another model that supports MCP, the tools and resources remain the same.

It also eases the context window problem. Instead of stuffing a massive document into the prompt I can expose it as an MCP resource. The model only pulls what it needs when it needs it. This is significantly more efficient and cost-effective. It lets me build agents that are aware of their environment without being overwhelmed by it.

The three pillars: tools, resources, and prompts

To understand how to build with MCP I look at its three core primitives. These are the building blocks for any context-aware system.

Tools are model-controlled actions. When I give an agent a tool I am giving it the ability to change the world. This could be writing a file to a disk or making a POST request to a Shopify API. The model decides when to call the tool based on the user's intent.
Resources are application-controlled data. Think of these as read-only files or database entries that the agent can inspect. Resources provide the necessary grounding. If I am building a support agent the documentation for the product would be a resource. The agent can search and read it to provide accurate answers.
Prompts are user-controlled templates. They help guide the interaction. By using MCP prompts I can standardize how users interact with the agent across different platforms. It ensures consistency in how the model interprets tasks.

Building your first MCP server

I prefer using TypeScript for building MCP servers because of the mature official SDK. However the protocol itself is language-agnostic, with first-party SDKs for Python, Java, Go, and more. Here is a simplified look at how I structure a basic server that exposes a weather tool. This uses the low-level Server API to make the request handlers explicit; the higher-level McpServer class wraps the same boilerplate if you want less ceremony.

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";

const server = new Server(
  {
    name: "weather-server",
    version: "1.0.0",
  },
  {
    capabilities: {
      tools: {},
    },
  },
);

server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: "get_weather",
        description: "get the current weather for a location",
        inputSchema: {
          type: "object",
          properties: {
            location: { type: "string" },
          },
          required: ["location"],
        },
      },
    ],
  };
});

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === "get_weather") {
    const location = request.params.arguments?.location;
    // logic to fetch weather from an api goes here
    return {
      content: [{ type: "text", text: `it is sunny in ${location}` }],
    };
  }
  throw new Error("tool not found");
});

const transport = new StdioServerTransport();
await server.connect(transport);

This snippet illustrates the simplicity of the protocol. I define the tool and how to handle the call. The MCP client handles the rest. This modular approach is exactly what I look for when managing cloud infrastructure or complex backend systems. It is clean and scalable.

Security and the MCP ecosystem

Security is a major concern when giving an AI agent access to your data. I have seen many implementations where API keys are hardcoded or permissions are too broad. MCP addresses this by using a client-server architecture where the server controls exactly what is exposed.

The server acts as a gatekeeper. I can implement fine-grained access control at the server level. For example an MCP server connecting to a database can be restricted to only specific tables or read-only queries. This level of control is essential for enterprise-grade applications.

The ecosystem has matured fast. MCP has gone from an Anthropic experiment to a genuine industry standard, with OpenAI, Google, and Microsoft all backing it. On the tooling side, clients like Zed, Cursor, VS Code, and Claude Code ship MCP support so AI assistants write better code with real context. If you want a hands-on walkthrough, I wrote up connecting my own dev tools through Claude MCP separately.

Practical steps for getting started

If you are a developer looking to dive into MCP I recommend following these steps.

Explore the existing MCP servers on GitHub. The reference repo ships servers for filesystem access, Git, web fetching, and persistent memory. See how they are structured.
Pick a simple data source you use every day. It could be your Obsidian notes or a local directory of markdown files. Build a basic server to expose these as resources.
Use a client like Claude Desktop to test your server. See how the model interacts with your data. Adjust the tool descriptions to make them more intuitive for the AI.
Compose multiple MCP servers once you are comfortable. Imagine an agent that can read your calendar and then write a draft email based on your upcoming meetings.
Add the coordination layer when one agent is no longer enough. MCP connects an agent to its tools; A2A connects it to other agents. The agent protocol stack breaks down where each one belongs.

MCP is more than just a new protocol. It is a shift in how we build AI applications, moving us away from "black box" agents and toward transparent, context-aware assistants you can actually reason about in production.

How are you planning to use MCP in your next project? Drop me a line — happy to swap notes on real-world MCP server design.

Vibe coding: the shift to agentic workflows

Sun, 22 Mar 2026 00:00:00 GMT

I've spent the last decade building Laravel applications, managing Docker clusters, and fine-tuning Shopify stores. For most of that time, "coding" meant one thing: translating a business requirement into a specific syntax that a machine could execute. It was a manual, linear process of writing line by line, debugging stack traces, and managing state.

But recently, the ground has shifted. We're moving away from the era of "writing code" and into the era of "orchestrating intent."

This transition — often playfully called vibe coding — is more than just a meme. It represents a fundamental architectural shift in how we build software: moving from sequential instruction to agentic workflows powered by protocols like MCP (Model Context Protocol). If you are new to the idea, my intro to vibe coding covers the philosophy and developer-experience side before this post dives into the architecture.

The friction of the manual syntax

The traditional development lifecycle is riddled with invisible friction. You have an idea (the "vibe"), you break it down into tasks, and then you spend 80% of your time fighting with syntax, configuration, and boilerplate.

In a standard Laravel environment, even a simple feature — say, an automated reporting tool — requires you to set up routes, controllers, service classes, and database migrations. You are the compiler. You are the architect. You are the labor.

The problem is that our cognitive load gets consumed by the "how" rather than the "what." We get stuck in the weeds of PHP version compatibility or Docker networking issues, losing sight of the actual user value. This manual micromanagement doesn't scale with the demands of modern business.

The agitation of the "black box" assistant

When AI first entered the scene with basic autocomplete, it felt like a shortcut. But it wasn't a solution. We ended up with what I call "the Copilot paradox": the AI suggests code, but you still have to copy-paste it, test it, find the error, and feed it back to the AI.

It's a broken feedback loop. The AI is a "black box" that doesn't actually know your system. It doesn't know your database schema, your MCP servers, or your deployment status on Coolify. You are still the manual bridge between the AI's logic and your local environment.

This creates a new kind of fatigue. Instead of writing code, you're now a high-speed code reviewer, constantly context-switching between your editor and a chat interface. This isn't "vibe coding" — it's just accelerated manual labor.

The solution: agentic workflows and MCP

True vibe coding isn't about being lazy; it's about shifting your role to that of a high-level system architect. This becomes possible through agentic workflows — systems that don't just complete text but execute tasks in loops. That jump from a static model to an autonomous actor is exactly the LLM vs AI agent distinction.

The breakthrough here is the Model Context Protocol (MCP) by Anthropic. MCP acts as the "USB-C port" for AI applications. Instead of you manually giving the AI context, the AI uses an MCP client to talk directly to your tools — your PostgreSQL database, your Slack channels, or your GitHub repositories.

The shift from chains to loops

In a traditional chain, you give a prompt and get a result. In an agentic loop, the architecture looks like this:

Intent. You describe the outcome ("build a Laravel dashboard for my Shopify sales").
Reasoning. The AI (like Claude) determines it needs to see the schema.
Action. It uses an MCP tool to query the database.
Observation. It sees a missing table and decides to create a migration.
Correction. If the migration fails, it reads the error and fixes it itself.

I call this "intent-based engineering." You aren't writing the migration — you are approving the architectural decision. Nobody lands here on day one, though: the jump from chat prompts to loops is a progression I broke into levels of an AI coding workflow, and MCP sits near the top of it.

Implementing the agentic stack

As an engineer who values quality, I don't just let the "vibe" take over without guardrails. The loop only stays safe if something verifies what comes out of it — that is the whole argument in trust is not a QA strategy. Here is how I'm currently structuring my agentic stack using Laravel and AI.

1. Defined MCP servers

I build small, dedicated MCP servers that expose only the necessary tools to the AI. This keeps the context window clean and the security tight. I go deeper on this in Claude MCP dev tools and on designing context-aware agents with MCP.

// Conceptual MCP tool definition in a PHP environment
public function defineTools(): array
{
    return [
        'get_database_schema' => [
            'description' => 'Retrieves the structure of the Laravel application tables.',
            'parameters' => [],
        ],
        'run_artisan_command' => [
            'description' => 'Executes an artisan command safely.',
            'parameters' => ['command' => 'string'],
        ],
    ];
}

2. Stateful loops

Instead of one-off chats, I use tools like Cursor, Claude Code, or Windsurf that maintain a stateful connection to my local file system. This allows the agent to "see" the impact of its changes in real-time, just like a human developer would.

3. The human-in-the-loop (HITL)

The most important part of the architecture is the review gate. Even with agentic loops, the human architect must sign off on the "plan" before the "action" phase. This ensures the PHP logic follows clean architecture principles rather than just "making it work." What that gate should actually check is a separate question — I argue for dropping line-by-line reading in favor of specs and automated verification.

The takeaway for the modern founder

If you're a founder or a CTO, the takeaway is simple: stop hiring for syntax and start hiring for system design. The technical barrier is collapsing, but the architectural stakes are higher than ever.

Embrace the vibe. Focus on the intent and the user experience.
Invest in infrastructure. Build the MCP connections and the data pipelines that allow AI to be effective.
Think in loops. Design your internal processes so that AI can iterate autonomously, reducing your bottleneck role.

At Ansezz, I'm not just building apps anymore — I'm building agent-ready ecosystems. Whether it's a complex Shopify integration or a custom SaaS, I ensure the architecture is ready for the agentic future.

The code might be generated, but the vision is entirely yours.

Are you ready to stop writing code and start orchestrating your intent? Get in touch — let's design your agent stack together.

Why your RAG implementation is failing in production

Sun, 08 Mar 2026 00:00:00 GMT

You built a RAG (Retrieval-Augmented Generation) demo. On a local machine, with a handful of PDF files, it looked convincing. The answers felt coherent. The system appeared capable.

Then you pushed it to production.

That is usually where the illusion breaks.

Users start reporting that the LLM is "hallucinating" when the real issue is retrieval. Obvious answers go missing even though they exist in the documentation. Irrelevant chunks surface because they are semantically adjacent, not actually useful.

If your RAG system feels unreliable in production, you are not dealing with a model problem first. You are dealing with a retrieval design problem. Most production RAG systems fail because they rely too heavily on vector search and confuse a strong demo with a robust system. (For the broader catalogue of ways this goes wrong, see 7 mistakes you're making with your production RAG stack.)

I've spent a lot of time building custom AI solutions at Ansezz, and one pattern keeps showing up: a demo proves possibility, but production demands precision.

The "vector noise" trap

The philosophical shift from demo RAG to production RAG is simple: in a demo, semantic resemblance often feels good enough. In production, "good enough" is where failures begin.

Embeddings are useful. They let us map text into vectors and retrieve by meaning rather than exact wording. That is powerful. But semantic similarity is not the same thing as retrieval accuracy.

The problem. Vector search is strong at finding related concepts, but weak at handling specificity.

If a user searches for "Project-X-99 deployment logs," a vector search might return documents about "Project-A deployment" or "logging best practices" because they are semantically close. It can miss the exact identifier "X-99" because that string carries little semantic weight in a high-dimensional space.

The agitation. Once retrieval drifts, the LLM inherits the drift. The model cannot reason its way out of missing or irrelevant context. You end up paying for tokens that produce confident but unhelpful answers, and users lose trust for a reason that often sits one layer below the model itself.

The solution: hybrid search (vector + BM25)

The fix starts with one realization: meaning alone is not enough. You need semantic retrieval and lexical precision working together. This is hybrid search.

What is BM25?

BM25 (Best Matching 25, from the Okapi probabilistic retrieval framework) is the standard lexical ranking method behind classic search systems. It does not try to infer meaning. It rewards exact terms based on how important they are within a document and across the collection, while accounting for document length and diminishing returns from repeated terms.

Why you need both

Vector search handles synonyms, multi-lingual queries, and conceptual matching.
BM25 search handles exact matches, IDs, SKUs, product codes, and technical jargon.

Production systems need both because user questions are rarely pure meaning or pure keyword. They are usually a mix of the two. If you are still deciding how to structure retrieval in the first place, vector search vs graph search is a useful companion read.

Technical insight: reciprocal rank fusion (RRF)

When you run two different retrieval strategies, you also create a new design problem: how should they be combined?

A practical answer is Reciprocal Rank Fusion (RRF). It is simple, reliable, and does not require you to pretend that scores from different retrieval systems are directly comparable.

The logic breakdown:

Assign a score. For every document returned by either search method, calculate a new rank-based score.
The formula. score = 1 / (k + rank), where rank is the item's 1-based position in each result list (so the code below adds 1 to a 0-based index). The k constant (often 60) prevents top-ranked items from dominating too aggressively.
Sum it up. If a document appears in both the vector and BM25 result sets, its scores are added together.
Sort. The documents with the highest combined scores are passed to the LLM.

Here's the minimal PHP version I drop into a Laravel service:

function reciprocalRankFusion(array $resultSets, int $k = 60): array
{
    $scores = [];

    foreach ($resultSets as $results) {
        foreach ($results as $rank => $docId) {
            $scores[$docId] = ($scores[$docId] ?? 0.0) + 1 / ($rank + 1 + $k);
        }
    }

    arsort($scores);

    return $scores;
}

This gives you a cleaner retrieval layer. If a document is semantically relevant and lexically precise, it moves toward the top for a reason.

The "second pass": using re-rankers

Hybrid search is a strong retrieval foundation, but production RAG usually needs one more layer of judgment.

If you want more precise results, add a re-ranker.

A re-ranker such as Cohere Rerank or BGE-Reranker is a cross-encoder model that evaluates the query and the document together. That matters because relevance is relational. It is not just about what a document contains. It is about whether that document answers this question.

Step 1. Retrieve the top 50 results using hybrid search.
Step 2. Pass those 50 results through a re-ranker.
Step 3. Send only the top 5 re-ranked results to your LLM.

This reduces context stuffing and improves the quality of what reaches the model. In practice, it is one of the clearest differences between a RAG demo and a production RAG system that behaves consistently. The extra hop does add latency, which is where a Redis and semantic caching layer earns its keep.

Your production RAG checklist

The problem

A RAG system can feel impressive in a demo and still be structurally weak in production.

The agitation

Once real users, messy documents, and ambiguous queries enter the picture, weak retrieval turns the LLM into expensive guesswork. That is when confidence and correctness start drifting apart.

The solution

To move from demo RAG to production RAG, I focus on a few non-negotiables:

Stop relying on vector-only search. Add a BM25 layer.
Implement RRF. Fuse lexical and semantic retrieval without overcomplicating score calibration.
Tune chunking deliberately. If chunks are too small, they lose context. If they are too large, they add noise. I usually find 512–1024 tokens with a 10–15% overlap works well for technical documentation.
Add a re-ranker. Refine the final candidate set before anything reaches the LLM.
Evaluate with RAGAS. Measure faithfulness and relevance instead of trusting intuition.

Building AI is easy. Building reliable AI is hard. It requires a deeper understanding of retrieval, ranking, and context design, not just the ability to connect an API. If you are still choosing your foundation, picking the right RAG stack walks through the vector database trade-offs.

If you are looking to build a high-performance SaaS or need help modernizing your digital presence with AI that actually works, check out what I do at Ansezz. I specialize in solving these exact types of technical problems.

Where does your own system still behave like a demo when it should be behaving like production? Get in touch — I read every war story.

Monolith to microservices: a pragmatic guide

Sun, 22 Feb 2026 00:00:00 GMT

Your monolith is a ticking time bomb and every feature you add makes the explosion more inevitable.

I have seen it happen a dozen times. A startup begins with a clean Laravel or Rails app. It is fast. It is easy. It is productive. Then the team grows. The code base swells. Suddenly, a simple change to the checkout logic breaks the authentication system. Deployments that used to take five minutes now take forty. You are not scaling your business anymore — you are managing technical debt.

This is the point where most developers start dreaming of micro-services. They imagine a world where every service is isolated and deployments are instant. But the reality is often a nightmare. If you do it wrong, you end up with a distributed monolith. You get all the complexity of networking with none of the benefits of isolation.

The solution is not a "big bang" rewrite. It is pragmatic scaling. I use the strangler fig pattern to move from monoliths to micro-services without losing my mind or my job. If you are still deciding whether to split at all, start with monolith vs microservices — this post assumes you have already made that call and want the migration playbook.

The problem with the big bang

When a monolith becomes too heavy, the immediate reaction is to want to scrap it. I have seen companies spend two years on a rewrite only to ship a product that has half the features of the original. The business dies while the engineers play with new toys.

The monolith is not your enemy. It is just a phase. The real problem is coupling. When every part of your app knows too much about every other part, you cannot move. You are stuck in a web of dependencies. If you try to jump straight into micro-services, you will likely just port those dependencies into a network layer. Now, instead of a function call failing, you have a 500 error across a network socket.

I prefer a slower, more deliberate approach. I focus on high-value extractions. I look for the parts of the app that hurt the most. Is the image processing service slowing down the web server? Is the reporting engine locking up the database? Those are your first candidates for micro-services.

The strangler fig pattern in practice

Martin Fowler named this approach after a tree that grows around another tree. It starts as a small vine and eventually replaces the host entirely. In software, this means building new features as services while the old monolith remains.

The process starts with an API gateway or a load balancer. I put a routing layer in front — Nginx or a Google Cloud HTTP(S) load balancer with Cloud Armor bolted on for WAF and DDoS protection. If a request comes for /api/v1/orders, the URL map sends it to the new service. Everything else goes to the old monolith. (If you're unsure which box does what here, see load balancer vs API gateway.)

This allows me to test the new service in production with real traffic while the monolith acts as a safety net. If the new service fails, I just flip the routing back. I do not have to migrate everything at once. I can migrate one endpoint at a time.

Containerization with Docker

You cannot do micro-services without Docker. I treat every service as a black box. The monolith might be running on an old version of PHP, while the new service is a lean Go binary or a modern Laravel instance. Docker makes this possible.

I start by containerizing the monolith. Even if it stays as a monolith for another year, putting it in a container forces me to define its environment. It makes the infrastructure reproducible.

# a simplified example of a service container
FROM php:8.4-fpm

WORKDIR /app
COPY . /app

RUN apt-get update && apt-get install -y \
    libpq-dev \
    && docker-php-ext-install pdo_pgsql

EXPOSE 9000
CMD ["php-fpm"]

Once the monolith is containerized, I can deploy it to a platform like Google Kubernetes Engine (GKE). This is where the real power of micro-services comes in. I can scale the order service to fifty instances during a sale while keeping the blog service at two.

Communication and the anti-corruption layer

The hardest part of micro-services is not the code. It is the data. Your monolith has a single database. Your micro-services should each have their own. But how do they talk?

I use an anti-corruption layer (ACL). When I extract a service, I do not let it reach back into the monolith's database. That would be cheating. Instead, I create an interface. If the new service needs user data, it asks the monolith via a private API or a message queue like Google Pub/Sub.

This keeps the new service clean. It does not care about the messy database schema of the legacy app. It only cares about the data it receives through the ACL. Eventually, when the user logic is also migrated, I just update the ACL to point to the new user service. For the asynchronous side of this — letting services react to events instead of calling each other directly — I lean on event-driven Pub/Sub or a RabbitMQ-backed queue.

Cloud infrastructure and DevOps

Scaling a monolith usually means buying a bigger server. Scaling micro-services means managing a fleet of small instances. I rely heavily on cloud-native tools to manage the complexity.

I use Terraform to manage my infrastructure as code. This ensures that my staging and production environments are identical. If I need a new database for a service, I define it in code. I do not click around in a dashboard.

On the DevOps side, I use tools like GitHub Actions or Coolify for deployments. Every service has its own pipeline. If I update the checkout service, I only deploy the checkout service. I do not have to worry about the rest of the system.

The hidden costs of micro-services

I would be lying if I said this was all sunshine and rainbows. Micro-services come with a "complexity tax." You now have to deal with distributed logging, service discovery, and eventual consistency.

I tell my clients that they should only move to micro-services when the pain of the monolith is greater than the cost of the complexity tax. If your team is three people and your app is simple, stay in the monolith. You will move faster.

But if you are hitting walls every day and your developers are afraid to touch the code, it is time to start strangling.

Pragmatic takeaways for your next move

Start with an API gateway to handle routing.
Containerize your monolith first to normalize the environment.
Use the strangler fig pattern to migrate one domain at a time.
Build an anti-corruption layer to keep new services clean.
Invest in infrastructure as code early on.
Only split when the monolith starts to hurt your productivity.

Migration is a marathon, not a sprint. I have spent months on a single extraction just to make sure it was perfect. The goal is not to have micro-services. The goal is to have a system that can grow with your business.

Have you ever tried a "big bang" rewrite only to regret it six months later? Tell me about it — I collect these stories for a reason.

Laravel multi-tenancy: a scalable SaaS architecture

Sun, 08 Feb 2026 00:00:00 GMT

I still remember the panic of my first SaaS launch. I was watching the logs as the third customer signed up. Suddenly I realized I had no idea if customer A could see customer B's data. That realization is a rite of passage for every developer.

Building a software-as-a-service (SaaS) platform is a massive technical challenge. The biggest hurdle is almost always data isolation. You need to ensure that every tenant feels like they have the whole application to themselves. If you get this wrong early on, it will haunt you forever.

I have spent years refining a scalable Laravel multi-tenancy architecture. It is the most robust way to serve many customers from a single codebase without their data ever bleeding together. Here is how I approach it to keep both security and scalability intact.

Why simple database structures fail SaaS

Most developers start with a single database. They add a user_id or team_id to every table. It works fine for the first ten users. Then the complexity grows.

You start adding more relationships. You forget to add a where clause in one obscure controller. Suddenly one customer is seeing another customer's private invoices. This is a catastrophic failure. It kills trust and can end your business overnight.

Performance also becomes a nightmare. As your database grows to millions of rows the queries get slower. Indexing helps, but it does not solve the fundamental problem of data bloat. You need a strategy that isolates data while keeping your infrastructure manageable.

Choosing your isolation strategy

When I build custom web solutions I always start by choosing between two main paths. You either go with a single database or a multi-database setup.

The single database approach uses a shared schema. Every row has a tenant_id. It is cheap to run and easy to update. I recommend this for startups where costs need to stay low. You can manage thousands of small tenants on a single server this way.

The multi-database approach is the gold standard for enterprise. Every customer gets their own database. This offers the strongest isolation and makes per-tenant backups and replication straightforward. If one database crashes the others stay online. I use this for high-value clients who have strict compliance needs.

I often use the stancl/tenancy package for Laravel. It is the most flexible tool in the ecosystem. It allows you to switch between these strategies as your business grows. You can find out more about how I handle these complex technical challenges on the Ansezz work page.

Building with global scopes

The secret to sleeping well at night is automation. I never rely on my memory to filter data. Instead I use Laravel global scopes.

A global scope automatically adds a filter to every query on a model. It ensures that Customer::all() only returns customers for the current tenant. It happens behind the scenes so you cannot forget it.

I create a BelongsToTenant trait. I apply this trait to every model that needs isolation. It handles the filtering and automatically sets the tenant_id when a new record is created. It is a simple solution that prevents 99 percent of data leaks.

Here's what that trait looks like in practice:

<?php

namespace App\Concerns;

use App\Models\Tenant;
use App\Scopes\TenantScope;
use Illuminate\Database\Eloquent\Relations\BelongsTo;

trait BelongsToTenant
{
    protected static function bootBelongsToTenant(): void
    {
        static::addGlobalScope(new TenantScope());

        static::creating(function ($model): void {
            if (! $model->tenant_id && app()->bound('tenant')) {
                $model->tenant_id = app('tenant')->id;
            }
        });
    }

    public function tenant(): BelongsTo
    {
        return $this->belongsTo(Tenant::class);
    }
}

You also need to isolate your cache and your file storage. If two tenants upload a file named logo.png they should not overwrite each other. I configure Laravel to use tenant-specific prefixes for all storage paths. This creates a true "sandbox" environment for every user.

Scaling on the cloud

Your architecture is only as good as the infrastructure it runs on. I usually deploy my Laravel apps using Docker and cloud providers like Google Cloud or AWS.

Containerization is key. It lets me scale the application horizontally: when traffic spikes I spin up more instances of the web server. That only works because the web tier stays stateless — tenant context is resolved per request, not stored on the box. Because the multi-tenancy logic lives at the application level, the infrastructure stays clean. When a single tenant starts pushing serious request volume, I reach for Laravel Octane to handle high traffic before throwing more servers at the problem.

I use managed database services like Google Cloud SQL. They handle the heavy lifting of backups and scaling. For multi-database setups I use automated scripts to provision new databases whenever a customer signs up. This "infrastructure as code" approach ensures that scaling is a button click away.

If you are looking to modernize your digital presence with a scalable cloud setup you can see my full range of services at ansezz.com.

The tenant switcher experience

The final piece of the puzzle is the user interface. Customers need a seamless way to move between different accounts if they own multiple businesses.

I build clean dashboards using Vue, with the frontend talking to the Laravel backend over a GraphQL API for a reactive feel. The tenant switcher is always accessible and shows the user exactly which context they are working in.

I focus on making the transition between tenants feel instant. I cache the tenant configuration in the frontend to avoid unnecessary API calls. It is these small details that separate a basic app from a high-quality pro solution.

My Laravel multi-tenancy checklist

If you are starting a new project today, here are the steps I recommend you follow.

Choose your package early. I prefer stancl/tenancy because of its flexibility. It handles subdomain routing and database switching out of the box.
Implement global scopes immediately. Do not wait until you have ten models. Add the trait to your base model and make it a standard part of your workflow.
Automate your deployment. Use Docker from day one. It makes local development identical to production. This avoids the "it works on my machine" bugs that plague SaaS launches.
Plan for data migration. As you update your schema you need a way to run migrations across hundreds of databases. Tools like stancl/tenancy have built-in commands for this.
Keep it simple. Don't build a multi-database setup if you only have five users. Start small and scale as the revenue grows. My goal is always to deliver exceptional results without over-complicating the technical stack.

Are you building a SaaS or looking to migrate your current app to a multi-tenant structure? What is the biggest technical hurdle you are facing right now? Here's how I help teams architect and ship multi-tenant SaaS, and you can always get in touch — I'd love to hear about it. 🤙

AI vs traditional development: which fits?

Sun, 25 Jan 2026 00:00:00 GMT

Most teams frame AI vs traditional development as a binary choice. That is the wrong question.

The real problem is not "AI or traditional?" — it is what kind of speed, control, and risk your business can actually afford.

I see this mistake a lot. Teams chase AI because it feels faster, or reject it because it feels messy. Both directions land in the same place: rushed systems with weak foundations, or polished systems that ship too late.

The better move is to understand where each approach wins, where it breaks, and where a hybrid model gives you the best return. Both work. They just solve different problems.

AI-powered development: the speed revolution

AI integration changes how I build software. Instead of manually writing every repetitive piece, I can use tools that understand context, generate scaffolding, speed up testing, and remove a lot of the drag from delivery. I dig into the day-to-day of this in my post on vibe coding, where taste and intent matter more than raw typing speed.

The core advantage: speed

This is where AI shines.

For standard workflows, admin panels, CRUD-heavy systems, internal tools, and first-pass prototypes, AI can cut a serious amount of time. What used to take weeks can often be reduced to days if the scope is clear and the review process is tight.

That speed usually comes from a few places:

Automated code generation. Prompts turn into usable boilerplate and feature drafts.
Faster testing. AI can draft test cases and edge-case coverage quickly.
Debugging support. It helps narrow down likely failures faster.
Documentation help. It can turn rough implementation details into clean internal docs.

How much of that speed you actually capture depends on where you sit on the AI coding workflow levels — copy-pasting into a chat window and orchestrating agents against your real codebase are not the same tool.

Who benefits most from AI development

I would lean toward AI-heavy workflows when speed matters more than perfect customization on day one.

That usually means:

Startups trying to reach product-market fit before the runway gets tight.
Small teams that need leverage more than headcount.
Businesses shipping standard features that already follow familiar patterns.
Teams where non-technical stakeholders want to contribute to discovery and prototyping.

In those cases, AI acts like a power tool. It does not replace the builder. It just makes the first cut much faster.

The trade-offs to consider

This is where a lot of teams get burned.

AI is fast at common patterns. It is weaker at deep product nuance, strange business rules, and systems that need careful long-term architecture. If you skip review, you can ship something that looks finished but behaves like a prototype wearing a production costume. It also helps to know what kind of AI you are actually leaning on — the trade-offs differ between predictive models and generative ones, which I break down in machine learning vs generative AI.

There is a longer-term cost too. Recent studies of AI-accelerated codebases report more duplicated code, larger pull requests, and faster technical-debt accumulation, so the upfront speed can quietly shift effort into later debugging and rework. That is the trap. The fix is treating AI output as a draft, not as truth — the same discipline I argue for in the architectural shift to agentic workflows.

Traditional development: the control champion

Traditional development is slower, but it gives me tighter control over how the system is shaped.

This is the path I trust most when the business rules are complex, the architecture matters, or the cost of failure is high. Every part of the system is designed with intent instead of inferred from a prompt.

The core advantage: control

Traditional development is better when the software needs precision.

That matters for:

Complex enterprise systems — lots of moving parts and layered business logic.
Regulated industries — where auditability and traceability matter.
Mission-critical applications — where downtime or bad behavior is expensive.
Custom architectures — where the product does not fit common patterns.

The predictability factor

One underrated benefit of traditional development is predictability.

Manual design, explicit code reviews, architecture decisions, and planned testing give me a clearer picture of trade-offs. It is like building with blueprints instead of assembling furniture from a photo.

That slower process often saves time later because fewer assumptions make it into production.

The time investment reality

The downside is obvious.

Manual coding, reviews, debugging, refactoring, and testing take time. You need stronger engineering talent, and you need the discipline to keep standards high when deadlines start squeezing the team.

Traditional development gives more control, but you pay for it in time and cost.

AI vs traditional development: head-to-head

Factor	AI-assisted development	Traditional development
Upfront speed	Often significantly faster	Standard industry timelines
Cost structure	Cheaper to start, debt-prone later	Higher labor cost, steadier
Team requirements	Still needs senior review	Requires senior expertise
Customization level	Strong on common patterns	Unlimited customization
Quality assurance	Fast drafts, human review required	Manual review from the start
Risk management	Variable, depends on review rigor	Predictable risk factors
Scalability	Scales output, not judgment	Scales with team growth

Making the right choice for your business

Choose AI integration when

Choose AI when your bottleneck is delivery speed and the work is close to known patterns.

That usually applies when:

Your market window is tight.
You are building standard business apps like portals, dashboards, e-commerce flows, or content systems.
Your team wants quick prototypes before committing engineering time.
Your budget is better spent on iteration than on deep custom engineering from day one.

Choose traditional development when

Choose traditional development when the cost of being wrong is higher than the cost of being slower.

That usually means:

The app needs a unique architecture.
Compliance and audit trails are mandatory.
Reliability matters more than release velocity.
Your team wants direct ownership of code quality and system design.

The hybrid strategy: best of both worlds

This is the option I recommend most often.

The strongest teams do not treat this like a religion. They use AI where speed helps and switch to traditional engineering where judgment matters.

A practical hybrid setup looks like this:

Generate boilerplate and first drafts with AI, then review and reshape manually.
Use AI for prototyping, then rebuild critical paths carefully.
Automate repetitive testing tasks, but keep human review for logic and architecture.
Use AI to accelerate docs and support material, while keeping final technical decisions human-led.

The hybrid model works because it treats AI like a junior accelerator, not like an autopilot.

Implementation guidelines

Starting with AI integration

If I were introducing AI into an existing team, I would start small.

Begin with low-risk features.
Define a review process for all AI-generated code — one that scales past line-by-line reading.
Choose tools that fit the current workflow.
Train the team on prompting, verification, and code quality checks.

Maintaining traditional excellence

If the team stays mostly traditional, I would protect the basics.

Invest in strong senior review.
Keep documentation current.
Use clear architecture standards.
Avoid rushing complex work into fragile implementations.

Building hybrid capabilities

If the goal is balance, then the workflow matters more than the tools.

Identify which tasks are repetitive and safe to automate.
Keep humans responsible for architecture and business logic.
Add quality gates before merge and deployment — here is the gate I run on AI-authored PRs.
Measure outcomes, not just speed.

The future-ready approach

The teams that will win in 2026 are not the ones that blindly choose AI or reject it.

They are the ones that know where speed is enough, where control is non-negotiable, and where a hybrid model gives them leverage without chaos.

That is the real solution.

Use AI to remove friction. Use traditional engineering to protect the parts that matter. Combine both when the business needs speed and reliability at the same time.

Your development strategy should match your business goals, not the trend cycle. If you had to choose today, which matters more for your next product: speed, control, or a hybrid path? Here's how I help teams pick and ship the right mix, and if you'd rather just talk it through, reach out — I'd love to hear which side you're leaning toward.

Scaling SaaS with Coolify: deployment strategies

Sun, 11 Jan 2026 00:00:00 GMT

You've finally moved your apps off that messy manual VPS and into Coolify. It feels great. Everything is in one place. But then the traffic starts to spike. You realize that hosting your production database, three web apps, and a memory-heavy build process on a single $10 DigitalOcean droplet is a recipe for disaster.

The "single server trap" is real. It's fine for a side project or a quick MVP. But when you're building for real customers, you need more than just a dashboard. You need a strategy. You're worried about what happens when that one server hits 100% CPU or when a simple deployment takes your whole site down for five minutes.

I've spent the last decade scaling web applications and building custom solutions at Ansezz. I've seen self-hosted setups crumble under pressure because they lacked the right architecture. The good news is that Coolify is more than capable of handling high-scale workloads. You just need to know how to pull the right levers.

In this guide, I'm going to show you how to move from a basic setup to a production-grade infrastructure using advanced Coolify strategies. We're talking multi-server nodes, zero-downtime deployments, and offloading the heavy lifting so your apps stay snappy. If you're just getting started, my walkthroughs on Coolify and Docker for SaaS hosting and running a fully self-hosted SaaS on Coolify cover the foundations this post builds on.

Moving beyond the single-server monolith

The biggest mistake I see engineers make is keeping everything on one node. When your build process starts, it eats up CPU and RAM. Your web app starts to lag. Your database gets starved for resources.

The solution is to decouple your "control plane" from your "workloads."

In a professional setup, you want one small server dedicated solely to running the Coolify instance itself. This is your mission control. Then, you add separate "app servers" where your actual containers live.

To do this in Coolify, you go to the Servers tab and add a new server via SSH. Once it's connected, you can choose which server a specific resource should be deployed to. This gives you horizontal scalability: if one server is getting full, you just spin up another one, add it to Coolify, and point your next app there.

This separation of concerns is a core pillar of what we do when building custom web applications. It prevents a single point of failure from taking down your entire digital presence.

The art of the zero-downtime deploy

Nothing kills user trust faster than a "502 Bad Gateway" every time you push a small CSS fix. By default, many self-hosted setups just kill the old container and start the new one. There's a gap. That gap is where your users get frustrated.

Coolify handles this beautifully with "rolling updates," but it only works if you tell it how to check the health of your app.

If you don't configure health checks, Traefik (the reverse proxy Coolify uses) might start sending traffic to your new container before the app inside it has even finished booting up.

Here is the workflow I use to keep deploys seamless:

Create a health endpoint. In your Laravel, Vue, or Node app, create a simple route like /healthz. It should return a 200 status code only when the app is ready to serve traffic.
Configure Coolify. In your application settings, go to the Health Check section. Set the path to /healthz and the interval to something like 5 seconds.
The rollout. When you hit deploy, Coolify starts the new container alongside the old one. Traefik only routes traffic to a container once its health check passes, so requests keep hitting the old container until the new /healthz reports healthy. The old container is then drained and killed.

This is a non-negotiable step for any SaaS or e-commerce store where every second of downtime equals lost revenue.

Offloading builds to a dedicated Coolify server

If you're building a modern app with Docker, the build process can be incredibly resource-intensive. Compiling assets, installing npm packages, and building images can spike your server usage to the moon.

If you're running that build on the same server that's trying to serve your customers, they're going to feel the slowdown.

Advanced users leverage a dedicated build server.

You can designate a high-CPU server in Coolify specifically for builds. When you trigger a deployment, Coolify builds the image on that server, pushes it to a container registry, and your production app server pulls the finished image down. That registry step is mandatory: a build server only works if you've wired up a registry (Docker Hub, GitHub Container Registry, or a self-hosted one) for both servers to authenticate against. Note that a server flagged as a build server can't also run deployed apps, so this is a dedicated role.

Your production server never feels the build. It just pulls a fresh, ready-to-run image.

What about the database?

While Coolify makes it easy to click "New Database," running your production Postgres or MySQL inside a Docker container on the same server as your app is risky.

For production workloads, I almost always recommend using an external managed database like AWS RDS or Google Cloud SQL. It handles backups, point-in-time recovery, and scaling automatically.

In Coolify, you simply provide the connection string as an environment variable. This keeps your state (the data) separate from your compute (the app) — the same stateless app discipline that makes horizontal scaling possible. If your app server goes up in flames, your data is safe on a managed platform.

Automation at scale with CI/CD

Manual deployments are for hobbyists. For a professional workflow, you want your code to move from GitHub to production without you touching a single button in the Coolify UI.

I prefer using GitHub Actions for this. While Coolify has a great GitHub App integration, using Actions gives you more control. You can run your test suite, lint your code, and only if everything passes, trigger the Coolify deployment via a webhook.

Here is a snippet of how I usually structure a simple deployment step in a .github/workflows/deploy.yml file:

name: deploy to production
on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: trigger coolify webhook
        run: |
          curl --fail -X GET "${{ secrets.COOLIFY_WEBHOOK_URL }}" \
            -H "Authorization: Bearer ${{ secrets.COOLIFY_TOKEN }}"

It's simple, direct, and ensures that broken code never reaches your servers. It keeps your development cycle clean and your mental health intact.

Advanced configuration tips

Managing a multi-server setup requires a bit of extra care. Here are a few practical takeaways to keep in your back pocket:

Resource limits. Always set CPU and RAM limits in Coolify for each application. This prevents a single "leaky" container from hogging all the resources and crashing the whole server.
External backups. If you do choose to run databases inside Coolify, use the S3-compatible backup feature. I personally use Backblaze B2 or Cloudflare R2 for this. Never rely on local backups alone.
Docker pruning. Coolify is good at cleaning up, but it's worth checking your disk space regularly. Large images can eat up your SSD fast. Set up a cron job or use Coolify's built-in cleanup settings.
Monitoring. Use a tool like Better Stack or GlitchTip to monitor your endpoints. Coolify tells you if the container is running, but an external monitor tells you if a human can actually use the site.

Scaling is a journey

Scaling isn't about having the most expensive hardware. It's about having a system that is predictable and resilient. Coolify gives us the tools to act like a giant tech company without the massive overhead of a dedicated DevOps team.

By splitting your servers, mastering health checks, and automating your builds, you move from "hoping it works" to "knowing it scales."

I've helped dozens of founders and tech leads navigate these waters. Whether you're building a Shopify app or a complex Laravel SaaS, the principles are the same. Keep your compute separate from your data, and your builds separate from your traffic.

Have you ever had a deployment go sideways because a build process crashed your production server? What's your current "war story" from the world of self-hosting? Drop me a line.

Shopify Liquid vs. headless: picking the right stack

Sun, 28 Dec 2025 00:00:00 GMT

Your store is making money, but every new change feels like surgery on a moving car.

Traffic is up. Orders are up. Pressure is up. But the theme layer is starting to fight back. Simple feature requests turn into fragile hacks. App scripts pile up. Mobile performance gets softer with every install. What used to feel fast and convenient now feels like a ceiling.

This is where a lot of brands start weighing Shopify Liquid vs. headless. The promise sounds great. More freedom. Better performance. Cleaner frontend architecture. But this is also where expensive mistakes happen. A headless rebuild can solve real problems — or create a second system your team now has to babysit forever.

The real question is not which stack sounds more modern. It is which stack fits your stage, your team, and your operational reality.

The Liquid reality: why it still wins for most stores

Liquid is still the default winner for a reason. It is tightly integrated with Shopify, fast to ship, and much easier to maintain than a custom headless frontend.

For most growth-stage stores, Liquid gives the best speed-to-market. Online Store 2.0 made theme architecture much more modular than the old days, so a solid theme setup can go a long way before it becomes a real blocker.

This is the part people underestimate. A good Liquid stack is like a well-tuned production van. It is not flashy, but it moves product reliably, gets updated quickly, and does not need a pit crew every week.

The problem shows up when business needs outgrow theme constraints. Maybe the storefront needs deeply custom interactions. Maybe product data has to come from an ERP, a PIM, and a custom backend at the same time. Maybe merchandising logic is getting too complex for theme code to stay clean. That is usually the point where headless becomes a serious conversation, not just a trendy one.

Performance is the primary driver

Performance is the most common reason teams start looking at headless, and milliseconds genuinely matter. On e-commerce storefronts, small delays compound into lower conversion rates, weaker ad efficiency, and a worse mobile experience.

A well-built headless stack using Hydrogen and Oxygen can push performance much further than a typical theme setup. You get finer control over rendering, data loading, caching, and frontend execution. That opens the door for lower LCP and a more responsive storefront.

But this is where the hype needs a reality check. Headless does not automatically mean faster. It only gets faster when the frontend architecture is actually good.

If the team over-fetches Storefront API data, hydrates too much JavaScript, or ships a bloated component tree, the custom storefront can end up slower than a decent Liquid theme — and that happens more often than people admit. There is also a middle path worth knowing about: dropping in Shopify storefront web components lets you add dynamic, framework-light interactivity without committing to a full headless rebuild.

So yes, headless can be a performance win. But only if the implementation is disciplined.

The hidden complexity of going headless

Going headless means splitting commerce from presentation. Shopify still handles products, checkout, and admin workflows. Your custom frontend handles the customer experience.

That sounds clean on paper. In practice, it means you now own two systems instead of one.

You need to manage hosting, deployments, caching, GraphQL queries, error handling, observability, and integration behavior across services. Every app in the stack has to be checked for API compatibility. If an app only works by injecting snippets into a theme, that convenience is gone.

This is the part that catches teams off guard. In Liquid, many features feel plug-and-play. In headless, the same features often become custom integration work. Reviews, loyalty, search, subscriptions, personalization, analytics. All of it may need extra engineering. The same calculus applies to newer surfaces like agentic commerce on Shopify, where the storefront has to expose clean, machine-readable APIs no matter which stack you pick.

The easiest way to think about it is this: Liquid is renting a well-equipped shop. Headless is designing your own building. You get more freedom, but now plumbing, wiring, and maintenance are your problem too.

Time and money: the real cost of freedom

Time and budget usually decide this faster than architecture opinions do.

A custom Liquid theme can often be launched in weeks. That means faster testing, faster iteration, and lower implementation cost. If the business mainly needs merchandising flexibility, better UX, and cleaner performance hygiene, Liquid usually gives a better return.

Headless is a different category of investment. The build takes longer. The team needs stronger frontend engineering. The integration surface is bigger. And maintenance does not stop after launch.

This is the important part. With headless, you are not just paying for a redesign. You are taking on a software product that needs ongoing care. Deployments, monitoring, API changes, dependency updates, caching strategy, and developer ownership all become part of normal operations.

For many stores, that trade-off is not worth it yet. More freedom is great, but freedom is expensive when the business does not fully need it.

My decision framework: which one should you choose?

I like to reduce this decision to a few practical questions.

Is the current theme actually blocking revenue? If conversion is healthy and the main pain is taste or minor flexibility, Liquid is probably still the right call.
Does the team have the engineering depth to own a custom storefront long term? Headless is not a one-time build. It is an operating model.
Are the integration requirements genuinely complex? If the storefront needs to combine Shopify with custom product logic, external systems, or a bespoke application layer, headless starts to make more sense.
Is performance a code problem or an architecture problem? Many slow stores do not need headless. They need script cleanup, better image handling, less app bloat, and tighter theme code.

The simplest stack that solves the real bottleneck is usually the best stack. Building a spaceship to cross the street is still a bad decision. You can see how this framework plays out across real Shopify builds I've shipped.

Practical takeaways for your next move

If you are stuck between Liquid and headless, start here:

Audit site speed before making architectural decisions. If LCP is acceptable, the problem may not be the stack.
Remove app bloat. A lot of slow Liquid stores are just carrying too many scripts and too much leftover code.
Map every integration. List what works natively, what depends on theme injection, and what would break in headless.
Estimate ownership cost, not just build cost. Launch is only the first invoice.
Look at Hydrogen if the business really needs headless — but keep the scope tight.

Choosing a stack is a long-term commitment. The right answer is not the most advanced one. It is the one that solves the current bottleneck without creating three new ones.

Are you dealing with real technical limits in Shopify, or just feeling the pull of a more customizable stack? Drop me a line — happy to do a 30-minute architecture sanity check.

Picking the right RAG stack: vector databases for AI

Sun, 14 Dec 2025 00:00:00 GMT

You built a cool chatbot. It works great on your local machine until you feed it 50,000 internal documents. Suddenly, it's hallucinating. It's slow. It's pulling data from three years ago when you specifically asked for last week's report. Nine times out of ten, the weak link is your RAG stack — specifically the vector database underneath it.

Building a Retrieval-Augmented Generation (RAG) system sounds like a weekend project. But once you move past the "hello world" stage, you hit the database wall. Choosing the wrong vector store early on is a silent killer. It leads to high latency, soaring cloud costs, and a painful migration six months down the line when your data outgrows your infrastructure.

I've spent over a decade building custom web applications and scaling cloud infrastructure. I've seen teams get paralyzed by the sheer number of options in the AI ecosystem. You don't need a perfect database. You need the right tool for your specific scale and team.

Let's break down the 2026 vector database landscape so you can stop scrolling and start shipping.

Why the database matters in RAG

An LLM like Claude or GPT-5 is a genius without a memory. RAG gives it that memory. Your vector database is the librarian. If the librarian is slow or loses books, the genius can't do its job. (If you're still deciding whether RAG is even the right tool versus baking knowledge into the model, my breakdown of RAG vs fine-tuning is the better starting point.)

When we talk about RAG stacks, we're looking for three things:

Latency — can it find the right "memory" in tens of milliseconds? (When it can't, a Redis semantic cache in front of the store often does more than swapping databases.)
Hybrid search — can it search by meaning (vectors) and exact keywords (full-text)?
Developer experience — how much time are you going to spend on DevOps?

The contenders: which one is yours?

1. pgvector — the "I already have a database" choice

If you are already running Postgres for your web applications, pgvector is usually your first stop. It's not a new database. It's an extension that adds vector support to the database you already trust.

It's perfect if you have under 10 million vectors. You get ACID compliance, easy backups, and your relational data stays right next to your embeddings. No new infra. No new security audits.

Pros

Zero new infrastructure if you use Postgres.
Perfect for joining vector data with user metadata.
Huge ecosystem support (Laravel, Django, Node.js).

Cons

Scaling to 100M+ vectors requires serious server muscle.
Hybrid search requires manual tuning with Postgres full-text search.

2. Pinecone — the "I want zero ops" choice

Pinecone is the gold standard for managed service. It's a serverless vector database. You don't manage clusters. You don't tune indexes. You just send vectors and get results.

In 2026, Pinecone is the go-to for teams that want to scale from zero to a billion vectors without hiring a dedicated DevOps engineer. Their serverless architecture means you only pay for what you use.

Pros

Truly managed. Pick a region and go.
World-class performance and low latency.
Great enterprise features like SOC2 compliance.

Cons

It's a black box. You can't self-host it.
Costs can scale quickly if you have high write/read volume.

3. Weaviate & Qdrant — the hybrid powerhouses

If your RAG app needs to combine semantic search with old-school keyword search, these two are the leaders. Weaviate and Qdrant are built from the ground up for high-performance vector retrieval.

Weaviate excels at "out-of-the-box" hybrid search. Qdrant, written in Rust, is incredibly fast and efficient with memory. Both offer open-source versions and managed cloud options.

Pros

Best-in-class hybrid search (BM25 + Vector).
Flexible hosting (self-hosted Docker or managed cloud).
Highly optimized for filtering (e.g., "find documents from '2025' that talk about 'security'").

Cons

More operational overhead than Pinecone.
Requires learning a new database API.

How to choose: the engineering trade-offs

Picking a database isn't about finding the "best" one. It's about matching the tool to your engineering constraints.

Factor 1: the "billions" problem

Most startups don't have a billion vectors. They have a few thousand PDFs. If you're in the sub-1M range, pgvector is almost always the right answer. It's simple and it works.

If you are building something like a global legal search engine or a massive e-commerce recommendation system, you need the distributed architecture of Milvus or Pinecone. Don't build a massive distributed system if you don't have a massive amount of data.

Factor 2: hybrid search is non-negotiable

Pure vector search is actually pretty bad at finding specific technical terms. If you search for "PHP 8.4 features," a pure vector search might give you general "PHP" articles. A hybrid search combines the "vibe" of the vector with the "exactness" of a keyword search. If your data is highly relational, it's also worth weighing vector search vs graph search before committing to a pure-vector approach.

If search quality is your #1 metric, look at Weaviate or Qdrant. They handle the blending of these two search types natively.

Factor 3: the "DevOps" tax

I'm a huge fan of cloud infrastructure and deployment. But I also know that every new piece of infra you add to your stack is another thing that can break at 3 AM.

If you have a small team, lean on managed services like Pinecone or Zilliz. If you have a strong infra team and want to save on cloud margins at high scale, self-hosting Qdrant on a tool like Coolify or Kubernetes is the move.

Implementing pgvector with Laravel

Since I work a lot with custom web development using Laravel, I want to show you how easy this looks in practice. You don't need a PhD in math to run a vector query.

// finding the most relevant document chunks
$embedding = Ai::embed($query); // get vector from OpenAI/Claude

$results = Document::query()
    ->select('content')
    ->orderByRaw('embedding <=> ?', [$embedding]) // the <=> operator is pgvector's magic
    ->limit(5)
    ->get();

That snippet is essentially the core of a RAG system. You find the content, send it to the LLM, and get a grounded answer.

Three practical tips for your RAG stack

Before you commit to a database, keep these three things in mind. They will save you weeks of refactoring.

1. Index early, but not too early. Vector indexes like HNSW are fast for searching but slow for inserting data. If you are doing a massive initial data load, insert your vectors first, then create the index. It's the difference between minutes and hours.

2. Normalize your vectors. Make sure your embedding model and your vector database are on the same page. If you use cosine similarity, normalize your vectors. It keeps your results consistent and prevents weird ranking bugs.

3. Keep the metadata lean. It's tempting to store the entire JSON object of a document inside your vector database. Don't. Store the vector and a simple ID. Keep the heavy data in your primary database (like Postgres). This keeps your vector index small and fast.

These are the cheap wins. For the deeper traps — bad chunking, missing reranking, stale embeddings — see the 7 mistakes you're making with your production RAG stack.

My personal rule of thumb

I've built systems for startups and established businesses. Here is how I usually guide them:

Default to pgvector. It's the path of least resistance for most web apps.
Move to Pinecone if you need high performance and don't want to manage servers.
Choose Weaviate if your application relies heavily on complex hybrid search and metadata filtering.

The "right" stack is the one that lets you ship your AI features today, not the one that looks the best on a benchmark chart.

Are you building a RAG system right now? What's the biggest hurdle you've hit with your data retrieval?

Drop a line or reach out. I'd love to hear your war stories.

Summary takeaways

pgvector is king for teams already on Postgres.
Pinecone is the best zero-ops solution for scaling.
Hybrid search (keyword + vector) is usually better than vector search alone.
Keep your architecture simple. Don't over-engineer for "billions" of vectors if you only have thousands.

Vibe coding: why projects need more than just logic

Sun, 30 Nov 2025 00:00:00 GMT

Most developers are obsessed with logic. We spend years mastering syntax, optimizing database queries, and debating architectural patterns. We build systems that are technically perfect but somehow feel hollow. They work, but they don't sing — and that gap is exactly what vibe coding is meant to close.

The problem is that your users don't care about your clean code or your clever recursive functions. They care about how the software feels. They care about the "vibe."

If you keep building purely for the machine, you are going to lose. The next generation of successful products won't be the ones with the most features or the tightest algorithms. They will be the ones that master the art of vibe coding.

The logic trap

I've spent over a decade in the trenches of software development. I've built custom web applications for startups and managed complex cloud infrastructure on Google Cloud and AWS. For a long time, I thought my job was to be a logic machine. I thought that if I followed every best practice and wrote the most efficient Laravel code possible, the project would be a success.

I was wrong.

Logic is just the foundation. It is the skeleton that keeps the building from falling down. But nobody wants to live in a skeleton. People want a home with character, warmth, and a specific feeling. In software, that character comes from the vibe.

When we focus purely on logic, we end up with "boring" software. It is the kind of software that does what it says on the tin but leaves the user feeling nothing. Or worse, it feels frustrating because the developer didn't think about the emotional friction of a slow-loading button or a confusing layout.

Entering the era of vibe coding

Andrej Karpathy coined "vibe coding" in a February 2025 post — "fully give in to the vibes, embrace exponentials, and forget that the code even exists." He framed it as a throwaway, weekend-project mode and has since distanced the term from production work (he now prefers "agentic engineering" for serious builds). I'm using the broader sense the industry latched onto: a shift from being a writer of code to being a curator of intent in the age of AI tools like Cursor and Claude.

Vibe coding is about letting go of the need to micro-manage every semicolon. It is about using natural language to describe the feel and behavior you want, and then letting AI handle the heavy lifting of the implementation.

In this world, your value as an engineer isn't in how fast you can type. It's in your taste. It's in your ability to recognize when a user interface feels "off" and knowing how to steer the AI to fix it. It is about prioritizing the outcome over the output — which is really a question of prompt engineering versus context engineering: giving the model enough of the right context to make good calls on its own.

I've seen this shift firsthand in my own work at Ansezz. When I'm working on a Shopify store development project, the technical logic of the checkout is important. But the vibe of the checkout — the smooth transitions, the reassuring feedback, the perfect typography — is what actually drives conversions for the business.

Tools that fuel the flow

To embrace vibe coding, you need tools that don't get in your way. You need tools that allow you to stay in a state of flow where the distance between your idea and the execution is as small as possible.

Tools like Cursor have changed the game for me. Instead of spending twenty minutes setting up boilerplate for a new Vue component, I can describe the "vibe" of the component in the chat. I can say, "build me a dashboard widget that feels airy and modern, uses a bento grid layout, and gives the user a sense of calm control over their data."

The AI generates the code. I review it. If the vibe isn't right, I don't fix the code line-by-line. I talk to the model again. I give it feedback on the feeling. "This feels too cramped. Give it more white space and make the shadows softer."

This is the essence of vibe coding. It's a high-level conversation about intent.

The senior developer guardrails

Now, I know what some of you are thinking. "This sounds like a recipe for a messy, unmaintainable codebase."

You are right to be worried. If you just "vibe" your way through a project without any discipline, you will end up with a "ball of mud." This is where the senior engineer perspective becomes more critical than ever.

Vibe coding isn't about being lazy. It's about shifting your focus. You use your senior-level expertise to build the "robust core" that allows the "vibe layer" to exist.

For me, that core is often built with Laravel and Docker. I use Laravel because it is built for "developer happiness." The framework itself has a vibe of elegance and simplicity. It provides the solid, logical foundation — the authentication, the database migrations, the API structures — that I can trust.

Once that robust core is in place, I can afford to be more exploratory with the frontend and the user experience. I can "vibe code" the top layer because I know the foundation is solid.

Why Shopify and vibe coding are a perfect match

If you work in e-commerce, vibe coding is your secret weapon. Shopify is a platform that already understands the importance of the feel. They have spent years perfecting the checkout flow and the admin experience.

When I do Shopify customization, I'm not just writing Liquid code. I'm trying to match the brand's vibe. A luxury jewelry brand needs a completely different "vibe" than a high-energy fitness store.

One should feel slow, deliberate, and expensive. The other should feel fast, punchy, and motivating. You can't achieve that through logic alone. You achieve it by obsessing over the details that the logic-only dev ignores.

How to start vibe coding today

If you want to move beyond being a logic-only developer, here are some practical steps you can take:

Prioritize your taste. Start looking at software not just as a tool, but as an experience. What apps do you love using? Why? Is it the speed? The animations? The way the buttons click? Start building a "swipe file" of great vibes.
Embrace AI as a partner, not a tool. Stop using Copilot just for autocompletion. Start using tools like Claude or Cursor to brainstorm high-level concepts. Describe the "feel" you want and see what it gives you. Wiring your editor into the rest of your stack with MCP to give the model real context is what makes this practical. Once you are comfortable here, the natural next step is real agentic workflows with MCP and agentic loops. If you want the whole progression laid out, I mapped it level by level, from gateway prompts to multi-agent orchestration.
Build a solid core. Don't let the vibe turn into chaos. Use frameworks like Laravel or tools like Docker to keep your infrastructure predictable and clean. The more you trust your foundation, the more you can play with the surface.
Iterate on the feeling. Instead of trying to get the code perfect the first time, get the "vibe" right first. Build a messy prototype that feels great, and then use your technical skills to refactor and harden it.
Focus on user empathy. Every time you write a piece of logic, ask yourself: "how will this make the user feel?" If the answer is "nothing," you have more work to do.

The future is felt, not just calculated

We are entering a time where "coding" as we knew it is becoming a commodity. Anyone can generate a function to sort an array. But not everyone can create an experience that moves people.

The future of software development belongs to the engineers who can bridge the gap between the machine and the human heart. It belongs to the people who understand that the best code is the code you don't even notice because you're too busy enjoying the vibe.

I've seen the results of this approach in my own projects and for the clients I work with. When you stop fighting the logic and start leaning into the flow, the work gets more fun and the results land harder.

What is the one app you use that just "feels" right — and what can you steal from its vibe for your next project?

Hello, world. Yes, another developer blog.

Sun, 16 Nov 2025 00:00:00 GMT

import SpeechBubble from "@/components/neobrutalist/SpeechBubble.astro"; import StickyNote from "@/components/neobrutalist/StickyNote.astro"; import CodeBlock from "@/components/neobrutalist/CodeBlock.astro"; import ComparisonTable from "@/components/neobrutalist/ComparisonTable.astro"; import BurstBadge from "@/components/neobrutalist/BurstBadge.astro";

Most developer blogs read like a LinkedIn post had a baby with a Medium article. This one won't. I'm Anass. I ship Laravel + Shopify + AI for a living, and this is where I take notes out loud.

Why now

I've spent over a decade remote, mostly head-down in client codebases. The patterns I keep reaching for — Laravel Octane at scale, RAG done right, agentic commerce — don't show up in tutorials. So I'm writing them down.

Strong opinions, loosely held. Code that runs in production.

What you'll find here

Laravel internals you actually use day-to-day
AI engineering with Claude and MCP
Shopify Plus app patterns
Architecture and DevOps lessons learned the hard way

Subscribe via [RSS](/rss.xml) — no newsletter, no popup, no LinkedIn dance.

This blog vs the AI-slop blog

Code you can actually run

Every post that needs code gets the syntax treatment — real, runnable, not pseudo-code:

<CodeBlock code={use Prism\\Prism\\Prism;\n\n$response = Prism::text()\n ->using('anthropic', 'claude-sonnet-4-5')\n ->withSystemPrompt('You are a senior Laravel engineer.')\n ->withPrompt('Refactor this controller for clarity.')\n ->asText();} lang="php" filename="app/Actions/AskClaude.php" />

That's it. First post live. More incoming.