Note: When a company's staff exceeds 5,000 people, standard messengers become a bottleneck: data leaks, message delays, lack of offline sync. Without the right approach, a corporate messenger turns into a source of vulnerabilities and failures. We develop corporate messengers turnkey—from protocol to store publication. In one project for a retailer with 5,000+ employees, we processed 100+ messages per second with 99.9% uptime. Below are the technical solutions that underpin it. Investment in development pays off by reducing communication time by up to 40%.
What infrastructure does a corporate messenger require?
A corporate messenger is not just CRUD with WebSocket. It includes real-time transport, E2E encryption, push notifications, history storage, media sharing, and cross-device synchronization. Each of these components requires a separate approach. For example, for a group of 5,000 users with a peak load of 200 messages per second, an architecture with horizontal scaling and WebSocket connection balancing is necessary.
Which transport protocol to choose for a corporate messenger?
The choice of protocol determines scalability and maintenance complexity. WebSocket paired with a custom protocol gives full control but requires implementing reconnect, heartbeat, acknowledgement, and message queuing on connection loss. XMPP is a mature standard with ready-made servers (Ejabberd, OpenFire, Prosody) and libraries for iOS/Android. It provides presence, MUC, and OMEMO for encryption out of the box. Matrix is a more modern option with E2E by default and federation, but it's tightly coupled to a homeserver (Synapse). For corporate tasks, we most often choose WebSocket + custom backend (NestJS + Redis Pub/Sub + PostgreSQL). XMPP is justified when integrating with an existing XMPP infrastructure; Matrix if federation between organizations is needed. The key decision is made based on your IT landscape.
| Protocol | Scalability | Complexity | E2E by default | Federation |
|---|---|---|---|---|
| WebSocket + custom | High | High | No | No |
| XMPP | Medium | Medium | OMEMO | Yes |
| Matrix | Medium | Low | Yes | Yes |
How to implement E2E encryption in group chats?
Signal Protocol is the de facto standard for E2E. Used in Signal, WhatsApp, Skype. For mobile: libsignal-protocol-java (Android), SignalProtocolKit (iOS). The protocol is based on the Double Ratchet Algorithm: each message is encrypted with a new key; compromising one does not reveal the rest (forward secrecy).
Encryption implementation in Kotlin
// Encrypting an outgoing message val sessionCipher = SessionCipher(signalStore, recipientAddress) val encryptedMessage = sessionCipher.encrypt(plaintext.toByteArray()) val payload = Base64.encodeToString(encryptedMessage.serialize(), Base64.NO_WRAP) For groups—Sender Key Distribution: one key encrypts for all, more efficient than encrypting individually. Keys are stored only on the device. When the app is deleted, the history is lost—this is the trade-off. Solution: optional key backup via iCloud Keychain / Google Drive with user consent.
Step-by-step plan for E2E implementation:
- Choose the Signal Protocol library for each platform.
- Set up a server for storing encrypted messages and key management.
- Integrate encryption/decryption on clients.
- Conduct a key compromise test.
History storage and synchronization
Local database—Room (Android) / Core Data (iOS). Messages with fields: id, conversationId, senderId, encryptedContent, timestamp, status (sent/delivered/read). Resync on reinstall: if E2E without backup—history unavailable. With backup—paged loading via cursor-based pagination. Delivery and read statuses—via WebSocket ack. In offline mode, messages accumulate and are sent in batch.
Media and files
Upload via a separate HTTP endpoint. For images: first thumbnail (JPEG, 200px, quality 40), then original. Video—HLS or progressive download. Chunked upload with resume (S3 Multipart Upload). Progress via okhttp3.MultipartBody. Cache via Glide/Kingfisher with LRU eviction of old files.
Push notifications and badges
For a closed app—FCM (Android) / APNs (iOS). On iOS, UNNotificationServiceExtension decrypts E2E before display. On Android 13+, request POST_NOTIFICATIONS permission. Badge on iOS: UNUserNotificationCenter.setBadgeCount() (since iOS 16) or via push payload. On Android—ShortcutBadger (launcher-dependent).
Stages and timelines
| Stage | Content | Time |
|---|---|---|
| Design | Protocol architecture, E2E solution, DB | 2-3 weeks |
| Backend | WebSocket server, API, storage | parallel with client |
| iOS + Android | Real-time, UI, media, push | 10-14 weeks |
| E2E encryption | Signal Protocol or OMEMO | +3-4 weeks |
| Testing | Load testing (up to 10k users), real-time, edge cases | 2-3 weeks |
MVP without E2E (basic chats, push, history) — 3-4 months. Full version with E2E — 5-7 months. Cost is calculated individually.
What's included in the work
- Technical specification and architectural documentation
- Source code for iOS and Android with comments
- Integration with your IT infrastructure (SSO, API, corporate email)
- CI/CD setup and app store publication
- Administrator and user training
- 3-month warranty support
Checklist for readiness verification
- [ ] WebSocket connection in background on iOS and Android
- [ ] APNs and FCM certificates
- [ ] Penetration test on E2E
- [ ] History synchronization after reinstall
- [ ] Load testing with 5,000+ concurrent users
Our team has 10+ years of experience in mobile development and over 40 corporate projects. We use Signal Protocol for encryption and WebSocket API for real-time. Investment in development pays back on average in 12-18 months, and savings on operational costs can reach 40%. Request a consultation to assess your project—get a preliminary estimate in 2 days. Contact us to discuss the details of your corporate messenger.