Architecture decisions made at the start of a project determine the cost of every subsequent feature. A wrong choice — storing data in infoblock properties instead of separate tables when you have 100,000 items — will make simple queries impossibly slow within two years. Fixing it later costs 10–30 times more than getting it right upfront. Every day we see projects where poor architecture forces the team to spend 70% of their time on maintenance instead of development. In 10+ years of work, we have conducted over 50 architecture consultations and built 30+ projects from scratch.
Typical Architecture Decision Points
Infoblocks vs. ORM Tables: Which to Choose?
Infoblocks are versatile and manageable through the admin interface — great for content. But for complex relationships, high write frequency, or non-standard queries, custom ORM tables (\Bitrix\Main\ORM\Data\DataManager) perform 5–50 times faster.
Rule of thumb: if data is edited through the admin panel by content managers — use infoblocks. If data is handled only by code (logs, queues, events, transactions) — use ORM tables.
Monolith vs. Modular Architecture
At the start, it's convenient to write everything in one custom component. A year later, that 3,000-line component becomes untestable and difficult to hand over. Modular approach: /local/modules/company.module_name/ with a clear public API, events, and Composer dependencies.
AJAX Components vs. SPA Approach
Bitrix supports both. AJAX components (bitrix:main.loader) work natively with the core but have limited capabilities. SPA with React/Vue (via bitrix:ui.sidepanel or a full SPA) provides a better UX but requires a separate API and complicates SSR/SEO.
Why Caching is a Key Performance Factor
Proper caching can speed up a site 10–50 times without changing logic. Bitrix provides several layers:
| Layer | Mechanism | Application |
|---|---|---|
| Managed cache | \Bitrix\Main\Data\ManagedCache |
Objects with invalidation tags |
| Page cache | Component settings | Entire pages/blocks |
| memcache / Redis | /bitrix/.settings.php |
Sessions, object cache |
| CDN | External CDN | Static files, images |
Edition & License Selection
| Task | Recommendation |
|---|---|
| Corporate portal | Bitrix24 on-premise, Enterprise |
| Online store with B2B | 1C-Bitrix: Business or Small Business |
| High-load marketplace | Enterprise + cluster |
| Landing page + CRM | Bitrix24 cloud |
The edition determines available modules: b2b, catalog (B2B trade catalog), sale.crm (CRM integration in orders).
1C Integration: Architecture Decisions
Classic exchange via CommerceML (file-based) works up to ~50,000 SKUs. For larger volumes or real-time requirements, use REST exchange via 1C API or a message broker (RabbitMQ).
Broker architecture: 1C → publishes event to RabbitMQ → Bitrix worker subscribes and processes → updates data in real time. Latency is seconds instead of hours with file exchange.
How We Consult on Architecture
- Analyze business requirements and constraints (traffic, data volume, budget)
- Compare architectural options with risk and cost assessment
- Select Bitrix edition and module composition
- Design data schema and module structure
- Architecture of 1C and external integrations
- Technology stack recommendations (cache, search, queues)
- Produce an 'Architecture Decision' document for the development team
Case from our practice: B2B platform with 500,000 SKUs
Task: An online store for corporate clients with individual pricing, quotas, and delivery conditions 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 >500ms - Catalog filter via infoblock properties — sequential scan on a table with 5 million property rows
- Standard
salecart and orders don't support per-counterparty quotas and conditions
Architecture solution:
- Prices moved to a separate ORM table
bl_b2b_pricewith an index on(user_group_id, product_id)— price query in 5ms - Filter via ElasticSearch (integrated with Bitrix via custom component)
- Standard
saleextended with modulecompany.b2b_sale— added counterparty fields, quotas, and special conditions - Prices from 1C transmitted via RabbitMQ → worker updates
bl_b2b_pricein real time
Result: catalog page with filter loads in 300ms, price updates from 1C arrive within 30 seconds instead of 4 hours.
| Solution Component | Technology | Rationale |
|---|---|---|
| Price storage | ORM table + indexes | b_catalog_price doesn't scale to 100M records |
| Search & filter | ElasticSearch | Full-text search + faceted filter in <100ms |
| 1C sync | RabbitMQ + worker | Real-time instead of file exchange |
| Cart & orders | Extension of \Bitrix\Sale |
Maintains compatibility with Bitrix modules |
Get a consultation on your project's architecture — we'll assess risks and propose the optimal solution within 2–3 days. Request an architecture audit to avoid expensive rework down the road.