E-commerce Development: Tech Stacks for High Traffic

For a large-scale online store with a catalog of over 100,000 products and a daily traffic of 50,000 users, the optimal technology stack is custom, template-free development based on fast CMFs combined with PostgreSQL databases, Redis caching, and the Elasticsearch search engine. Ready-made CMS solutions often fail under such conditions because their architecture contains a lot of excess code and creates an excessive number of database queries during stock synchronization or product filtering.

Large e-commerce projects require more than just a beautiful storefront; they need a stable ecosystem capable of processing hundreds of orders simultaneously without delays or failures. When a large-scale advertising campaign or seasonal sale launches on the site, every second of delay costs the business thousands of dollars in lost profit. That is why the project architecture must be built with horizontal scaling, asynchronous processes, and maximum code optimization in mind. If the system is not designed for peak loads, the site will simply stop loading during a promotion, leading to catastrophic reputational damage.

A properly selected technology stack helps avoid technical debt in the future. Instead of constantly fixing bugs and trying to speed up a slow template, the business gets a flexible tool that easily adapts to new market requirements, allowing for the seamless integration of any payment gateways, delivery services, and internal accounting systems. A custom approach to development ensures that the resource will work stably even during extreme traffic peaks. In our experience, we recommend building in a capacity buffer of at least 30-40% of projected peak traffic levels.

Why ready-made CMS are not suitable for large e-commerce projects

Ready-made CMS are a great solution for starting a small business with a limited budget, but for large-scale projects, they become a serious obstacle due to their monolithic structure. Attempting to adapt a standard platform to the unique business processes of a large company usually leads to the creation of a cumbersome add-on that consumes huge amounts of server resources and runs extremely slowly. Using template-based solutions for a large e-commerce project is like trying to turn a standard family sedan into a heavy-duty dump truck by attaching dozens of external trailers.

A ready-made CMS is like a one-size-fits-all suit: it fits everyone a little, but fits no one perfectly, especially when the business starts to grow rapidly.

Why an "all-in-one" architecture slows down a website

The monolithic architecture of popular CMS tries to satisfy the needs of completely different types of websites simultaneously. Because of this, the core of the system is built with redundant functionality that is loaded with every user request, even if they are just viewing a single page. In our experience, more than 70% of the standard code in ready-made CMS is not used at all in a real project, yet the server is forced to spend RAM and CPU time processing it. This significantly reduces the overall speed of page generation. If deep optimization of the core is not performed, the server response time (TTFB) will grow exponentially as the number of visitors increases.

A typical mistake architects make when working with monoliths is trying to speed up the site by using more expensive hosting. This increases costs by 3-5 times but does not eliminate the slow TTFB, which causes Google to lower the site's rankings.

The problem of security and third-party plugin vulnerabilities

To expand the functionality of ready-made systems, developers are forced to install dozens of third-party plugins from various authors. Each such plugin is a potential vulnerability through which attackers can gain access to the customer database or payment information. Since the source code of these modules is open, hackers are constantly looking for holes in them. The presence of a large number of plugins also complicates the updating of the CMS itself, as any core update can completely break the site's functionality. For a large store, using unverified modules is a direct path to data leaks and reputational risks.

According to our statistics, 85% of e-commerce hacks occur due to outdated third-party modules. What happens if you do not update the security perimeter? Attackers will gain access to customers' payment data, which threatens the company with huge fines.

Scaling limitations when increasing the product database

When the number of catalog items exceeds 50,000 units, ready-made CMS begin to experience serious performance issues. The standard database structure is not designed for complex queries with many filters (by brand, size, color, etc.). As a result, simple product filtering in a category can take 5-10 seconds, which is completely unacceptable for modern e-commerce. Large-scale projects require a different architecture, where the database is designed individually for specific business tasks. Ignoring this rule leads to the web server freezing when dozens of users try to apply filters simultaneously.

When exceeding 50,000 products, queries to EAV tables completely lock the database. If data denormalization is not performed, the product card generation time will increase to 8 seconds, leading to the loss of 60% of potential buyers.

Risks of data loss during automatic updates

A typical mistake is updating a ready-made CMS without first testing on a copy of the site. Since most CMS-based stores have customizations, core updates often cause conflicts with plugins. This leads to the cart or payment modules stopping work on the site. It is recommended to perform updates only after a full backup and verification on a test environment for 2-3 days. Neglecting this step can cause sales to stop for several hours or even days.

