National Gas Service Monitoring
National Gas Service Monitoring & Call Center System (104)
Our team developed a nationwide monitoring and call-center solution for the Gas Emergency Service 104, designed to streamline communication, accelerate response times, and ensure reliable service delivery at scale.
Key Features
- VoIP Call Handling – Operators receive emergency calls directly through integrated VoIP telephony.
- Automated Case Creation – Incoming calls instantly generate database records, automatically filling in caller details.
- Rapid Response Management – Dispatch and control emergency teams via dynamic forms and an interactive live map.
- Route Optimization – Build and assign efficient travel routes for faster arrival.
- Realtime Team Tracking – Monitor brigade locations and activity in real time across the entire country.
- Responsibility Zones – Link teams directly to their assigned regions for structured coverage.
- Enterprise Inventory Management – Maintain equipment and resources in a centralized system.
- Extensive Reference Catalogs – Cities, streets, teams, districts, responsibility zones, vehicles, event classifiers, and more for quick and accurate data input.
- Analytics & Reports – Visual dashboards and diagrams for decision-making: response times, arrival delays, ticket closure efficiency, and pre-event factors to optimize workflows.
Why It Matters
In a service where seconds save lives and property, the system delivers transparency, speed, and accountability. From the moment a call is received to the deployment of a rapid-response brigade, every process is tracked, optimized, and analyzed. This nationwide solution empowers the Gas Service 104 to operate at maximum efficiency while ensuring safety for millions of citizens.
Architecture
MVP STAGE
Introduction
In the context of digital transformation, it is extremely important to implement reliable, scalable, and integrated customer support systems, especially for critical infrastructures such as emergency dispatch services.
The Mont Blanc pilot project, developed by the GreenLight-CS team, aims to create an innovative solution combining a modern CRM platform with flexible microservice architecture and deep integration with the CallWay telecommunication system.
This document presents the technical vision, architectural solutions, and practical implementation of a CRM system adapted to the needs of emergency dispatch services. It describes the microservice structure, usage scenarios, load testing results, and scaling recommendations, allowing assessment of the system’s readiness for real-world deployment.
Architecture
The application architecture is built on decomposition into autonomous subsystems as microservices packaged in containers. Each microservice:
- Implements a set of cohesive functions.
- Interacts with others via HTTP (REST), gRPC, or asynchronously via AMQP.
- Is deployed independently in Docker containers.
- Has its own database, ensuring isolation and independence.
Client apps (Web/Mobile) communicate through a single API Gateway, which routes requests to services.
Project Description
The system is deployed on Kubernetes, ensuring flexibility, fault tolerance, and horizontal scaling.
- Interaction: services exchange events via a data bus (RabbitMQ).
- Security: access is controlled via OAuth 2.0 & OpenID Connect at the API Gateway.
- Isolation: each service stores its own data.
- Monitoring & Logging are included.
- CI/CD pipelines automate updates.
This architecture provides scalability, modularity, fault tolerance, and adaptability for emergency systems.
Overview of Microservices
Core microservices include:
- ClientArea: central client data directory (contacts, addresses, coordinates, employees).
- Teams: manages emergency crews (composition, zones, status, schedules).
- Orders: lifecycle of requests (creation → completion, assignment, analytics).
- Audit: logs critical actions (auth, API calls, data changes).
- Dictionaries: reference data (types, categories, statuses, refusal reasons).
- Identity: authentication/authorization with OAuth2 + OIDC, JWT tokens.
- Integrations: manages external system connections (e.g., CallWay telephony via WebSockets & SignalR push events).
This setup enables automation of call processing and quick operator response.
Frontend Platform
The frontend is built using
micro frontends, allowing modular UI components to be developed independently.
Key features:
- Isolation of UI modules.
- Dynamic loading of components.
- Unified backend interactions (Command pattern).
- Flexible design theming without affecting logic.
- Event-driven communication between UI modules.
For the pilot, UI design was minimal (MVP) — the focus was stable integration with CallWay.
Request Window Interface
The request form includes:
- Contact Info (phone, name, anonymity option).
- Incident Card (category, type, priority, description, source).
- Address (detailed with coordinates).
- Map (interactive, auto-updates with address).
- Previous Requests (history by client/address).
Use Cases
- UC-001: Registering a request via phone call
- Triggered by incoming CallWay call.
- Auto-fills phone, pulls client history, links call recording.
- UC-002: Registering a request manually
- Operator creates without phone call.
- Supports anonymous or known clients.
- UC-003: Viewing an existing request
- Allows playback of call recordings, browsing history, restricted by user roles.
Load Testing
Tests simulated real-world emergency workloads.
- Hardware: 2 servers (4 cores @ 3.2GHz, 8GB RAM, Kubernetes + Docker, RabbitMQ, MS SQL).
- Scenarios: request creation via Orders.API with ClientArea + RabbitMQ.
Results
- 100 requests → 122 req/sec, avg 77 ms.
- 10,000 requests → 259 req/sec, avg 377 ms.
- 40,000 requests → 175 req/sec, avg 1126 ms.
- 100,000 requests → 221 req/sec, avg 449 ms.
- Errors: 0 in all cases.
Conclusions & Recommendations
- The system reliably processes >220 requests/sec without errors.
- For emergencies (e.g., earthquakes, floods), a country of 30M people → ~300k requests/hour (~83/sec).
- Current architecture already exceeds requirements.
Recommendations
- Scale RabbitMQ with HA configuration.
- Separate databases by services.
- Add caching for static data.
- Optimize message payloads.
- Add monitoring for RabbitMQ & DB.
- Include load testing in CI/CD.
Other projects
