Calling backend
- LiveKit / WebRTC
- IVR & call queues
- WebSocket / STOMP
Core backend
- Users & tenants
- Roles & presence
- CRM & HR
- Oracle · persistence
- RabbitMQ · events
- Redis · hot-path data
Problem and requirements
CallX connects live conversations with the organizational workflows behind them. The documented scope includes tenants, agent presence, IVR, DTMF, queues, CRM, and HR. Keeping a call responsive and keeping a customer record correct are related goals, but they involve different workloads. The platform is in active development; this case study describes the implemented scope rather than a finished production rollout.
Calling backend and media
I built the calling backend with Spring Boot, LiveKit, WebRTC, and WebSocket/STOMP. It covers IVR flows, DTMF handling, and live queues; Firebase Cloud Messaging notifies offline agents. A Python LiveKit Agent worker integrates ElevenLabs text-to-speech. The distinction between media transport, application signaling, and offline notification makes each responsibility visible in the architecture.
Core backend and customer context
The core backend manages users, tenants, roles, presence, CRM, and HR. CRM capabilities include customers, contacts, campaigns, pipelines, leads, opportunities, and interactions. Automatic call logging connects conversations to customer timelines, so call activity becomes part of the business record rather than remaining isolated in the calling system.
Persistence, events, and hot-path data
Oracle provides persistence, RabbitMQ carries asynchronous events, and Redis supports hot-path data. The two backends communicate through a shared service-token contract. This design separates responsibilities without removing the need for clear cross-service contracts. LDAP/Active Directory, SAML 2.0, OAuth 2.0/OIDC, SaaS, and self-hosted deployment patterns are documented in the project work.
Failure handling: review boundaries
A useful review of this architecture asks what happens when an agent disconnects, a notification arrives late, or a business event is repeated. Media reconnection, durable call records, and presence reconciliation need separate acceptance criteria. These are engineering review scenarios; the available project record does not establish measured recovery times or a specific retry policy.
Delivered capability and design takeaway
The documented result is a platform that combines real-time calling, organizational management, and CRM call history in separate cooperating services. The architectural takeaway is to give latency-sensitive communication and durable business operations explicit boundaries. No throughput, availability, or response-time figures are claimed here.