The infrastructure behind the Initpc e-commerce

An e-commerce with over 280,000 products in its catalogue and more than one million images is not a website: it is a system that has to stay up while suppliers update their price lists, customers buy, crawlers pass through and marketplace exports run in the background. For Initpc, whose technical partner we have been since 2006, we chose not to put everything on a single machine, but to build a layered infrastructure in which every layer has a precise, replaceable job.

Here we describe what that infrastructure looks like today, in production: Proxmox VE on Ubuntu Server, HAProxy in front of everything, Varnish and Redis for caching, MariaDB for the data, Docker for the auxiliary services, pfSense and Hector LIS on the perimeter. We also explain what happens when one piece stops: that is where you can tell whether an architecture was designed or merely installed. This is the infrastructure deep dive of the complete architecture of the Initpc project, which also covers the platform, search, ERP integration and AI.

Why virtualise: Proxmox VE on Ubuntu Server

A WooCommerce store with a catalogue this size has workloads that differ widely from one another: the web tier serves pages and runs PHP, the database executes heavy queries on products and metadata, the in-memory cache wants RAM and low latency, search has an engine of its own, and imports run in batches overnight. On the same machine, one workload's peak becomes everyone's slowdown.

So we chose Proxmox VE installed on top of Ubuntu Server: an open-source hypervisor with centralised management of virtual machines, snapshots, built-in backup and a networking model suited to segmentation, sitting on a base we update with the same tools we use on every system we run for our clients, with no dependence on a closed appliance.

The practical consequence is that every role lives in its own VM: web frontend, database, cache, search, services. Each has its own allocated resources and can be updated, cloned or moved without touching the others. It is the same approach we apply in our enterprise server virtualisation projects: separate by role before you separate by power.

The map of the layers and what happens if one goes down

The table summarises the layers, the component that implements each one and the effect of its failure: it is the same map we use ourselves when we intervene.

Layer	Component	Role	If it goes down
Perimeter	pfSense	Firewall and network segmentation	External traffic does not get in: site unreachable, data protected
Monitoring	Hector LIS	Intrusion detection, traffic analysis	The site keeps working; visibility on events is lost until restored
Entry point	HAProxy	Load balancing and TLS termination	No request reaches the web tier: the first thing to restore
HTTP cache	Varnish	Serves pages already generated	Requests go to the web backends: site up, under more load
Application	Web VM with WooCommerce	Generates pages, cart, checkout	Varnish serves what it has in cache; dynamic pages stop
Object cache	Redis	Object cache and sessions	WooCommerce reads everything from MariaDB: slower, but working
Data	MariaDB	Catalogue, orders, customers	No orders: the one point to protect with backups
Search	Elasticsearch in Docker	Search index and autosuggest	Search falls back to native queries; everything else is unaffected
Services	Docker, ERP, imports	Price list and marketplace synchronisation	The site keeps selling on the last successful sync

The "If it goes down" column is the design criterion: no non-essential component may drag sales down with it.

Entry point: HAProxy between the Internet and the web tier

Every request that gets past the firewall goes through HAProxy, which performs two tasks deliberately kept out of the web VMs.

The first is TLS termination: certificates and encryption are handled in a single place. The backends receive already-decrypted traffic on the segmented internal network, never deal with renewals, and any policy change is made once.

The second is load balancing: HAProxy distributes requests across the web backends and checks that they respond; a backend that stops responding leaves the rotation without human intervention and rejoins it when it is healthy again. This is what makes horizontal growth of the web tier a routine operation: clone a web VM in Proxmox, add it to the backends, reload the configuration.

Two-level caching: Varnish and Redis

On a catalogue like this, caching is not an optimisation, it is part of how the system works, and the two levels play different roles.

Varnish sits in front of the web VMs and keeps the pages already generated: once WordPress has produced a product page or a category, subsequent requests are served without running PHP or querying the database. Cart, checkout and the customer area are excluded by rule. When the ERP updates a product's price or availability, the corresponding page is purged and regenerated on the next request.

Redis works inside the application: it acts as the object cache for WordPress, holding the results of the most frequent queries on options, terms and product metadata, and it manages sessions. On WooCommerce, where a single page may need dozens of database reads, it takes load off MariaDB in a structural way. In short: Varnish avoids generating the page, Redis makes generating it cheaper when that is unavoidable.

Data and services: MariaDB and Docker

MariaDB lives in a dedicated VM, sized to keep the hot part of the product and metadata tables in memory. It is the only component whose state cannot be rebuilt from the others: that is why it has its own backups, independent of the hypervisor's.

On the services VM we use Docker for everything auxiliary to the application: this is where Elasticsearch runs, queried by the site through ElasticPress, and where the ERP import and synchronisation processes live. Containers let us update or rebuild a service from a known image without one broken component dragging down the others. We describe the role of the search engine in the deep dive on Elasticsearch for e-commerce search; the flow of product data in the one on the ERP and warehouse synchronisation.

Storage and backup for over one million media files

Product images are the largest dataset and the one that grows fastest: we keep them on storage separate from the VMs' system disks, mounted by the web machines, so that restoring the web tier never means copying the media again and adding space never means rebuilding the VMs. Backup follows the same principle: VMs saved as images by the hypervisor, the database with its own dumps, media with incremental copies of only the new or changed files. Restores are tested, not just configured, because a backup that has never been restored is a hypothesis. It is the same method we offer as a Proxmox backup service.

Availability and scalability, layer by layer

The most important point is not raw power, but the fact that each layer scales on its own. The web tier scales horizontally, with more identical VMs behind HAProxy. Varnish scales first by raising the share of pages served from cache, then by adding memory. Redis scales on RAM and, if needed, by separating sessions from the object cache. MariaDB scales vertically on its VM and, looking ahead, with a read-only replica for catalogue queries. Elasticsearch scales by adding nodes to the cluster in Docker. Batch services move to a VM of their own when they start to weigh.

On the availability side the rule is to degrade rather than stop, as the table shows: only HAProxy and MariaDB actually take the shop down, and those are the two on which we concentrate monitoring and recovery procedures. Day-to-day management falls under our business server support.

Perimeter and monitoring: pfSense and Hector LIS

An e-commerce exposes a PHP application, a checkout and APIs to the public: defence cannot be reduced to updating plugins.

pfSense is the perimeter firewall and the tool we used to segment the network. The web tier is reachable from HAProxy, the database only from the web tier and the services, Proxmox management only from the administration network: a compromise of the public layer must not give direct access to the data. The rules are few, explicit and reviewed whenever the architecture changes, as in our firewall management and installation service.

Hector LIS is our intrusion detection and traffic monitoring product. It watches what passes through the perimeter and between segments, recognises anomalous patterns — scans, repeated attempts on authentication, traffic towards unexpected destinations — and flags them before they turn into an incident. On a site with so much legitimate automated traffic, crawlers and integrations included, the value lies in telling normal noise apart from what deserves action; we cover it on the Hector LIS page.