Regularly ignoring backups before an update leads to the total loss of orders for the current day. To restore the database, developers will need at least 12 hours, during which the online store will suffer losses.

Difficulty of fixing bugs in proprietary code

When you use a ready-made CMS, you are completely dependent on the developer of that platform. If you find a critical bug that slows down the site, you cannot simply go into the code and rewrite it, as this would violate the license or be overwritten during the next update. Custom development allows you to have full control over every line of code, which is critical for high-load systems. The ability to make quick fixes is the key to the continuous operation of your business.

Fixing bugs in ready-made solutions often drags on for weeks due to the convoluted core structure. In custom systems, fixing a critical bug takes up to 2 hours, which minimizes service downtime.

For large online stores, it is critical to have an architecture that allows the frontend to be separated from the backend and scaled independently. This ensures the stability of the storefront, even if heavy stock synchronization with an ERP system is taking place at that moment. Ready-made CMS usually do not allow such a separation without deep and expensive reworking of the entire platform core.

• Redundant core code slows down server response
• High risk of hacks due to third-party module vulnerabilities
• Difficulty in updating the system when changing third-party plugins
• Low processing speed for large databases
• Inability to flexibly customize for non-standard business processes
• Unpredictable conflicts between different plugin versions
• High memory consumption per user session
• Difficulty in implementing a custom API for CRM
• Limited horizontal scaling at the code level
• Increased response time for complex SQL queries

Which database architecture will ensure stability during peak sales

The heart of any large-scale e-commerce project is its database, which must withstand simultaneous queries from thousands of buyers and synchronization with internal accounting systems. To ensure high performance, relational databases are used to store structured information about orders and users, as well as non-relational stores for quick access to temporary data. An optimal data architecture is built on the principle of load distribution and avoiding direct heavy queries to the main storage while users are browsing the catalog.

A properly configured database should not just store information, but be able to deliver it in milliseconds even during a critical influx of buyers.

Replication and load distribution between database servers

For high-traffic projects, database replication technology is used, where one main server is created for writing (Master) and several servers for reading (Slave). What we see in practice is that such a distribution allows the system to be offloaded: all order processing and user registration operations go to the Master server, while browsing products, categories, and filtering occur through Slave servers. This prevents database table locking during active shopping. The typical procedure for configuration is offloading reads to separate nodes and setting up automatic failover if a server fails.

The procedure for configuring replication requires offloading reads to Slave servers. If this is not done, during promotions, the database will block the order processing flow, and users will see a server connection error.

Query caching using Redis for instant response

So that users do not wait for a database response with every click, information that rarely changes (menu structure, static pages, product characteristics) is stored in fast RAM using Redis technology. This allows ready-made data to be delivered in microseconds. Applying smart caching reduces the load on the main database server by approximately 80-90%, thanks to which the site works stably even during an influx of tens of thousands of visitors simultaneously. This is critical, as SQL queries are the most expensive operation in terms of execution time.

A typical mistake is indefinite caching without automatic clearing. If a product price changes in the ERP, but Redis is not updated, the customer will buy the product at the old price, which will cause direct losses for the company.

Fast full-text product search via Elasticsearch

Standard search via an SQL database is too slow and cannot account for language morphology, user typos, or synonyms. For a large online store, implementing a specialized search engine like Elasticsearch is mandatory. It builds an inverted index of products and allows you to instantly find the necessary items among millions of options, taking into account personal recommendations and correcting typos in real time. Using the flexible Atom CMF framework allows for the seamless integration of such search tools directly into the site's core.

The Elasticsearch integration process takes 7-10 days. What happens if you leave the search on standard SQL queries? Each search query will overload the database, increasing the site response time to a critical 5 seconds.

Using indexes to speed up retrieval

Many developers forget about proper indexing of tables in the DB. If there are 1,000,000 products in a table, searching by an attribute without an index forces the database to scan every row. We recommend creating composite indexes for the most frequent filters. This takes up more disk space but reduces retrieval time from seconds to milliseconds. A typical mistake is adding too many indexes, which slows down the process of writing new products, so a balance is needed.

An excessive number of indexes slows down the import of new products from 1C by 3 times. The procedure involves indexing only those fields that are actually used in catalog filtering by buyers.

