Consulting on 1C-Bitrix solution architecture

Architecture Consulting for 1C-Bitrix Solutions

Architectural decisions made at the start of a project determine the cost of every subsequent feature. A wrong choice — storing data in information block properties instead of separate tables when the volume is 100,000 elements — will, two years later, make it impossible to perform simple queries in reasonable time. Rework costs 10–30 times more than making the right choice at the outset.

Typical Architectural Decision Points

Information blocks vs. ORM tables. Information blocks are flexible and manageable through the admin interface — well suited for content. But for complex relationships, high write frequency, or non-standard queries, custom ORM tables (\Bitrix\Main\ORM\Data\DataManager) are 5–50 times faster.

Rule: if data is edited through the admin panel by editors — use an information block. If data is managed only by code (logs, queues, events, transactions) — use an ORM table.

Monolith vs. modular architecture. It is convenient to write everything in a single custom component at the start. A year later, that 3,000-line component is impossible to test and difficult to hand off to another team. The modular approach: /local/modules/company.module_name/ with a clear public API, events, and Composer-managed dependencies.

AJAX components vs. SPA approach. Bitrix supports both. AJAX components (bitrix:main.loader) work natively with the core but are limited in capability. An SPA on React/Vue (via bitrix:ui.sidepanel or a full SPA) delivers better UX but requires a separate API and complicates SSR/SEO.

Caching. Bitrix provides several layers:

Edition and License Selection

The edition determines which modules are available: b2b, catalog (B2B trade catalog), sale.crm (CRM integration in orders).

1C Integration: Architectural Decisions

The classic CommerceML exchange (file-based) works well up to approximately 50,000 SKUs. For larger volumes or real-time requirements, a REST-based exchange via the 1C API or a message broker (RabbitMQ) is needed.

Broker-based architecture: 1C → publishes an event to RabbitMQ → a Bitrix worker subscribes and processes → updates data in real time. Latency — seconds instead of hours compared to file-based exchange.

Case Study: B2B Platform, 500,000 SKUs

Goal: an online store for corporate clients with individual prices, quotas, and delivery terms per counterparty.

Problems with the standard approach:

• Storing prices in b_catalog_price — 500,000 SKUs × 200 buyer groups = 100 million records; any price query > 500 ms
• Catalog filter on information block properties — sequential scan on a table with 5 million property rows
• Standard sale cart and orders do not support quotas and counterparty-specific terms

Architectural solution:

• Prices moved to a dedicated ORM table bl_b2b_price with an index on (user_group_id, product_id) — price query: 5 ms
• Filter powered by ElasticSearch (integrated with Bitrix via a custom component)
• Standard sale extended by the company.b2b_sale module — counterparty fields, quotas, and special terms added
• Prices from 1C delivered via RabbitMQ → worker updates bl_b2b_price in real time

Result: catalog page with filter loads in 300 ms; price updates from 1C complete within 30 seconds instead of 4 hours.

What Is Included in Architecture Consulting

• Analysis of business requirements and constraints (traffic, data volume, budget)
• Comparison of architectural options with risk and cost assessment
• Bitrix edition and module selection
• Data schema and module structure design
• Integration architecture for 1C and external systems
• Stack recommendations (cache, search, queues)
• Architecture Decision Document for the development team