PrestaShop Behind a Load Balancer: What Breaks and How to Fix It

PrestaShop on a single server is fine. PrestaShop behind a load balancer with auto-scaling nodes — that's where the fun begins. The framework was never built for this, and it shows.

I've been running a B2B store on PrestaShop for several years now. ~300k SKUs, hundreds of orders a day, auto-scaling on GCP. Here's what went wrong and how we dealt with it.

800 Queries Per Product Page. Yes, Really.

A single product page in PrestaShop fires about 800 SQL queries. A category listing — around 2,000. Not a bug. That's just PrestaShop being PrestaShop.

On one server you stick Redis in front of it and forget about it. On multiple nodes — not so simple.

Cache Desync Between Nodes

PrestaShop caches query results locally. Redis, Memcached, whatever — it's per-node. So each node builds its own cache.

What happens:

• Node A caches a product at 10:00
• Node B caches it at 10:02
• Admin updates the price at 10:05
• Both nodes keep serving stale data with different prices

Obvious idea: shared Redis. Problem: network latency on every hit. At 800 queries per page, even 1ms extra per query gives you almost a second of overhead. Your "fast cache" is now slower than just hitting the database.

How We Actually Solved It

We didn't fight the architecture. We went around it.

Sticky sessions via Cloudflare. Visitor lands on a node, stays on that node for the session. No desync from the user's point of view.

Local Redis on each node, TTL 10 minutes. Fast, simple, no network hop. We talked to management: "product descriptions might be 10 minutes behind." They said fine. For a B2B catalog that doesn't change every minute, this is a non-issue.

Table blacklist. This is the part that actually matters. We built a list of tables that must never be cached — any SQL query touching these tables goes straight to the database.

The blacklist breaks down like this:

Carts and sessions — cart, cart_product, customer, guest, address. Changes on every click.

Orders and payments — orders, order_detail, order_history, payment gateway tables. You don't want stale financial data. Ever.

Stock — stock_available. Showing wrong availability is worse than a slow page.

Analytics — connections, page_viewed, log. Write-heavy, would trash the cache constantly anyway.

Third-party modules — anything that deals with orders, wishlists, promotions, discounts. Every time you install a new module, you check its tables and add them to the blacklist if needed. This never ends.

Configuration — configuration, configuration_lang. Admin changes a setting — it needs to work immediately.

The rule is dead simple: if the table changes more often than once per 10 minutes, it goes on the blacklist.

What It Gave Us

Second hit on a warm cache:

• Product page: 800 → 200–300 queries (about 65% less)
• Category listing: 2,000 → 600 queries (about 70% less)

No distributed cache. No invalidation logic. No latency overhead. Just sticky sessions, local Redis, and a blacklist.

Deploying Code When There's No Single Server

On one box it's git pull && clear cache. With N nodes the questions pile up. How does code get everywhere? What about shared files? What about PrestaShop's class cache?

Shared Files on NFS

Some stuff has to be shared — images, documents, uploads. An admin goes into backoffice, uploads a banner — that image lands on one node. Others don't see it. So we mount certain directories from NFS:

• Product images and module media (banners, sliders, brand logos)
• Documents, downloads, invoices
• Upload directory
• Logs

Everything else — PHP, vendor, compiled assets — lives on each node's local disk. You do not want to serve PHP from NFS. Trust me.

The Deploy Machine

We have a dedicated deploy box. It shares the NFS mount with web nodes. Deploy looks like this:

1. SSH into deploy machine
2. git pull
3. npm run build (compiles Bootstrap and friends)
4. rsync to all web nodes, excluding NFS directories
5. Cache dirs get wiped during rsync — nodes rebuild class maps on next request

The NFS directories are symlinked on each node — /img points to NFS, everything else is local. Rsync skips the symlinked paths.

What this gives you: code hits all nodes within seconds, PHP serves from local disk (fast), shared files are always in sync, and cache resets automatically. Good enough.

Modules: The Worst Part

This is where PrestaShop really punishes you for having infrastructure.

When you click "Install" on a module, it can:

• Drop files into /override/, overriding core classes
• Run arbitrary SQL — create tables, alter schema, insert rows
• Copy assets all over the filesystem

No migrations. No rollback. It's a side-effect machine.

On multiple nodes this is a nightmare. You can't just commit a module and deploy — it needs its install hooks. You can't install via admin panel on prod — it only runs on one node.

Module Surgery

Every marketplace module goes through prep before it gets anywhere near production.

Strip the overrides. Modules come with an /override/ folder. We empty it. A developer manually reviews what the module wanted to override and merges it into the project's own /override/ directory by hand. Resolves conflicts, makes it a normal commit. Reviewable, reversible.

Why? Because if two modules try to override the same core method, you get a silent race condition. On a single server you might not notice. On multiple nodes with different cache states — good luck debugging that.

Review the install() method. Read what SQL it runs. Know what it'll do to your database before it does it.

Deploy the code first. Commit the cleaned module, git pull on deploy machine, rsync to all nodes. At this point every node has the module files but the module isn't installed yet.

Then hit Install in the admin panel. Since we stripped the overrides, the installer only does its database work — creates tables, registers hooks. Doesn't matter which node handles the request, the DB is shared and the code is already everywhere.

Rsync once more. PrestaShop rebuilds its class index after install. One more rsync pushes that to all nodes.

Tedious? Yes. But it works every time. And on production I'll take boring and reliable over clever and fragile.

Why Not Just Ditch PrestaShop?

Fair question after all of the above.

Because a €100 module from the marketplace replaces months of custom development. Mollie integration is free. Need gift cards? Wishlists? Complex discount rules? Someone already built it, battle-tested it on real stores, and sells it for the price of a dinner.

Try getting that on a custom headless build. You'll burn through your budget before you ship anything.

PrestaShop's value was never its architecture — the architecture is showing its age. The value is the ecosystem. For a small or mid-size business, solving commerce problems with off-the-shelf modules at these prices is hard to beat.

Yes, you pay for it with operational complexity when you scale. Everything in this article is that tax. But you're handling it with a small team and a sane budget, while companies on "enterprise" platforms throw 10x the money at consultants and ship slower.

That's the trade-off. If your team can handle the rough edges — and now you have a playbook — PrestaShop still makes a lot of sense.

TL;DR

• PrestaShop on multiple nodes breaks in three places: cache, deployment, and modules.
• Cache: sticky sessions + local Redis + table blacklist. 800 queries → 300. No distributed cache needed.
• Deploy: dedicated deploy machine, rsync to nodes, NFS for shared files only. PHP always on local disk.
• Modules: strip overrides, review SQL, deploy code first, install via admin second. Every time. No shortcuts.
• PrestaShop's ecosystem is worth the operational pain — if you know how to manage it.

Struggling with a similar setup? Tell me.

---

Tags: prestashop, ecommerce, devops, scaling