1С as a Mobile App Backend: Five Hidden Rakes That Only Appear in Production

Using 1С as a backend for a mobile application is a pragmatic choice for many enterprises that already rely on the platform for accounting, ERP, or warehouse management. The promise is simple: expose existing business logic via REST or OData, connect a mobile frontend, and get a real-time synchronized system without building a separate backend from scratch. However, as a recent engineering post on Habr highlights, the transition from prototype to production reveals at least five distinct pitfalls that are invisible during development. This article examines each rake based on the production experience of a team that deployed a 1С-backed mobile app, with technical details and practical mitigation strategies.

1. The REST Performance Ceiling: 3–5 Requests per Second

The first shock comes when load testing begins. 1С HTTP services, especially those using the built-in REST interface, exhibit a severe throughput limitation. The team reports that a standard 1С server configuration handles only 3–5 concurrent requests per second before response times exceed 10 seconds. This is not a bug but a consequence of 1С’s single-threaded request processing model for HTTP services. Each request acquires a lock on the infobase, serializing all incoming calls. In a mobile app with hundreds of active users, this creates an immediate bottleneck.

Why it’s invisible in dev: During development, you test with one or two devices. The app feels snappy. In production, 50 concurrent users issuing background sync requests instantly queue up.

Technical detail: The root cause is the 1С COM+ connector and the way HTTP services are handled inside the 1С runtime. Even when using a web server (Apache or IIS) in front of 1С, the bottleneck remains at the 1С application server level. The team measured that a single 1С worker process can handle at most one request at a time per infobase. Using multiple infobases (e.g., sharding by region) can help, but that adds complexity.

Mitigation strategies:
- Implement a queue layer: Use RabbitMQ or Redis to queue incoming mobile requests and process them asynchronously via a scheduled job in 1С. This decouples the immediate response from the processing, allowing the app to receive an acknowledgment token and poll for results later.
- Switch to OData with compression: The team found that OData services in 1С:Enterprise 8.3.25+ can handle slightly more throughput (up to 8–10 req/s) when response compression is enabled and $select/$filter are aggressively used to reduce payload size.
- Use a separate 1С cluster for mobile backends: Dedicate a lightweight server cluster with no background jobs to reduce lock contention.

Code example (pseudo-1С):

// Async queue processor in 1С
Procedure ProcessMobileQueue(QueueItem) Export
    // This runs in a scheduled job, not in HTTP context
    Result = ExecuteBusinessLogic(QueueItem.Request);
    SaveResultToPollingTable(QueueItem.ID, Result);
EndProcedure

2. Session Management and Authorization Blow-Up

The second rake involves user sessions. 1С’s built-in authentication (standard users and passwords) works for desktop clients but fails under mobile conditions. The team discovered that each mobile request that requires authentication forces a new 1С session creation — a heavy operation that involves opening the infobase, checking rights, and initializing the user context. In production, this led to session table bloat and eventual crashes.

Numbers: A single session creation in 1С takes 200–400 ms. If a mobile app sends 10 requests per minute per user, and you have 200 users, that’s 2000 session creations per minute, consuming 400–800 seconds of CPU time per minute — impossible.

Why it’s invisible in dev: You test with one user and keep the session alive. In production, mobile networks drop connections, users switch between Wi-Fi and cellular, and each new connection triggers a fresh authentication.

Solution: The team implemented token-based authentication using JWT (JSON Web Tokens) outside of 1С. A separate lightweight service (written in Python or Node.js) validates credentials against 1С once, issues a token with a 24-hour expiry, and the mobile app sends the token in the header. 1С then only validates the token signature via a simple HTTP service call, bypassing session creation entirely. This reduced authentication overhead by 90%.

Integration note: ASI Biont supports connecting to 1С via REST API with token-based auth — more details at asibiont.com/courses.

3. Data Model Rigidity Kills Mobile UX

1С metadata is designed for desktop forms and batch processing — rigid, with fixed field types and complex referential integrity. Mobile apps require lightweight, denormalized data structures for offline-first use. The team attempted to expose 1С documents directly via OData, but the resulting JSON payloads were 10–15 KB per object — too large for mobile networks.

