1C-Bitrix architecture: where load growth breaks
1C-Bitrix architecture rarely breaks at once — it degrades gradually, and the first signal usually looks like “it got slower after the next catalog update.” A catalog with tens of thousands of items, exchange with the accounting system, and a growing share of authorized visitors add up to a bottleneck: catalog load grows faster than server capacity.
Typical Bitrix bottlenecks are well known: a single node serves both the catalog, the cart, and the admin panel; exchange with the accounting system runs synchronously and keeps tables locked; scheduled tasks run one after another and compete for the same data. Individually, each element is tolerable — together they produce non-linear growth in response time.
Cache is a separate story. It does not have time to warm up if invalidation triggers on every product change, and catalog pages are rebuilt for every guest.
Managed and composite cache help, but they require correct dependencies and separation of warm-up by schedule — otherwise, after a reset, the site gets a burst of heavy queries.
An audit of the site architecture begins not with code, but with a map of the site’s failure points: how many nodes there are, where the database lives, who writes to the catalog and when, and what happens when the accounting system is unavailable.
Then come measurements: execution plans for heavy queries, the share of pages served from cache, warm-up time. This shows what can be solved by configuration and what requires moving exchange into a queue and separating reads from writes. We’ll break down how this is addressed.
What a well-designed 1C-Bitrix architecture delivers
Rebuilding the 1C-Bitrix architecture begins not with cosmetics, but with measurements: how much a key page returns under load, which queries go to the database, what is cached, and what is recalculated on every request.
After moving heavy queries out and configuring caching, the response of the catalog and product pages stops depending on database size — the page is served in fractions of a second and withstands traffic peaks without increasing the number of servers.
Site fault tolerance is a consequence of separating roles, not of one powerful node: the application, database, files, and background task queue live separately, state is replicated, and the single point of failure disappears from the diagram.
Recovery time is measured in minutes, not hours waiting for a backup, because failover to the standby node is described in a procedure and practiced in drills, rather than invented at the moment of failure.
The cost of downtime is measured in lost orders and inquiries, not in abstract risks: while the site is unavailable, the customer goes to a competitor and rarely returns.
That is why the first question during consulting is how many minutes of unavailability the business considers acceptable and what exactly must keep working: order intake, the customer account, integration with the warehouse.
Release deployment gets the same measurable boundary: a set of changes goes through build and automated checks, a ready artifact is sent to the server, and rollback to the previous version is one operation.
The volume of manual actions is reduced from dozens of steps to a few confirmations, and an update stops being an event that is postponed until night.
The control points after the rebuild are response time of key pages, failure rate, recovery time, and the number of manual operations during deployment.
Operating modes: single node, cluster, role separation
The operating mode determines what exactly will have to be changed when load doubles: scale up one server, split roles across machines, or add nodes behind a load balancer.
The choice depends not on catalog size, but on where the system bottlenecks now — disk, database, or request processing. Below are real options to choose between at the start and during migration.
| Option | When it fits | Limitations |
|---|---|---|
| Single node | Catalog with several thousand items, steady traffic, files and database on the same machine | Any failure takes down the entire site; backup and updates require downtime |
| Scaling one node | Growth is predictable, the bottleneck is CPU or disk | Hits the configuration ceiling, failure remains a single point |
| Role separation | Heavy uploads from 1C, large file archive, many authorized users | Roles are connected by network: delayed replication and short timeout cause data desynchronization |
| Server cluster | Peak sales, seasonal traffic, fault-tolerance requirement | Requires shared file storage and session offloading, otherwise the visitor is “moved” between nodes |
Cluster and load balancing work only together with shared file storage and a verified database replica. If images and cache remain locally on each node, the visitor gets different versions of the page on every refresh; if writes go to the replica, carts and orders diverge.
Therefore, the mode is chosen based on recovery requirements, not on the number of servers: first we fix the acceptable downtime, then select the scheme for it.
Stages of work: from scheme audit to handover of procedures
Work follows a fixed sequence: each stage is closed with an artifact that can be verified before moving to the next.
This way we do not move into production what we have not tested, and we do not change the architecture piecemeal — otherwise the causes of degradation can no longer be separated from the consequences of edits.
- Infrastructure audit. We record facts: core and module versions, web server and database configuration, scheduler, queues, external integrations, actual peaks from visit logs. The output is a map of the current state and a list of bottlenecks, not general conclusions.
- Architecture scheme. We design the target role separation: web layer, database, cache, search, offloaded background tasks. We fix failure points, behavior under overload, and rollback procedures.
- Test environment assembly. We deploy a copy with depersonalized data and the same component versions as in production. Otherwise, test results on it prove nothing.
- Load testing. We build the load profile from real logs, not average values. We increase load step by step and monitor response time for key scenarios, error rate, resource consumption, and the place where the system breaks first.
- Migration without downtime. We move traffic to the new scheme with a minimal work window: data synchronization, switching, control measurements. Rollback is performed according to a predefined procedure, not by a decision made on the spot.
- Observability. We configure metrics and alert thresholds by node, queue, and response time — so that degradation is detected before users complain.
- Handover of procedures. We provide the scheme, update rules, instructions for typical incidents, and a review of changes to the customer’s team.
What remains in the project after work is handed over
Project handover is not an archive and a farewell call. We provide a package with which your team can deploy the environment from scratch, release a version, roll it back, and troubleshoot an incident without us.
Everything is written for the specific infrastructure of the project, not from a template, and is updated during the work.
- Infrastructure diagram — development, staging, and production environments, server roles, connections to 1C and external services, traffic entry points, cache and processing queues; bottlenecks and external dependencies are marked separately.
- Project documentation — solution structure, custom components and modules, modified core files, history of architectural decisions with rationale: why it was done this way and what was rejected.
- Environment configurations — caching and indexing parameters, scheduled jobs and background agents, values that change site behavior, with notes on what can be safely edited.
- Access policies — roles in the administrative panel by information blocks and sections, server permissions, procedure for granting and revoking access, key and account rotation.
- Maintenance procedure — backup frequency and restore testing, platform update procedure, maintenance windows, notification channels, and escalation criteria.
- Support instructions — step-by-step typical operations: publishing content, releasing and rolling back a version, connecting a new integration, diagnosing frequent cache and exchange failures.
- Registry of integrations and credentials — what is connected to what, where keys are stored, which side is responsible for exchange, and what to do if data diverges.
Acceptance follows a checklist: you verify that the environment truly deploys and rollback passes according to the instructions, not just that the documents exist.
Case study: how load was separated and catalog outages were eliminated
What was there
The catalog on 1C-Bitrix ran on a single server: the application, database, and exchange with the accounting system shared the same resources.
The exchange ran on a schedule and, during the upload of prices and stock, took database connections — product pages began taking seconds to serve, and some queries failed due to timeout.
The peak occurred in the morning, when managers opened the admin panel and visitors opened the catalog.
What was changed
Roles were separated: a dedicated node for the application, a dedicated node for the database with a read replica for the catalog, and cache moved to a shared service.
Exchange was switched to asynchronous mode via a queue — data portions are placed in intermediate storage and applied step by step without blocking the storefront.
Frequently opened sections received cache warm-up after publication: the page is assembled in advance, not by the first visitor.
What became
The catalog stopped depending on the exchange schedule: upload runs in parallel with storefront operation. Product page response at peak decreased severalfold, and timeouts on the catalog section disappeared.
Exchange became observable — the status of each package is visible in the log, an incomplete package is reapplied and does not drag the others with it, whereas previously the entire upload had to be restarted.
Measurements were taken using the same scenarios before and after: opening the catalog, product page, search.
That is why the numbers are comparable, and the scheme — role separation, asynchronous exchange, cache warm-up — can be transferred to other projects with frequent uploads.
How does rebuilding on a live system differ from migration?
These are two different scenarios, and the choice between them is based on the cost of error. Rebuilding on a live system means changes are made in the running environment: templates, components, cache settings, migrations directly on the production database.
Project migration means a second environment is raised alongside, a copy of the database and files is deployed, and everything is tested there.
Rebuilding wins on speed: there is no need to synchronize data and wait for the new environment to warm up. But the risks of changes fall on users — schema migration runs on production data, rollback is possible only from a taken copy, and cache reset is visible on live requests.
Migration costs more in preparation: the test environment must replicate production — the same 1C-Bitrix branch, the same web server configuration, the same search engine, and the same exchange rules with 1C.
But switching without downtime is done at the routing level: both environments are kept, accumulated database changes are transferred, the domain is switched, and writes to the old one are closed.
The choice rule is simple. If the structure of information blocks, properties, exchange rules with 1C, or module logic change — it is a migration: the cost of error is higher than the cost of the second environment.
Cosmetic changes in a template, cache settings, and targeted component edits are acceptable on a live system — with a taken copy and a rollback plan.
We break down the task into these two scenarios already at the estimation stage and show where the point of no return is — before work begins.
Common technical concerns before starting work
Concerns at the start are almost always engineering, not organizational: what will happen to the running site, what will code turn into after the update, and is it realistic to run the project on your own. Below are the questions asked most often, with substantive answers.
Will the site have to be stopped during work?
No. We migrate and update on a separate staging environment with a copy of the database and files, and check critical scenarios — order, payment, authorization, upload to the accounting system.
Publication is a switch to the prepared environment; returning to the previous environment takes minutes.
Will a core update break our customizations?
It is not customizations as such that break, but solutions that bypass standard extension points: edits directly in the core, monolithic templates. We map such places and move logic into standard mechanisms — after that, updates are installed without manual file merging.
Will the number of errors increase after the update?
At first, their visibility increases: we enable logging and a set of regression checks for critical paths. We install the update in stages with checks after each — the cause of a failure is visible immediately, and rollback remains targeted.
Will we be able to run the project on our own going forward?
Yes, and this is a condition of a proper handover. We provide architecture documentation, an environment diagram, an update procedure, and a change log. We bring your engineers into the loop in advance: code review, joint releases, incident review on your side.
If your case is not on the list, describe the task, and we will review it separately and come back with an estimate and plan.Let’s discuss the task and come back with an estimate and plan
For the timeline estimate to rely on facts rather than assumptions, we need initial input on the project.
The architecture of a 1C-Bitrix solution is determined by load, exchanges, and data state — the list below covers exactly the places where estimates most often diverge from reality at the start.
- Current environment: product edition, where the site is hosted, how changes are deployed, and who does it.
- Integrations: what exchange occurs with (accounting system, warehouse, payments, delivery, mailing services), on what schedule, and what happens when communication is lost.
- Load: daily traffic, peak spikes, catalog size, and the number of concurrent users during maximum hours.
- Data: volume of catalog and orders, where we migrate from, whether history and relationships between entities need to be preserved.
- Constraints: hard dates, procedures and access requirements, what cannot be changed in the current environment.
- Priorities: what is critical in the first phase and what can be moved to the next stage.
Based on this input, we come back with a stage-by-stage work plan, timeline estimate, and scope of work — from design to production rollout.
If part of the data has not yet been collected, we discuss the task as it is and record assumptions in writing, so that the start of the project does not turn into rebuilding agreements.