Organizing a database using proper indexing is like the work of a professional librarian who knows exactly the location of every book by catalog, instead of searching the entire library room by room every time. This allows reducing the catalog page generation time to a record 50-100 milliseconds, which positively affects conversion and customer satisfaction.

• Database replication to separate read and write streams
• Using Redis for real-time dynamic query caching
• Implementing Elasticsearch for instant and smart catalog search
• Optimizing indexes to speed up complex product filtering
• Asynchronous logging and analytics writing to reduce load on the main server
• Configuring message queues for background tasks
• Real-time monitoring of slow SQL queries
• Sharding large tables into logical parts
• Regular cleaning of temporary data and logs
• Using SSD drives with high IOPS for the DB

Frontend and backend: technologies for ultra-fast page loading

To achieve maximum performance, modern developers use a Headless architecture, where the visual part of the site (frontend) is completely separated from the data processing logic (backend). They communicate with each other using a fast API. This allows for the creation of interfaces that load almost instantly and work like mobile apps. Separating the architecture into two independent parts also simplifies development, testing, and further scaling of the online store.

A modern user will not wait for a page to load for longer than three seconds — every additional click must happen instantly.

Advantages of the Headless approach and API-first development

When using a Headless architecture, the frontend is built on modern JavaScript frameworks such as React, Vue.js, or Next.js. The backend is solely responsible for business logic, order processing, and database work, returning results in JSON format. In practice, this looks like this: when a user navigates between categories, the site does not reload the entire page with the header and footer, but only updates the product list, which makes the transition instant. This allows for a reduction in data transfer traffic by 60-70%.

Although developing a Headless architecture requires 40-50% more time compared to a standard monolithic scheme, this approach pays off completely due to the ability to independently scale the frontend on cloud servers like Cloudflare or Vercel.

Choosing a server-side programming language for business logic

For developing a stable and fast server-side for large-scale e-commerce projects, PHP version 8.x is most often used in combination with optimized frameworks, or Node.js for high-rate microservices. Modern PHP demonstrates high code execution speed and has a developed ecosystem for working with databases and message queues. The main thing is to develop the system from scratch for specific business needs, avoiding heavy universal solutions that slow down code execution. Using asynchronous operators allows for processing thousands of requests simultaneously without freezing.

A common mistake is choosing rare or experimental programming languages for the backend, as this creates a shortage of developers on the market and increases the cost of project maintenance by 2-3 times. Using modern PHP 8.2 or PHP 8.3 with frameworks like Laravel or Symfony allows you to find qualified specialists in the shortest possible time.

Optimizing the client-side for Core Web Vitals metrics

The speed of page loading on a user's device directly affects the site's position in Google's search engine. The frontend part must meet strict Core Web Vitals requirements. To do this, Server-Side Rendering (SSR) technology is used, which allows the server to provide a ready-made HTML page to the user, as well as lazy loading for images and media files. This ensures a high loading speed score even on mobile phones with slow internet. An optimized frontend has a direct impact on the Bounce Rate.

To achieve 90+ points in PageSpeed Insights, it is necessary to configure lazy loading for media. If the LCP metric is not optimized to 2.5 seconds, the Google search algorithm will penalize the site in search results.

Using HTTP/3 to accelerate resource transfer

Configuring a modern web server with support for the HTTP/3 (QUIC) protocol significantly speeds up the loading of static resources (images, JS files, fonts). This is especially important for users with unstable mobile internet. If the server does not support modern protocols, resources are loaded sequentially, which creates a request queue and slows down page rendering by 1-2 seconds.

If HTTP/3 support is not provided, mobile users with unstable connections will load the interface 40% slower. This critically reduces the site's conversion in regions with low 4G speeds.

A Headless architecture is like a high-end restaurant, where the kitchen workspace (backend) and the dining room for guests (frontend) are completely separated by a beautiful and functional serving line. Thanks to this, the chefs are not distracted by the guests' conversations, and the waiters instantly receive ready-made orders and bring them to customers without any delays.

• Separating the interface from business logic via API
• Using React or Vue.js for a dynamic and smooth interface
• Server-side based on modern PHP 8 and fast CMF solutions
• Applying Server-Side Rendering (SSR) for fast page startup
• Optimizing images and fonts to meet Google Core Web Vitals requirements
• Using a CDN to deliver content from the node closest to the client
• Minimizing JS/CSS files to reduce browser parsing time
• Caching static content on the client side
• Abandoning heavy third-party libraries in favor of native JS
• Using Web Workers to perform calculations in the background

