Imagine: a carsharing service is launched, but during peak load the car map lags, driver verification drags on for hours, and tariffs cannot be changed quickly. Sounds familiar? Our team of 1C-Bitrix certified developers has over 12 years of experience and has completed 100+ projects for transport and logistics companies. In this article — architectural solutions and real numbers to help avoid these pitfalls.
Why does carsharing need 1С-Bitrix?
1С-Bitrix provides ready-made modules for infoblocks, users, and payments, accelerating development by 2–3 times compared to a custom solution. Highload-blocks and tagged caching allow handling up to 10,000 requests per second on a typical server, as documented in Bitrix official resources. This is especially critical for the real-time map: Redis with a 15-second TTL reduces database load by 10 times. Clients typically save 30% on total cost and reduce time-to-market by 2-3 months.
How to build a real-time car map?
The map is the central interface of the service. Coordinates are updated by a telematics service (GPS trackers every 10–30 seconds). Bitrix does not process telematics — that's a separate backend service. The scheme:
- The telematics service writes coordinates, status, and fuel level to Redis or PostgreSQL.
- A custom controller in
/local/routes/ fetches data from the storage and returns JSON with cars in a given bounding box.
- The frontend (Yandex.Maps JS API) requests the API when loading and moving the map. It receives an array of objects with id, coordinates, class, model, fuel, tariff group, status.
- Markers update without reloading. Free cars are active, busy cars are not displayed.
Optimization: caching in Redis with a 15-second TTL; for large volumes — PostGIS with spatial indexes (ST_Within). Client throttling — request no more than once every 10 seconds and only when the map moves. The performance difference between Redis and PostgreSQL is clear: Redis is 2x faster on reads but less reliable — so we use Redis for caching and PostgreSQL for storing trip history.
| Feature |
Redis (Cache) |
PostgreSQL (Permanent) |
| Read speed |
2x faster |
Slower |
| Durability |
Volatile |
Persistent |
| Use case |
Real-time map |
Trip history |
Telematics integration details
The telematics service ingests data via REST API calls. We use event-driven architecture with RabbitMQ for processing updates. Coordinates are stored in Redis with a TTL equal to the reporting interval. For historical analysis, data is archived to PostgreSQL with hourly aggregation.
How to implement multi-step registration with driver license verification?
The standard registration module is not suitable — you need a custom component with stage separation.
Step 1: Basic data collection. User enters name, phone, email. Step 2: SMS verification. A code is sent and verified via SMS gateway. Step 3: Document upload. User uploads photo of driver license and passport via user UF-fields. Step 4: Verification. Automatic check via the Traffic Police API (or manual moderation). As a result, the user completes registration in 3–5 minutes, and the verification status is sent via SMS.
What is payment preauthorization and how to implement it?
Before the trip, an amount is held on the card. At the start of the rental, a preauth request is sent via the payment gateway API (CloudPayments, YooKassa, Tinkoff), and the identifier is saved. At the end — a capture request for the actual amount; on cancellation — void. Implementation via the sale module with a custom handler. This reduces the risk of unpaid trips by 30% compared to post-authorization.
Tariff grid on Highload-blocks: why is it convenient?
Tariffs are stored in a HL-block Tariffs with fields: name, car class, period (day/night), day of week (weekday/weekend), geographic zone (linked to a HL-block of zones with polygons), cost per minute/hour/day, minimum cost, cost per idle minute. Geographic zones — a separate HL-block with a JSON field of boundary coordinates. Cost calculation: determine zone by GPS, period, day of week, then select tariff by combination. When crossing periods or zones, the calculation is split into intervals. On the public page, tariffs are displayed as a dynamic table, updated when rates change in the admin panel (tagged caching).
What is included and how long does it take?
We assess the project in 1 day and propose an architecture that can withstand thousands of users. Timelines vary from 3 to 8 weeks depending on integration complexity. Deliverables include:
- Architecture design document and technical specification
- Setup of infoblocks and HL-blocks
- Custom components: registration, personal account, map
- Integration with telematics, payment gateways, and 1C
- API and administration documentation
- Operator training session
- One month of post-launch support
Our carsharing website development on 1C-Bitrix includes seamless carsharing integration with 1C, REST API telematics, and highload Bitrix site optimization. We leverage Bitrix's in-memory caching, lazy loading, and event-driven architecture for telematics data ingestion to ensure ACID data consistency. Contact us for a consultation — we will assess your project and suggest the optimal solution. Order carsharing website development on 1С-Bitrix — get a reliable platform that grows with your business.
How to properly design infoblocks?
When developing a 1C-Bitrix website, we see dozens of projects where poor infoblock structure slows down the site. Typical scenario: the client asks for a "product catalog." The developer creates one infoblock catalog, puts 15 properties in it. Six months later – 40 properties, 8 of which are used only for one category. The filter lags, the b_iblock_element_property table grows to millions of rows, CIBlockElement::GetList runs for 3 seconds. Consequences – conversion drop, loss of customers, additional optimization costs. In one project after catalog refactoring, page generation time dropped from 4.2 to 0.8 seconds, and annual support costs were reduced by over $10,000 through eliminated redundant queries and agents.
Our approach: design infoblocks before writing a single line of code. Separate infoblocks for entities (products, categories, brands), dictionary properties via highload blocks, trade offers for SKUs. This builds performance for years. If you want a preliminary audit of your infoblock schema, contact us for a free review of common mistakes and recommendations.
Why 1C-Bitrix outperforms most CMS for business
The choice of CMS is dictated by business needs, not preferences. Native 1C exchange via catalog.import.1c provides two-way synchronization of products, prices, balances, and orders through CommerceML without third-party modules — five times faster than developing custom exchange on OpenCart or WordPress, saving hundreds of thousands of rubles. Proactive security module includes WAF, file integrity control, SQL injection protection, and two-factor authentication; it's certified for FSTEK requirements. Modular architecture lets you enable only needed modules — iblock, catalog, sale, search — reducing DB queries per hit. Regular patches close vulnerabilities faster than open-source projects (average CVE fix time two weeks). Official documentation is maintained on the vendor's site.
What highload blocks are and how they speed up the catalog
Highload blocks are an alternative to extended infoblock properties when the list of values can grow to thousands of entries. Typical example: manufacturers, countries, colors. If stored as list properties in an infoblock, each filter triggers a full scan of b_iblock_property_enum table. With HL-blocks, selection uses indexes – filter response time drops from 1–2 seconds to 50 ms. We use HLB component and custom queries via Bitrix\Highloadblock\DataManager. This is critical for catalogs with 100,000+ items.
From our practice: an online store with 500,000 items. Standard filter by brand took 4 seconds. The server couldn't handle 50 concurrent requests – pages crashed. We moved the brand directory to an HL-block, added tagged caching for 15 minutes, and set up an agent to clear cache on change. After optimization, filter time was 120 ms, average LCP was 1.8 seconds. The project runs stable without failures.
What integrations are critical for 1C-Bitrix stores
Each e‑commerce project requires reliable connections with payments, fiscalization, logistics, and CRM. We integrate YooKassa, CloudPayments, Tinkoff, Apple Pay, Google Pay for payments; ATOL and OrangeData for 54-FZ compliance via sale.cashbox; CDEK, Boxberry, PEC, Russian Post, Yandex.Delivery for logistics; Bitrix24, amoCRM, Roistat, Calltouch, Mindbox for analytics and CRM. All integrations are configured with proper error handling and fallback logic.
What's included in 1C-Bitrix website development
Each project includes a full set of documentation and artifacts to prevent knowledge loss after handover.
- Technical specification – user stories, infoblock diagrams, integration schemas.
- Source code in Git – with commit history, release tags, branching rules.
- Administrative documentation – description of custom components, deployment instructions, list of agents and events.
- Staff training – up to a 3-hour webinar: admin panel, order management, price settings. Recorded for later review.
- Access to staging during development – test before production deployment.
- Warranty support – bug fixes for 30 days after launch. Post-warranty support packages with SLA (response 2 hours, resolution 8 hours).
Our process and technologies
| Project type |
Timeline |
Complexity |
Key features |
| Corporate website |
from 1 month |
Medium |
Catalog, news, forms, CRM integration |
| Online store |
from 2 months |
High |
54-FZ, marketplaces, 1C exchange, SKU |
| B2B portal |
from 3 months |
Very high |
Personal prices, document flow, Bizproc |
| Landing page |
from 2 weeks |
Low |
LCP < 2s, composite cache, static |
| Multisite structure |
from 1.5 months |
High |
Separate content, shared catalog, hreflang |
Tech stack: mobile-first markup, tested on physical devices (iPhone, iPad, Android). Use BrowserStack for Safari on iOS. Performance goals: LCP < 2.5 s, FID < 100 ms, CLS < 0.1. Enable composite site (composite module), CDN, tagged caching, WebP/AVIF, lazy loading. SEO: Schema.org via JSON-LD, auto-generation of sitemap.xml via seo module, canonical and hreflang for multilingual versions. robots.txt blocks /bitrix/ from indexing. CI/CD: Git, auto-deploy via GitLab CI, staging. DB migrations: sprint.migration module with versioning.
Process:
-
Analytics – study competitors, gather requirements, create prototypes in Figma. Output: technical specification with user stories.
-
Design – UI/UX with design system. Components are reusable.
-
Development – write components with custom templates in
local/templates/. Business logic in local/modules/.
-
Testing – functional, cross-browser, load testing (up to 1000 requests). Critical bugs fixed before launch.
-
Launch – deploy to production, monitoring via UptimeRobot, alerts in Telegram. Fixes for first 48 hours.
Multilingual support and redesign
Full localization via language files lang/ and SITE_ID mechanism. hreflang for each version. Regional versions with different prices and content – IP detection (main.geo) or manual selection. Multidomain – unified management of multiple domains.
Redesign without losing rankings: performance audit (PageSpeed, WebPageTest), SEO (Screaming Frog). New template in local/templates/ with preserved URL structure. 301 redirects only if URL changes significantly. Kernel update, migration to D7 ORM, infoblock restructuring, migration via sprint.migration with Git.
Guarantee and support
We have been working with 1C-Bitrix for 12+ years, completed 500+ projects. Certified developers on staff. Fixed price in contract – no surprises. Warranty period covers code errors. After warranty, subscription packages with SLA (response time 2 hours, resolution 8 hours). 24/7 availability monitoring, alerts in Telegram. Get a consultation and preliminary estimate: contact us via the form on the website or chat – we'll respond within an hour. Order turnkey development – we'll design infoblocks, integrate 1C, and speed up the catalog. If you already have a site on another CMS, order a performance audit and migration to Bitrix.
