CS-Cart Architecture and Scalability¶

General Overview¶

CS-Cart is a monolithic PHP application. The storefront, admin panel, REST API, business logic, and extension mechanisms operate within a single application and runtime environment.

The platform supports extensibility through modules, hooks, controllers, templates, and service classes without using or natively supporting microservices. This approach provides several advantages:

• simplified maintenance: a single installation and a unified update cycle;
• no risk of data desynchronization between services;
• more predictable debugging and issue diagnostics;
• easier extensibility through hooks, modules, and templates without maintaining a distributed system;
• a low entry barrier: CS-Cart can be quickly deployed on a standard hosting or a VPS server;
• a unified REST API for integration with the core functionality of the platform.

Scalability is achieved through proven infrastructure components (cache, CDN, load balancers, and databases) rather than by splitting business logic into separate services.

CS-Cart can be deployed in a horizontally scalable infrastructure. However, scaling is achieved through external infrastructure components rather than built-in clustering mechanisms.

This provides additional flexibility: the platform does not impose a rigid cluster architecture or a fixed server layout. Users can decide how to scale their projects and which external components to use. This approach is especially valuable for technically advanced teams and projects with specific infrastructure requirements.

Horizontal Scaling¶

CS-Cart supports operation across multiple web servers. Such setup requires manual infrastructure configuration. A typical configuration may include multiple web servers running CS-Cart, a load balancer, shared file storage, a shared Redis instance, and a shared database.

CS-Cart does not perform automatic configuration or orchestration of distributed infrastructure. The main advantage of this approach is transparency, control, and infrastructure predictability. The platform does not hide infrastructure mechanisms or restrict users to a predefined clustering model.

Configuration of a distributed environment (including multiple servers, load balancers, shared files, and shared cache) is handled by the system administrator, hosting provider, or DevOps team. At the same time, CS-Cart supports integration with Redis, CDN, Varnish, and cloud storage solutions, allowing to build scalable infrastructures in accordance with project-specific requirements.

This approach is especially useful for advanced users and companies that want full control over their infrastructure architecture.

Caching Mechanisms¶

CS-Cart uses multiple levels of caching to improve performance and reduce database load. The following built-in caching mechanisms are supported:

• Redis. Redis can be used for cache storage, user sessions, and locking. This is especially useful when CS-Cart operates on multiple web servers: all servers can access the same Redis instance and share cache and session data.
• CDN. CS-Cart supports CDN integration for serving static files such as images, CSS, JavaScript, and other assets. The codebase includes a CloudFront CDN backend. Using a CDN improves content delivery speed and reduces load on the main server.
• Varnish / reverse proxy cache. Supported through the Full Page Cache add-on. CS-Cart can work with Varnish to cache entire pages. Varnish operates in front of the application and can serve ready-made pages without accessing PHP or the database. CS-Cart includes cache headers and invalidation mechanisms for Varnish integration.
• Built-in application cache. CS-Cart caches settings, service data, storefront blocks, and portions of preprocessed application data. By default, cache can be stored in files, but other backends, including Redis, are also supported.
• Static file and asset cache. The system caches and reuses compiled CSS/JavaScript files and other static resources. These files can also be served through a CDN.

Sharding and Partitioning¶

CS-Cart does not provide built-in support for database replication or sharding at the application level. The platform uses a single database connection configuration: db_host / db_name. All application queries, including both reads and writes, are executed through this connection.

This approach simplifies backup, recovery, migrations, and product updates; provides ACID guarantees for for orders, inventory, and promotions (ACID stands for atomicity, consistency, isolation, and durability); eliminates synchronization issues between master and replica nodes; and uses unified database schema with baseline indexes.

The absence of built-in sharding and replication is compensated for by the following infrastructure mechanisms:

• Redis and file-based cache reduce the number of database queries;
• Varnish allows pages to be served without PHP execution or SQL queries;
• CDN handles static content delivery;
• pagination and temporary tables are used for heavy queries;
• S3-compatible storage solutions allow shared files across multiple web servers;
• bulk operations are processed in batches instead of using sharding.

CS-Cart configuration does not include separate master/slave or primary/replica settings. For most online stores, built-in replication mechanisms are unnecessary because a typical read-heavy storefront workload is effectively handled by a combination of cache, CDN, and Varnish.

Catalog sharding by partitions or shards is also not supported by the product. Large catalogs are processed within a single database unless external infrastructure solutions are used. Infrastructure mechanisms described above are typically used to compensate for this limitation.

Database Optimization¶

CS-Cart includes baseline database indexes and a table optimization tool (Optimize database in the settings), but it does not provide automatic index tuning for large catalogs.

For large stores, index optimization is typically performed manually based on load analysis and slow SQL query analysis. Instead of automatic index management, it is recommended to use external monitoring and diagnostic tools such as:

• Percona Toolkit;
• MySQL Enterprise Monitor;
• slow_query_log;
• InnoDB buffer pool tuning;
• increasing available RAM;
• hardware upgrades when necessary.

The Optimize database function performs database table maintenance tasks: it optimizes data storage, updates statistics used by the MySQL query optimizer, and reorganizes table data when necessary.

This tool is not intended for automatic performance tuning of large catalogs. Large catalog optimization is typically achieved through caching, infrastructure optimization, and manual index tuning based on slow query analysis.

Index configuration and optimization are performed manually depending on workload characteristics and catalog structure.