Comparing solutions: ready-made CMS vs. custom development on CMF

Before starting the technical implementation of a large-scale project, every business owner faces a choice: use a popular ready-made CMS or invest funds in custom development based on a flexible CMF. Both approaches have their merits, but their effectiveness differs drastically depending on the scale of the project, planned traffic, and the company's long-term goals. Making the right decision at this stage allows you to save tens of thousands of dollars on site maintenance in the future. Custom architecture is built with a buffer for 5-10 years of growth.

Investments in your own digital infrastructure are not expenses, but a capitalization of your business that makes it independent of third-party licenses.

When a business should really choose a ready-made CMS

Ready-made systems are ideal for testing a new niche when you need to quickly launch an online store with an assortment of up to 5000 products and verify demand. In such a case, it makes no sense to invest large budgets in custom development from scratch. However, if your business plans large-scale growth, a ready-made platform will quickly exhaust its technical potential, and you will have to order a full migration of the site to a different architecture, which our article on how developing an online store without a CMS works describes in detail. If you expect more than 1000 orders per day, any ready-made CMS will require serious modification.

Upon reaching 10,000 users per day, maintaining an outdated CMS becomes too expensive. It is recommended to plan the transition to a CMF in advance to avoid a sudden site crash during seasonal sales.

Why a custom solution pays off with million-dollar turnovers

Developing an online store based on a CMF from scratch costs from $7000, but these investments pay off due to high conversion, stability, and low hosting costs. A custom site consumes significantly fewer server resources than a heavy CMS, which allows you to save hundreds of dollars every month on server rental. In addition, a unique design and fast interface performance increase customer loyalty and stimulate repeat sales that cannot be achieved on a standard template. Custom code is a company asset that can be easily transferred between developer teams.

Investments in a CMF pay off within 3-6 months. Code optimization reduces hosting costs by 60%, and fast order processing increases site conversion by 1.5%, increasing daily net profit.

Flexibility in changing business logic

On a custom CMF solution, you can implement any unique mechanic: from complex loyalty programs with dynamic discounts to individual accounts for B2B clients with their own pricing. In ready-made CMS, you are limited by the functionality of a module that someone wrote for the mass market. Your own code allows you to adapt to market changes in days, not months, which provides a significant competitive advantage.

Based on a CMF, a new promotional mechanic is implemented by a content manager in 1 day. On a ready-made CMS, this process requires writing custom plugins, which delays the launch of the promotion by 2 weeks and increases costs.

Custom development allows you to create a digital fortress for your business, where every entry and exit is strictly controlled by reliable algorithms.

The choice between a ready-made CMS and a custom solution on a CMF is like buying a ready-made modular house compared to building a permanent cottage according to your own design on a reliable foundation. A modular house can be set up in a week, but it is impossible to remodel it, add a second floor, or place heavy equipment in it, whereas a custom project is built for any future needs of the owner.

Security strategy and protection of the online store from peak cyber threats

In addition to stability under load, a large-scale e-commerce project requires reliable protection of confidential data and resilience against external threats. When a site processes thousands of transactions daily, it becomes an attractive target for hackers and unscrupulous competitors. In our experience, building a multi-layered security perimeter is a mandatory stage in designing a modern internet platform.

The security of an e-commerce platform is a continuous process, where the weakest link is usually outdated software or the human factor.

Protection against DDoS attacks and traffic filtering at the CDN level

To protect against malicious traffic, we recommend configuring proxying through a geo-distributed CDN network. This allows filtering requests and blocking bots before they even reach your server.

The procedure for protection includes activating WAF and limiting request rates. If this is not done, a powerful DDoS attack will block the site for several days, leading to loss of profit and reputation.

Regular code audit and security of payment integrations

All payment gateways must work through secure protocols with data tokenization so that customer information is not stored on the store's servers. This eliminates the risk of confidential information leaking during a hack.

A typical mistake is saving logs with payment data on the server, which is a violation of PCI DSS. For security, it is necessary to conduct automatic code scanning using SAST tools at every site deployment.

• Proxying traffic through the Cloudflare CDN security network
• Encryption of all transmitted data according to the TLS 1.3 standard
• Tokenization of payment operations without saving cards on the server
• Regular automatic code testing for vulnerabilities
• Two-factor authentication for site administrators and managers