Bitrix24 server application: where the standard contour breaks
A standard Bitrix24 portal handles the load up to a certain threshold, and beyond that specific points start to break.
The first to give way is exchange with external systems: synchronization of the catalog, order statuses, or stock runs on a schedule, and when the data volume grows, the agent does not manage to complete the cycle before the next run.
Requests accumulate, exchange timeouts grow, and some changes simply never reach the portal — the discrepancy is discovered in reports, when reconciling the two sides manually costs more than fixing it.
The second bottleneck is heavy queries inside the portal itself. A report on deals for the quarter, exporting a customer's history, recalculating access permissions: while such a query is running, it holds connections and tables, and other users wait.
At peak this looks like "the portal has frozen" — even though an individual module is working correctly, the resource is simply shared by everyone.
The third and most unpleasant one is data consistency under concurrent writes. Two processes modify the same entity: an integration updates a status, a manager edits a card, a background recalculation overwrites a field.
Without an explicit write order and locking, we get lost updates, duplicates, and records that reference already deleted objects. The error is silent: it does not fall into the log, but surfaces weeks later during reconciliation.
Hence the conclusion: the standard logic is designed for a moderate flow and is not designed for peak concurrency and large volumes.
Let us break down how this is addressed by a Bitrix24 server application — by offloading heavy operations, managed queues, and explicit write rules.
What moving server logic out brings
Moved-out logic is a separate service that takes on heavy operations: exchange with the accounting system, bulk recalculations, queue processing. The Bitrix24 portal remains the interface and entry point rather than a compute node.
The difference is immediately visible: the page is served from cache instead of waiting for synchronization to complete.
Interface response speed
When calculations and exports leave the portal core, response time stops depending on their duration. A user opens a deal or task card in fractions of a second, even if an exchange with the accounting system is in progress at that moment.
Previously, such operations blocked workers and the portal "hung" for minutes — now they run in parallel.
Exchange resilience and the job queue
The exchange is built through a queue: each event is recorded, processed in order, and retried on failure. If the external system is unavailable, jobs are not lost but wait for the connection to be restored.
This eliminates a class of failures in which data diverged between the portal and accounting and required manual reconciliation.
Error control and offloading the core
Every processing step is logged: you can see what failed, at which stage, and how many times it was retried. The load on the portal core drops severalfold — heavy tasks no longer compete with user requests.
As a result, the portal performs predictably under load, and the exchange with the accounting system stops being the point where everything grinds to a halt.
Implementation approaches: comparison of options
When you calculate the load and failure points, the choice comes down to three schemes: everything inside the portal, everything in a separate service, or a hybrid.
The difference shows up not at the start, but at scale — when queues grow and some tasks can no longer be performed synchronously within a user request.
| Option | When it fits | Limitations of the approach |
|---|---|---|
| Built-in portal tools | Small volume, simple logic, no external systems | Background processing is limited by the portal's regulations and limits; heavy tasks compete with the interface; scaling only together with the portal |
| Separate service | High load, long-running operations, integrations with external systems | You need your own queues, monitoring, updates, and data synchronization with the portal; a separate access perimeter |
| Hybrid scheme | The portal is responsible for the interface and permissions, the service — for computations and exchange | Debugging is harder: a failure can occur on either side of the junction, end-to-end request tracing is needed |
What determines the choice
The key criterion is the nature of the load. If operations are short and fit within the interface response, built-in tools are sufficient: fewer moving parts, simpler maintenance.
As soon as long-running calculations, mass mailings, or exchange with an accounting system appear, background processing inside the portal starts getting in users' way — that's when we move the logic into a separate service.
A hybrid is chosen when permissions, roles, and events are more convenient to keep in the portal, and computations — outside.
We fix the boundary between the perimeters in the documentation: which data flow goes in which direction, where the failure point is, and how a task restarts after a failure. This removes the main pain of a hybrid — it's unclear where to look for the cause.
We honestly spell out the limitations before the start: for the built-in option — a ceiling on load, for a separate service — the cost of infrastructure ownership, for a hybrid — the price of junction complexity. Beyond that, the choice is dictated not by fashion, but by the profile of the tasks.
How the implementation of the Bitrix24 server application works
The implementation of the Bitrix24 server application begins not with code, but with a survey of the environment: which external systems already provide data, where reference data is stored, how access rights and queues are organized.
At this stage, we identify failure points — synchronous calls to external APIs, locks during bulk writes, lack of idempotency during repeated event delivery.
The integration scheme depends on the audit results, and changing it midway through the work is more expensive than laying it out correctly from the start.
Stages of work
- Environment audit. We compile a map of systems, describe data flows, measure current load and peak windows. The output is a list of bottlenecks with an assessment of what exactly breaks first as volume grows.
- Integration scheme design. We determine which events go through queues and which go through direct calls, and where retries with increasing delay are needed. We agree on exchange contracts and rules for handling version conflicts.
- Service setup. We deploy the application, configure the rights of the service account, isolation of background tasks, and logging. We write logs immediately so that the processing chain of a specific event can be reconstructed from them.
- Load testing. We run scenarios at volumes close to peak and above — we look at where response time grows and how the queue behaves when the external system is delayed. We measure the share of successful operations and recovery time after a failure.
- Failure handling. We check behavior when the external service is unavailable: events are not lost, are retried on schedule, and duplicates are not created. We separately test rollback to the previous version of the application.
- Handover to support. We hand over the procedures: how to read logs, what to do if the queue hangs, how to add a new data consumer without stopping the service.
- Support. We maintain monitoring of key metrics, respond to deviations, and update the application for changes in external systems.
Each stage ends with an artifact by which the next step can be verified: environment map, exchange scheme, service configuration, load testing report, procedures.
This order makes it possible to launch the application in parts and not stop the portal's operation during implementation.
What the customer receives
We hand over not "source files on a disk," but a package that allows the system to be operated, handed over to another team, and pass an audit.
Each artifact addresses its own class of risks: configuration — environment reproducibility, data flow diagram — failure diagnostics, policies — access control, maintenance procedures — predictability of support.
- Service configuration — connection parameters to the portal, queues, limits, timeouts, environment variables. Deployment on a new environment is repeatable without "fixes from memory."
- Data flow diagram — where events come from, where they are processed, where results are written, and what failure points exist at each stage.
- Access policies — service account permissions, scopes, secrets management, separation of read and write access by portal entities.
- Documentation — purpose of modules, external dependencies, update procedure, known limitations, and extension points.
- Maintenance procedures — what is monitored, which thresholds are considered critical, who responds and how, and how rollback to a previous build is performed.
- Change and migration log — what data structure changes were applied, in what order, and how to roll back each one.
- Local launch instructions — how to spin up the service on a test environment so that changes are verified before deployment to the production portal.
We agree on the package at the design stage: you see in advance exactly what will remain with you after handover. If part of the system will be maintained by your team, we will prepare the documentation to match its level, without "magic" in the code.
Case: exchange with the accounting system without freezes
The task was a typical one: the Bitrix24 server application synchronized orders, stock, and counterparties with the accounting system on a schedule. At peaks — shift closing, inventory counts, promotions — the data batch did not have time to be processed before the next run.
The exchange queued up, some records dropped out with an error, and managers corrected stock by hand.
What it was before
A batch of several thousand items was processed in about forty minutes, and this time grew along with turnover. The share of successful operations held at around 80% — every fifth record required manual review.
Support received dozens of requests per week with the same question: "why is the stock wrong". There was no stability in the exchange: after large uploads, processing had to be restarted manually.
What was changed
The exchange was broken down into stages, and heavy operations were moved into background jobs with idempotent processing — a repeated run does not create duplicates.
Logging was added for each batch, along with automatic retry for records that failed due to a timeout, instead of stopping the entire exchange. The queue received overflow control: during a spike, jobs do not pile up endlessly but are processed in portions while preserving order.
What it became
Batch processing time was reduced by roughly four times, and now it does not depend on the size of the upload. The share of successful operations reached above 99% — manual review almost disappeared.
Support requests on the topic of the exchange dropped from dozens per week to isolated ones, and stability no longer required night shifts.
How is a server application different from the portal's built-in tools?
The portal's built-in tools are business processes, robots, triggers, webhooks, and event handlers. They solve most applied tasks: approvals, notifications, scheduled exchange with external systems.
The limits of their applicability begin where logic stops being a "reaction to an event" and becomes a long-running process: processing large data sets, integration with an external API that takes minutes to respond, scheduled calculations with partial failure and retry.
The key difference of a separate service is that it lives outside the portal's request cycle.
A built-in handler executes within the context of a user request or an agent and shares resources with the portal: if an operation runs long, the page waits, and the agent blocks the queue.
A Bitrix24 server application moves such logic into a standalone process, communicates with the portal via REST and queues, and performs heavy operations in the background. The portal remains the interface, the service is the compute core.
Background processing provides predictability: a task is placed in a queue, a worker picks it up, on failure it retries with a limited number of attempts, and the result is written back to the portal. The user does not wait, and the system does not lose data on restart.
This also relieves the load on the portal's database — heavy queries go to a separate storage instead of competing with the interface.
Choosing an approach is not "either-or" but a question of the boundary. As long as a task fits within the built-in logic and does not harm the portal's responsiveness, a separate service is redundant.
As soon as long-running operations appear, external dependencies with unpredictable response times, or the need for a fault-tolerant queue — the built-in tools are not enough, and we design a separate service. During a task review, we show exactly where this boundary lies in your case.
Common technical concerns
A server application lives inside the portal and works with the same data as the interface, so the concerns are usually the same: will this break an update, will it handle the load, who will get access to the data, and what will happen to the logic a year from now. Below are the answers to each point.
Will the application break after a portal update?
We don't patch the core or modify stock modules — the logic is moved into its own application and communicates with the portal through public interfaces.
A portal update then doesn't overwrite our files, and incompatibilities are caught on the test environment before rollout to production. If a particular branch changes the behavior of some call, we see it in the checks and adapt the application before the update reaches users.
Will the portal handle the load if the logic becomes heavy?
Heavy operations — mass recalculations, synchronization with 1C, exports — go into background jobs and are executed in batches, rather than at the moment of a user request. The portal responds to interface actions while the queue quietly processes the data.
At peak times, this is the difference between "the page opens in a second" and "everyone waits while the report runs."
How is access to data segregated?
Rights are inherited from the account: the application runs under a separate service user with the minimum required set of rights, not under an administrator. Every action is written to a log — you can see who requested what. This removes the main risk of custom logic, when it quietly gains access to the entire portal.
What about maintenance when the logic grows?
Code, configuration, and the data schema are committed to a repository, changes go through review, and are rolled out in steps with the ability to roll back.
A year from now, further development can be handed off to another team — they won't have to dig through the entire portal to understand how the application is structured.
If a concern remains unresolved — describe your task, and we'll come back with an estimate and a plan.
Let's discuss your task and come back with a plan
To come back with an estimate and a plan, rather than generalities, we need to understand your current landscape: which systems are already running, where the boundaries between them lie, and what exactly needs to change.
Describe the task in free form — that's enough for us to ask clarifying questions and propose a realistic scenario.
From there, the work proceeds through clear stages:
- Task analysis. We pin down what the output should be: which data and events are involved, who initiates them and from where, which systems are responsible for the result.
- Survey of the current landscape. We look at what already exists: the portal, the accounting system, integrations, access rights. This way the estimate is based on facts, not assumptions.
- Work estimation. We break the task into blocks, and for each one we state the effort and risks. You see what the timeline is made up of and what affects it.
- Implementation plan. We agree on the sequence: what we do first, what can run in parallel, where your decisions on process logic are needed.
- Timelines and checkpoints. We show at which stages you receive an interim result and can adjust course before the finish.
- Implementation and verification. We build, test on real scenarios, and check behavior during failures and repeated runs.
- Support. After launch, we stay in touch: we monitor operations, handle requests, and make improvements as processes change.
If some systems are unknown to you or access to them is limited — that doesn't block the start. We begin with what's available and clarify details as the analysis progresses.
Describe the task and the current landscape — we'll come back with an estimate, a plan, and timelines by stage.