What is USSD (and who cares)?

Werner Vogels writes a short thesis piece on systems/ussd (Unstructured Supplementary Service Data), the early-1990s GSM Technical Specification protocol that most Western engineers last touched when activating a SIM, and how Sub-Saharan African payment companies (systems/mpesa, Moniepoint, Mukuru, OPay) and IoT platforms (systems/koko-networks) use it as a production transactional frontend at scale. The post is not a deep-dive on any one system; it is an argument for concepts/appropriate-technology — picking technology that is suitable, not shiny, by working backwards from the customer's real constraints (feature phone, no data plan, 2G coverage) rather than from the builder's preferred stack.

Key takeaways

1. USSD is a stateful, session-based, menu-driven GSM protocol that works on any feature phone over 2G without a data plan. Flow: user dials a short code (e.g. *123#) → message traverses the mobile network → USSD gateway routes by short code → application server responds with a menu → user interacts in a session with short timeouts. No internet connection, no app install, hardware under $20. (Source: sources/2025-10-29-allthingsdistributed-what-is-ussd-and-who-cares)

2. USSD is a frontend at production scale, not a legacy shim. M-Pesa processed over $100 billion in 2024; Moniepoint handled 5.2 billion transactions worth $150 billion. These are Western- rival transaction volumes transacted through a pre-smartphone menu protocol.

3. M-Pesa handles 4,000 transactions per second with real-time ML fraud detection, with Safaricom on AWS. The simple user-facing USSD menu hides a sophisticated cloud architecture — the patterns/feature-phone-frontend shape: minimal protocol surface at the edge, sophisticated compute/ML/storage in the backend.

4. systems/koko-networks runs "Africa's largest deployment of IoT technology for consumer fuels": 700+ KOKOpoint bioethanol ATM-style stations, each connected to a cloud platform, streaming real-time inventory data and enabling demand forecasting. USSD/ feature-phone-tier UX is not only for payments; an IoT+cloud backend serves the same customer who has no smartphone. Constraints shape the frontend but not the backend.

5. Sub-Saharan Africa mobile infrastructure reality (2025, GSMA): 27% mobile internet penetration; 55% of users still on 3G; ~1/3 of connections will still be 3G in 2030. Feature-phone-era interfaces remain the correct primary UX for hundreds of millions of people — and will remain so for at least a decade.

6. Thesis: "The limitations of materials are honesty in design." (Calatrava quote in the post.) Constraints aren't obstacles to engineer around; they are the problem specification. The companies ingeniously reusing a 1990s menu protocol are not "stuck in the past" — they are working backwards from the customer, same doctrine Amazon uses in patterns/pr-faq-writing.

7. Invisibility as the highest compliment. Werner: "The best engineering blends into the background of everyday life. You don't think about driving your car or paying for groceries. No one writes headlines when someone sends money from Lagos to Kigali or uploads a file to S3." Invisibility-through-appropriateness is a design goal, not an accident — and links directly to S3's concepts/simplicity-vs-velocity framing, where simplicity is a property of the experience, not the API.

Architecture extracted

USSD protocol (GSM, 1990s)

Feature phone  -->  Mobile network  -->  USSD gateway  -->  App server
      *123# dialed                        (routes by        (stateful
                                          short code)        session,
                                                             short timeouts)
      <- menu ------ <- text ------------ <- response ------ <-

Properties: - Stateful session — per-user, per-dial; server maintains state for duration of the session. - Short timeouts — session expiry bounded, forcing fast decision-making at the app server. - 2G sufficient — no data plan, no TCP/IP at the edge. Runs on any GSM carrier. - Text-only menu UI — 182-char limit per message in the classical spec; enough for balance/transfer/top-up/pay workflows.

M-Pesa (payments)

• 4,000 TPS processed on AWS (Safaricom).
• ML-based real-time fraud detection in the transaction path.
• $100B+ annual volume (2024).
• USSD as primary user interface; backend is a modern cloud payment platform.

Moniepoint (payments)

• 5.2B transactions / $150B volume (2024 figures per Werner).
• Also uses USSD as primary channel.

KOKO Networks (bioethanol IoT)

• 700+ KOKOpoint stations — bioethanol ATMs for cooking fuel.
• Each station connected to a cloud platform.
• Real-time inventory data streamed from each station.
• Demand forecasting in the backend.
• Customer tops up from their phone — likely USSD or lightweight app, post doesn't specify the user channel for KOKO specifically.

Operational numbers

Quantity	Value
M-Pesa TPS	4,000
M-Pesa annual volume (2024)	> $100 billion
Moniepoint transactions (2024)	5.2 billion
Moniepoint volume (2024)	$150 billion
KOKO Networks connected fuel stations	700+
Sub-Saharan Africa mobile-internet penetration	27%
Sub-Saharan Africa users on 3G	55%
Sub-Saharan Africa connections still 3G in 2030	~1/3 (est, GSMA)
Minimum USSD-capable hardware cost	< $20 USD

Caveats

• This is a thesis post, not a deep-dive. Architectural detail on M-Pesa / Moniepoint / KOKO backends is limited to the numbers above. Specific services (which AWS primitives Safaricom uses, which ML framework, which IoT platform for KOKO) are not named.
• No production incidents, internal tooling details, or engineering process content — the lessons are at the doctrine level ("appropriate technology", "invisibility", "working backwards") not the operational level.
• Numbers quoted secondhand — Werner cites published figures from Safaricom, Moniepoint, KOKO; the post is not a primary architectural source for those systems. Treat the TPS/volume/station-count numbers as approximate rather than authoritative.
• USSD itself is a well-understood commodity protocol; the wiki page on it exists mostly as the anchor entity the named systems plug into, not as a distributed-systems design primitive to study.

Cross-references

• concepts/appropriate-technology — central thesis; suitability over sophistication; constraints are the specification.
• concepts/simplicity-vs-velocity — Warfield's S3 framing of simplicity as experience-property; Werner's "invisibility" doctrine is the same claim from the customer's side.
• patterns/feature-phone-frontend — minimal-protocol edge (USSD menu) + sophisticated cloud backend (ML, fraud, IoT, real-time); the architectural shape shared by M-Pesa / Moniepoint / KOKO.
• patterns/pr-faq-writing — "work backwards from the customer" doctrine explicitly called out in Werner's closing.
• systems/ussd, systems/mpesa, systems/koko-networks — entities introduced by this source.
• companies/allthingsdistributed — Tier 1 source blog.

Raw

Original post: What is USSD (and who cares)? Local mirror: raw/allthingsdistributed/2025-10-29-what-is-ussd-and-who-cares-2895eb5d.md