Scalable e-commerce architecture: the Initpc case study

Some clients you follow for a project; others you follow for twenty years. Initpc.it belongs to the second group: an e-commerce store selling office supplies, stationery, school products and IT equipment that TN Solutions has supported since 2006, when it was an online shop like many others, through to today, with over 280,000 products in its catalogue, more than one million images and a search engine that answers across all of it in useful time.

This is not a case study about a single technology. It is the story of a scalable e-commerce architecture built in stages, replacing five sales platforms without ever losing track of the sixteen years of URLs that search engines knew, and bringing in, one at a time, everything a store of that scale demands: virtualized servers, multi-level caching, a dedicated search engine, an ERP that governs suppliers and warehouses, an artificial intelligence that writes the product pages.

This page is the big picture: context, challenge, architectural choices, problems and results. For each topic that deserves a read of its own we have written a dedicated deep dive, linked throughout the text and collected at the bottom.

The context: an online store that has grown for twenty years

Initpc.it sells to consumers and businesses, with a catalogue that ranges from ballpoint pens to toner, from office paper to gift items. The catalogue is not built by hand: it is fed by several suppliers and warehouses, each with its own price lists, its own codes, its own stock levels. This, even before traffic volumes, is what sets the project apart from a "showcase" e-commerce site: the storefront is the visible tip of a system that receives data every day, corrects it, decides what to publish and at what price, and pushes it out to the store and the marketplaces.

Our technical collaboration began in 2006 and has never been interrupted. Over twenty years we have designed and developed the systems the store runs on, following it through five sales platforms: osCommerce, Zen Cart, Magento, Magento 2 and finally WooCommerce, which is the current platform. Each step was a real migration, with data, images, customers and, above all, URLs to carry over to the other side.

The challenge: scale, history and control

The difficulties of a large e-commerce store are not a scaled-up version of those of a small one. They change in nature. A catalogue of a few thousand items can be searched with the platform's built-in function; with over 280,000 products that same function collapses and drags the database down with it. One price list can be imported with a plugin; several price lists from different suppliers, with conflicting codes and stock levels that change constantly, require an ERP. The product pages of a small shop are written; at 160,000 and then 280,000 items they are designed, generated and checked.

Add to this the history: sixteen years of URLs, generated by five platforms with five different logics, which search engines had indexed and other sites had linked to. Every migration could have scattered them. And add the control: the choice, repeated over time, not to hand over to external services what we could build and maintain ourselves, from marketplace repricing to AI-generated product pages, right through to monitoring the network perimeter.

The architecture in brief

The current architecture is layered, each layer with one job and each replaceable without touching the others. The foundation is a Proxmox VE virtualization platform on Ubuntu Server: the e-commerce roles (web frontend, database, cache, search, supporting services) live in separate virtual machines, so an abnormal load on one component does not starve the others and every layer can be sized on its own.

Layer	Components	Role
Perimeter	pfSense, Hector LIS	Firewall and network segmentation; intrusion detection and traffic monitoring
Entry point	HAProxy	Load balancing and TLS termination
HTTP cache	Varnish	Serves from memory the pages that do not need regenerating on every visit
Application	WordPress + WooCommerce	The store: catalogue, cart, orders, customer area
Application cache	Redis	Object cache and sessions, so the same database queries are not repeated
Search	Elasticsearch (ElasticPress), in Docker	The index behind catalogue search and autosuggest
Data	MariaDB	The e-commerce database
Catalogue governance	Proprietary TN Solutions ERP	Suppliers, warehouses, normalization, publishing, pricing, marketplaces and repricing
Content	Hector AI	Product data normalization and controlled generation of product pages

How the pieces fit together, what happens when one of them fails and how each layer scales is explained in the deep dive on the infrastructure architecture of the Initpc e-commerce store.

The main problems we tackled

A search function that collapsed. The platform's built-in engine queries the database with expensive queries on products and metadata: under a catalogue of this size, results came back slow and poorly relevant, and the load slowed down the rest of the site. We moved search to Elasticsearch, in a Docker container, connecting it to WooCommerce through ElasticPress: separate index, continuous synchronization, autosuggest on the search field. We cover it in Elasticsearch and search across over 280,000 products.

Five platforms, sixteen years of URLs. Each platform had written its URLs its own way. Before every migration we took stock of the existing URLs (logs, Search Console, previous sitemaps, backlinks) and built the redirect rules, canonicals and sitemaps so that rankings would not be scattered. The method is in the deep dive on the SEO migration of an e-commerce store with 16 years of URLs.

Price lists that don't speak the same language. Different suppliers and warehouses, different formats, overlapping codes, changing stock levels. The ERP we developed normalizes the data, applies the publishing rules, updates prices and stock towards the site and the marketplaces, and handles errors instead of letting them through. We tell that story in catalogue, warehouses and a proprietary ERP.

