USSD (Unstructured Supplementary Service Data) is one of the most practical ways to deliver digital healthcare services in places where smartphones, mobile data, and reliable internet access aren’t always readily available. Across Africa, it serves as the backbone for everyday healthcare interactions, booking appointments, receiving follow-ups, checking insurance eligibility, and completing basic health screenings on simple feature phones. From the user’s side, USSD feels straightforward, but behind the scenes, building systems that handle these interactions at scale is anything but simple. Sessions expire quickly, responses must be almost immediate, and the system has to deal with unreliable network behavior coming from telecom operators. A small architectural mistake can easily translate into dropped sessions, incomplete flows, or a system that works fine in testing but struggles when traffic increases. This article focuses on the architectural thinking behind building a high-volume USSD systems for healthcare scenarios, and the practical engineering patterns that make these systems more resilient and easier to maintain in production. Understanding the Core Constraints of USSD Before discussing architecture, it’s important to understand the constraints that shape every technical decision in USSD systems: Session-based interactions:  USSD sessions are stateful but short-lived, often expiring within seconds if responses are delayed.
Strict latency requirements:  Any delay in backend responses can terminate an active session.
High concurrency:  National or regional rollouts can result in tens or hundreds of thousands of concurrent sessions.
Unreliable networks:  Network interruptions, retries, and duplicate requests are common.
No client-side persistence: Feature phones do not store application state, so every piece of session data must be tracked on the server side. Session-based interactions:  USSD sessions are stateful but short-lived, often expiring within seconds if responses are delayed. Session-based interactions Strict latency requirements:  Any delay in backend responses can terminate an active session. Strict latency requirements High concurrency:  National or regional rollouts can result in tens or hundreds of thousands of concurrent sessions. High concurrency Unreliable networks:  Network interruptions, retries, and duplicate requests are common. Unreliable networks No client-side persistence: Feature phones do not store application state, so every piece of session data must be tracked on the server side. No client-side persistence These constraints demand an architecture that prioritizes speed, fault tolerance, and horizontal scalability rather than traditional synchronous request-response patterns. High-Level Architecture Overview At a high level, the system is composed of: USSD Gateway Layer
Flow Orchestration Layer
Application Backend
Session Manager
Event & State Layer
Observability & Error Tracking USSD Gateway Layer USSD Gateway Layer Flow Orchestration Layer Flow Orchestration Layer Application Backend Application Backend Session Manager Session Manager Event & State Layer Event & State Layer Observability & Error Tracking Observability & Error Tracking Each component has a clearly defined responsibility. This prevents tight coupling and allows different layers of the system to scale independently. USSD Gateway Layer The gateway acts as the entry point into the system. It manages session lifecycle events, translates telecom protocols into something the backend can understand, and sends responses back to the user. From an architectural standpoint, the backend never assumes delivery guarantees from the gateway. Every request is treated as potentially duplicated, delayed, or retried. This assumption drives downstream design decisions such as: Idempotent handlers
Session reconciliation
Defensive state management Idempotent handlers Session reconciliation Defensive state management Flow Orchestration Layer In scalable USSD platforms, interaction flows should not be tightly coupled to backend application logic. Instead of hard-coding menus and decision paths directly into services, a dedicated flow orchestration layer is introduced to manage user interaction sequencing. flow orchestration layer The orchestration engine is responsible for: Service selection
Question and menu sequencing
Conditional branching and navigation
Input validation and session progression
Overall control of the user journey Service selection Question and menu sequencing Conditional branching and navigation Input validation and session progression Overall control of the user journey Separating interaction flows from backend business logic becomes increasingly important as deployments grow in size and complexity. This architectural boundary allows product and operations teams to modify user journeys without requiring changes to core application services. It also prevents complex backend processes from introducing latency into active USSD sessions. When backend processing or data persistence is required, the orchestration layer emits events to downstream services asynchronously rather than performing blocking synchronous calls during the USSD session. This design approach delivers several operational benefits: Faster USSD response times
Minimal synchronous dependencies during sessions
Reduced coupling between interaction flows and backend services
Improved system maintainability and operational flexibility Faster USSD response times Minimal synchronous dependencies during sessions Reduced coupling between interaction flows and backend services Improved system maintainability and operational flexibility While this separation introduces additional architectural components, the long-term gains in scalability, reliability, and maintainability typically outweigh the added complexity in high-volume USSD environments. Event & State Layer One of the most effective ways to keep USSD systems responsive is to avoid performing heavy business logic during active sessions. Instead, user interactions can trigger asynchronous events that downstream services process independently. In this model, the system publishes interaction events to a messaging layer. Multiple domain services subscribe and process them. Shared state is updated asynchronously while the user receives a minimal response that keeps the session alive. Different technologies can support this approach. Some teams use in-memory messaging layers for speed, while others rely on distributed queues or streaming platforms. Each option has trade-offs around durability, ordering guarantees, and operational complexity. Despite these trade-offs, event-driven processing makes it easier to scale horizontally and prevents individual services from becoming bottlenecks. Backend Services Backend services are designed to be stateless and horizontally scalable: No session data is stored in memory
All session state is persisted externally in Redis
Handlers are idempotent to safely process duplicate events
Timeouts are handled explicitly No session data is stored in memory All session state is persisted externally in Redis Handlers are idempotent to safely process duplicate events Timeouts are handled explicitly This makes it possible to: Scale services during traffic spikes
Redeploy or replace instances without losing session continuity
Reliably handle millions of USSD interactions Scale services during traffic spikes Redeploy or replace instances without losing session continuity Reliably handle millions of USSD interactions Handling Scale, Timeouts, and Failures Session Timeouts USSD sessions frequently expire mid-flow. To handle this: Partial progress is saved in Redis after each interaction
Users can resume from their last completed step
Backend logic tolerates incomplete or missing data Partial progress is saved in Redis after each interaction Users can resume from their last completed step Backend logic tolerates incomplete or missing data High Concurrency Redis Pub/Sub allows the system to process thousands of concurrent events with minimal overhead, while backend consumers scale horizontally based on demand. Fault Isolation Failures in one downstream service (for example, appointment booking) do not collapse the entire flow. The flow orchestrator continues managing the session while backend services retry or flag failures asynchronously. Observability & Error Tracking In distributed, high-volume systems, failures are inevitable. What matters is how quickly they are detected and diagnosed. This is why Engineers need visibility into latency trends, session drop rates, and asynchronous processing failures. Structured logging helps trace issues across distributed services. Distributed tracing allows teams to follow a user interaction through multiple asynchronous boundaries. Real-time alerts provide early warnings when performance starts to degrade. This makes it possible to trace failures across asynchronous boundaries, identify systemic issues early, and improve reliability over time. Why This Architecture Scales This architecture scales by combining: Asynchronous, event-driven processing
Stateless backend services
Loosely coupled flow orchestration
Explicit failure and retry handling
Built-in operational visibility Asynchronous, event-driven processing Stateless backend services Loosely coupled flow orchestration Explicit failure and retry handling Built-in operational visibility Rather than treating USSD as a simple menu-driven channel, it is approached as a distributed systems problem, subject to the same rigor as high volume web or fintech platforms. Closing Thoughts USSD continues to play an important role in expanding access to healthcare services in low-connectivity regions. Building reliable platforms for this channel requires more than basic menu design. It involves thoughtful system architecture, careful handling of session state, and a realistic understanding of telecom infrastructure constraints. The patterns described here are technology-agnostic and can be implemented with different tools depending on team preferences and operational context. What matters most is designing systems that remain responsive under load and continue working even when networks behave unpredictably. In many ways, USSD reminds engineers that impactful technology is not always about cutting-edge tools. Sometimes it is about building dependable systems that meet people where they are and continue working under real-world conditions.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

USSD at Scale: Powering Healthcare Access Across Africa

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

AI Assistants Can Quietly Kill Skill Growth

MCP Explained: The Protocol That Unblocked Real AI Agent Ecosystems

Meet UGLA ERP, Runner-up of the Startups of the Year in Kyiv.

10 Steps To Digital Transformation While Simultaneously Cutting Costs

5 Books You Can Read to Boost Your Computer Science Knowledge

The System Design Cheat Sheet: Cache

AI Assistants Can Quietly Kill Skill Growth

MCP Explained: The Protocol That Unblocked Real AI Agent Ecosystems

Meet UGLA ERP, Runner-up of the Startups of the Year in Kyiv.

10 Steps To Digital Transformation While Simultaneously Cutting Costs

5 Books You Can Read to Boost Your Computer Science Knowledge

The System Design Cheat Sheet: Cache

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps