Magento Hosting Architecture Models

Incoming traffic such as genuine customers, search engine bots, security scanners, brute-force attacks, malicious IPs, spam bots and other background noise from the internet. Currently, over 30% of all HTTP requests worldwide are bot traffic — by 2027, bot traffic will overtake human traffic!

This layer keeps unwanted traffic away from the subsequent layers, thereby conserving resources and, above all, ensuring an uninterrupted shopping experience. OPNsense, SafeLine and PARC Security complement one another: the OPNsense firewall blocks traffic at Layer 3/4 (ports, IP ranges, unwanted connections). The SafeLine Web Application Firewall with semantic attack detection filters at Layer 7 (SQL injection, XSS, bot traffic, credential stuffing). The PARC Security module provides OPNsense and SafeLine with up-to-date blacklists and supplies IP groups for both good and malicious bots, on which many WAF rules are based. Interesting to know: Traditional CDN-WAFs such as Cloudflare, Akamai or AWS CloudFront terminate TLS at their edge — the traffic is decrypted there for inspection and is therefore technically visible. SafeLine terminates TLS and decrypts on your own infrastructure!

Varnish delivers requests directly from the cache (Full-Page Cache, FPC) without the need for the subsequent layers — Nginx, PHP-FPM, database — to be activated. This not only saves resources but also has a significant impact on page delivery speed. Product and category pages, for example, are delivered in a flash.

In our architecture, the frontend and backend are separated by default. The customer’s shopping experience is not disrupted by indexers, lengthy cron jobs or large import/export processes. Security is also improved by this separation: the Magento backend (admin interface), for example, is only accessible via VPN or IP restrictions. Furthermore, this separation enables horizontal scaling of the frontend — as traffic grows, multiple frontend nodes are run in parallel, whilst the backend, cron and indexer remain centralised. RabbitMQ distributes asynchronous Magento tasks (bulk attribute updates, image generation, exports, ERP sync) across one or more workers to prevent the server from becoming overloaded — and is what makes clean horizontal front-end scaling possible in the first place.

The main database is MariaDB — deliberately chosen over MySQL because it can be converted directly into a Galera cluster (with ProxySQL as the router) if required. OpenSearch handles product search and can be scaled horizontally in the same way using a coordination node and additional search instances. Redis manages the front-end and back-end sessions.

For our infrastructure, we generally rely on a mix of cloud and dedicated servers based on Proxmox VE. Each service runs encapsulated in its own VM — optimisation, scaling and updates take place precisely where they are needed. The setup is designed from the outset to allow for expansion with additional cloud or dedicated servers at any time, in order to achieve greater reliability and performance.

The SafeLine WAF has one upstream server per site. If a site goes down, the WAF automatically switches to the remaining Varnish server.

Magento Open Source can only access one DB, one Redis or one OpenSearch server—load balancing and failover are not built-in. Therefore, ProxySQL (DB), HAProxy (Redis) and the OpenSearch Coordinator (search) handle the routing. One Nginx frontend per site — for greater load capacity and reliability. The backend admin panel and backend CLI/index are distributed across individual sites.

The Galera cluster replicates the database synchronously across both sites and the cloud. OpenSearch runs similarly as a 3-node cluster. Redis is present at every site.

Two dedicated servers instead of one — distributed across two sites. The cloud layer is extended with routing and quorum VMs.