Thin product pages, and too many to write by hand. When the catalogue stood at around 160,000 items, the estimate for generating product pages with commercial artificial-intelligence APIs exceeded €30,000. We chose to build the pipeline in-house with Hector AI, bearing only the energy and server costs: attribute normalization, generation of titles, descriptions and keywording, checks before publication. The case is in Hector AI and product pages.

Performance on a site that changes every day. The pages of such a vast catalogue can neither all be pre-generated nor served from the database every time: the combination of Varnish and Redis, together with progressive work on images, rendering and metrics (desktop first, then mobile, with Lighthouse and Chrome DevTools) is what keeps the pages responsive. The real Google PageSpeed Insights tests, with desktop passing the Core Web Vitals and mobile still work in progress, are in e-commerce performance and Core Web Vitals.

The technologies

Proxmox VE and Ubuntu Server for virtualization; HAProxy, Varnish and Redis for entry point and caching; WordPress and WooCommerce as the sales platform; MariaDB for the data; Elasticsearch with ElasticPress, in Docker, for search; pfSense and Hector LIS for perimeter and monitoring; the proprietary TN Solutions ERP for the catalogue, marketplaces and repricing; Hector AI for data quality and product pages. Open technologies where they exist, our own software where the market offered only subscriptions we would have paid for forever without controlling them.

The results

• An e-commerce store with over 280,000 products and more than one million media files that remains manageable by a company, not by an IT department.
• A search engine that answers across the whole catalogue, with suggestions as you type, without weighing on the database.
• Five platform migrations in sixteen years with the legacy URLs mapped and redirected, rather than lost.
• Product pages generated and checked with Hector AI for around 160,000 items, with a significant increase in organic visibility and traffic in the following weeks and better indexing of long-tail categories and brands.
• Prices and stock levels aligned across suppliers, site and marketplaces from a single ERP, with proprietary repricing that accounts for margin and fees.
• An infrastructure in which every layer can be stopped, updated or enlarged without stopping the store.

Problem → solution

Problem	Solution	Deep dive
One server for everything, with no room to grow	Proxmox VE with separate VMs per role; HAProxy, Varnish and Redis in front of WooCommerce	Infrastructure architecture
Slow, irrelevant search, database under load	Elasticsearch in Docker via ElasticPress, synchronized index, autosuggest	Elasticsearch and search
Sixteen years of URLs from five different platforms	Inventory, mapping, pattern-based and one-to-one 301 redirects, canonicals, sitemaps	SEO migration
Heterogeneous price lists from several suppliers and warehouses	Proprietary ERP: normalization, publishing rules, synchronizations, error handling	ERP and warehouses
Selling on marketplaces with margins to defend	Multichannel publishing and proprietary repricing (margin, fees, stock)	In the ERP case
Thin product pages, impossible to write by hand	Hector AI: attribute normalization, controlled generation, batch checks	Hector AI and product pages
Exposed perimeter of a site that sells around the clock	pfSense for segmentation, Hector LIS for detection and monitoring	In the infrastructure architecture
Heavy pages on a constantly changing catalogue	Multi-level caching and progressive optimization of images and rendering	Performance and Core Web Vitals

Production, development, experimentation

An honest case study distinguishes what is running from what we are building.

In production today: WooCommerce, Elasticsearch search via ElasticPress, the Proxmox infrastructure with HAProxy, Varnish, Redis and MariaDB, the pfSense perimeter with Hector LIS, the proprietary ERP with multichannel publishing and repricing, the product pages generated with Hector AI.

In development: a new proprietary search engine, still on Elasticsearch in Docker but with an index and ranking designed by us rather than mediated by a plugin, built to use the attributes distilled by Hector AI; and a commercial version of Hector AI with a human operator in the loop, to assist the store's customers.

In future experimentation: a proprietary e-commerce platform, beyond the boundaries of WooCommerce, which we will begin experimenting with from December 2026. It is not in production and we do not present it as such: we write it here because it is the natural direction of twenty years of work on this project.

Conclusions

Initpc.it did not grow because at some point somebody bought a bigger platform. It grew because every time a piece reached its limit (the server, the search, the way price lists were handled, the way product pages were written) that piece was replaced with something designed for the next scale, without throwing away the rest and without losing the accumulated history. It is the same method we apply to our clients' projects: we describe it on the page about e-commerce development and design and, for the infrastructure side, in our server virtualization and business server support services.

If you have a catalogue that is becoming unmanageable, a migration ahead of you or a search function that no longer holds up, this case study offers a real precedent. The deep dives below go into the detail of each topic.