Example: A typical Sales Document in 1С contains a header, a table of line items, VAT breakdowns, and audit fields. For a mobile picker app, only product code, quantity, and location are needed. Sending the full document wastes bandwidth and causes slow rendering on the mobile side.

Rake: The team initially built a generic OData endpoint that returned all fields. In production, the app crashed on low-end Android devices due to memory overflow when parsing large JSON arrays.

How they fixed it: They created dedicated “mobile views” — thin 1С reports that generate flat JSON arrays with only the required fields. These views are cached in Redis with a 60-second TTL, reducing load on 1С and speeding up responses. The mobile app never queries 1С directly; it always goes through a caching middleware.

4. Offline Sync Conflicts — The Silent Data Loser

One of the most dangerous rakes is the assumption that 1С can handle offline sync correctly out of the box. 1С has a built-in exchange mechanism for distributed infobases, but it is designed for scheduled batch sync, not real-time mobile conflict resolution. The team implemented a custom sync protocol where the mobile app sends changes made offline (while disconnected), and 1С applies them. The result was frequent data corruption.

Root cause: 1С uses optimistic locking with a “last writer wins” strategy at the record level. When two users modify the same document offline — one on the mobile, one on the desktop — the last sync overwrites the previous changes silently. The team discovered this only after a week of production use, when inventory counts became inaccurate.

Technical detail: The standard 1С exchange plan uses a reference timestamp for each object. If the mobile sends an object with a timestamp older than the current version, 1С still accepts it and overwrites the newer version. There is no built-in conflict detection.

Mitigation: The team implemented a three-way merge using a version vector stored in a separate 1С register. Each sync checks the version number. If a conflict is detected, the change is rejected and the mobile app receives a “conflict” response, forcing the user to manually resolve it. They also added a “sync journal” table that logs every change with a UUID to enable rollback.

Sample conflict resolution logic:

# Middleware pseudo-code
def sync_change(mobile_change):
    server_version = get_version(mobile_change.object_id)
    if mobile_change.version < server_version:
        return {"status": "conflict", "server_version": server_version}
    else:
        apply_to_1c(mobile_change)
        increment_version(mobile_change.object_id)
        return {"status": "ok"}

5. Debugging and Monitoring Blind Spots

The fifth rake is the near-total absence of standard monitoring tools for 1С HTTP services. Unlike modern backends (Node.js, Django, etc.) that integrate with Prometheus, Grafana, or DataDog, 1С provides only a performance measurement tool (the “Technological Journal”) that is file-based and hard to query in real time. The team could not correlate slow mobile requests with specific 1С operations.

Production incident: A sudden spike in response times from 200 ms to 15 seconds occurred at 10 AM daily. It took three days to trace the cause: a scheduled background job that recalculates inventory balances was locking the infobase during peak mobile usage. Without proper tracing, the team was debugging in the dark.

Solution: They built a simple middleware in Go that sits between the mobile app and 1С. This middleware logs every request with timestamps, response sizes, and response codes. It also exposes metrics via a /metrics endpoint that Prometheus scrapes. The team then set up alerts when the 95th percentile response time exceeds 2 seconds.

Monitoring stack they used:
- Middleware: Go HTTP proxy with structured logging (JSON)
- Metrics: Prometheus + Grafana dashboards
- Alerting: Alertmanager on response latency and error rate
- 1С side: Custom logging table that records each incoming HTTP request with a correlation ID passed from the middleware

Correlation ID flow:

Mobile -> Middleware (generates UUID) -> 1С HTTP service (logs UUID) -> Response -> Middleware logs UUID + latency

This enabled them to pinpoint that the background job was the culprit. They rescheduled it to run at 3 AM.

Conclusion

Deploying 1С as a mobile app backend is not a plug-and-play solution. The five rakes — REST throughput limits, session management overhead, data model rigidity, offline sync conflicts, and debugging blind spots — are invisible during development but become critical in production. The team’s experience shows that a successful architecture requires adding a middleware layer (for queuing, caching, token auth, and monitoring), building mobile-specific data views, and implementing custom conflict resolution. Without these, the “fast prototype” becomes a slow, unreliable production system. The full technical post is available at Source. For enterprises considering this path, investing in middleware and async processing is not optional — it is the difference between a working app and a constant firefighting mode.