DEV Community

Cover image for Building Namma Push: The Open‑Source, Pure‑Rust Alternative to Firebase Cloud Messaging
Black Lover
Black Lover

Posted on

Building Namma Push: The Open‑Source, Pure‑Rust Alternative to Firebase Cloud Messaging

#grpc #rust #webdev #programming

📱 The Push Notification Problem

Every modern app needs to send push notifications. Whether it’s a ride‑hailing service alerting a driver of a new trip, a fintech app confirming a payment, or a messaging app delivering a chat message — notifications are critical.

The industry standard is Firebase Cloud Messaging (FCM) from Google. It’s easy to set up, works across platforms, and is free for moderate usage. But as your app grows, FCM’s limitations become painful:

  • Data privacy — Google sees who you’re messaging and when.
  • Cost — At scale, FCM can cost $50–100 per million notifications.
  • Latency — 200–2000ms is common, especially for cross‑platform messages.
  • Lock‑in — Your entire notification infrastructure is tied to Google’s ecosystem.
  • No direct Android connection — FCM goes through Google Play Services, which doesn’t work on devices without Google (e.g., in China).

And on iOS, FCM is just a wrapper around Apple’s APNs, adding another hop and more latency.

What if you could have full control over your notification infrastructure? What if you could deploy your own push server, connect directly to devices, and achieve sub‑10ms latency — all while keeping your data private and reducing costs by 70%?

That’s exactly what we built with Namma Push.

🚀 What Is Namma Push?

Namma Push is an open‑source, self‑hosted push notification platform written entirely in Rust. It replaces FCM and APNs with a unified, high‑performance system that you run on your own infrastructure.

Key capabilities:

  • Direct gRPC/QUIC connections to mobile, web, desktop, and IoT devices — no third‑party intermediary.
  • Sub‑50ms P99 latency for active clients (often sub‑10ms).
  • WhatsApp‑style wake‑up — optional FCM/APNs messages to wake apps that are killed, while the actual notification content stays private.
  • Horizontal scalability — from 10,000 to millions of concurrent connections using Redis Cluster.
  • One Rust core — shared code for all client SDKs (iOS, Android, Web, Desktop, IoT).
  • Full observability — Prometheus, Grafana, Jaeger, Loki included.
  • Multi‑tenant — host many applications on a single cluster with isolated rate limits and API keys.
  • Cost‑efficient — self‑hosted, pay only for your own infrastructure (70%+ savings compared to FCM).

🏗️ Architecture Overview

Namma Push is designed as a cloud‑native, horizontally scalable system. Here’s a high‑level view:

┌─────────────────────────────────────────────────────────────┐
│                  Producer Applications                       │
│          (gRPC / REST with API Key)                         │
└─────────────────────────────┬───────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│           Namma Push Gateway (Rust / tonic)                 │
│   • gRPC server (port 50051)                                │
│   • QUIC/HTTP3 (port 50052)                                 │
│   • REST Admin API (port 9090)                              │
│   • Tenant validation, rate limiting, consistent hashing   │
└─────────────────────────────┬───────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                   Redis Cluster (Shared State)              │
│   • Priority streams (CRITICAL / HIGH / NORMAL / LOW)      │
│   • Dead Letter Queue (DLQ)  • Wake‑Up Queue                │
│   • Presence store (active connections)                     │
└─────────────────────────────┬───────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│               Delivery Orchestrator (Rust Workers)          │
│   • Per‑shard readers                                       │
│   • Client presence check                                   │
│   • Platform‑specific delivery (APNs, WebPush, MQTT)       │
│   • Exponential backoff retries                             │
└─────────────────────────────┬───────────────────────────────┘
                              │
    ┌─────────────────────────┼─────────────────────────┐
    ▼                         ▼                         ▼
┌───────────┐           ┌───────────┐           ┌───────────┐
│ iOS SDK   │           │ Android   │           │ Web SDK   │
│ (Swift +  │           │ (Kotlin + │           │ (WASM/JS) │
│  Rust)    │           │  Rust)    │           │           │
└───────────┘           └───────────┘           └───────────┘
Enter fullscreen mode Exit fullscreen mode

🔌 The Magic: One Rust Core for All Platforms

The heart of Namma Push is a single Rust library that handles:

  • gRPC/QUIC connections with automatic reconnection
  • Local storage of pending notifications (SQLite on mobile, IndexedDB on web)
  • Message queuing and delivery
  • Heartbeat management

This core is then wrapped for each platform:

  • Android: JNI bindings + Kotlin foreground service
  • iOS / macOS: C‑bridge + Swift (APNs token registration)
  • Web: WebAssembly (wasm-bindgen) + JavaScript service worker
  • Desktop: Native Rust (Tauri) or Electron
  • IoT: no_std Rust with MQTT or CoAP

Benefits of this approach:

  • Code reuse — the same networking and logic works everywhere.
  • Performance — Rust’s zero‑cost abstractions and memory safety.
  • Portability — the core runs on servers, browsers, and microcontrollers.

📱 Android: Google‑Free Forever

One of the most exciting aspects of Namma Push is its Android implementation — it works completely without Google Play Services or FCM.

How It Works

  1. The Android SDK contains a foreground service with START_STICKY flag.
  2. This service maintains a persistent gRPC/QUIC connection to your Namma Push server.
  3. When the app is in the background or even swiped away, the service continues running (Android shows a persistent notification, which can be hidden on Android 14+).
  4. An AlarmManager health check restarts the service if it’s killed by aggressive battery optimisations.
  5. Notifications are delivered instantly over the gRPC connection.

No FCM, no Google Play Services required. Works on any Android device, even in China.

If you want an extra layer of reliability, you can optionally enable FCM as a wake‑up helper — but it’s not needed for most use cases.

📱 iOS: Leveraging APNs Without Sacrificing Privacy

iOS is more restrictive: Apple does not allow long‑running background services. To wake an app that is killed, you must use APNs. But we use APNs only as a wake‑up channel — not to deliver the actual notification.

  1. The iOS SDK registers for remote notifications and sends the device token to your Namma Push server.
  2. When your server detects that the client is offline, it sends a silent APNs push (content-available: 1) with no user‑visible payload.
  3. The device receives this push, wakes the app (if allowed), and the app reconnects via gRPC to fetch pending notifications.
  4. All notification content stays on your server — Apple never sees the title, body, or data.

This gives you the reliability of APNs for wake‑up while keeping your data private.

🌐 Web Push: Native, No FCM Required

For web browsers, Namma Push uses the W3C Web Push Protocol with VAPID authentication — the same technology used by Chrome, Firefox, Edge, and Safari. No FCM, no external service.

  • The server generates its own VAPID keys.
  • The Web SDK (Rust compiled to WebAssembly) subscribes to push using those keys.
  • Notifications are sent directly from your server to the browser’s push service.

This is fully self‑contained and respects user privacy.

🧠 Smart Delivery & Offline Handling

Namma Push is not just a dumb relay — it’s intelligent about delivery.

  • Priority queues — CRITICAL, HIGH, NORMAL, LOW. Critical notifications bypass queues for immediate delivery.
  • Dead Letter Queue (DLQ) — Failed deliveries are stored with exponential backoff retries (1s, 2s, 4s, …). After 5 failures, they stay in the DLQ for manual inspection.
  • Wake‑up queues — Offline clients get a pending notification queue that is replayed as soon as they reconnect.
  • Local caching — SDKs store notifications locally (SQLite on mobile, IndexedDB on web) so they survive disconnections.

This ensures at‑least‑once delivery with minimal data loss.

📊 Performance & Scale

We built Namma Push to handle millions of devices. Here are the numbers from our benchmarks:

Metric Single Node Cluster (3 gateways + 6 Redis shards)
Concurrent connections 10,000 500,000+
Throughput (TPS) 1,000 50,000+
P99 latency (online client) <50ms <50ms
P99 latency (wake‑up via FCM/APNs) – <2s
Availability – 99.99% (multi‑AZ)

Horizontal scaling is trivial — just add more gateways and Redis shards.

🛠️ Observability Out of the Box

We believe in “you build it, you run it”. Namma Push includes a full observability stack:

  • Prometheus metrics: active connections, delivery latency, queue sizes, error rates, per‑tenant usage.
  • Grafana dashboards pre‑built for operations and business metrics.
  • OpenTelemetry + Jaeger for distributed tracing.
  • Loki for log aggregation.

All components are open source and run alongside your Namma Push deployment.

🔒 Security & Compliance

Because you host it yourself, you control the security:

  • TLS 1.3 for all external endpoints.
  • mTLS for internal service communication.
  • API keys (JWT) for backend authentication.
  • RBAC for admin UI (viewer, operator, admin).
  • Audit logs of all admin actions.
  • Designed to support GDPR (right to erasure), HIPAA (audit trails), and PCI‑DSS (segmentation).

No third party sees your notification metadata unless you explicitly choose to use FCM/APNs as optional fallbacks.

💸 Cost Comparison

Let’s run some numbers. Suppose you send 100 million notifications per month:

  • FCM (or similar managed service): $5,000–10,000 per month (or “free” but with quotas and limited analytics).
  • Namma Push self‑hosted on AWS (3 gateways + 6 Redis shards): ~$4,800 per month including all infrastructure.
  • Savings: $200–5,200 per month, or $2,400–62,400 per year.

And that’s without counting the value of having your own data, lower latency, and no lock‑in.

🚀 Roadmap & Getting Involved

Namma Push is currently in active development, following a 16‑week roadmap to a stable v1.0 release:

  • Phase 1 (Weeks 1‑5): Core engine — gRPC, Redis streams, basic delivery.
  • Phase 2 (Weeks 6‑10): Production features — FCM/APNs fallback, DLQ, Redis cluster, QUIC.
  • Phase 3 (Weeks 11‑14): Observability — Grafana, Jaeger, load testing, security hardening.
  • Phase 4 (Weeks 15‑16): UI & documentation — Vue.js admin UI, deployment guides, SDK examples.

We’re building this in the open. The code is on GitHub (coming soon), and we welcome contributions. Whether you’re a Rust developer, a mobile engineer, or just curious, there’s a place for you.

🎯 Why Namma Push Matters

Push notifications are the lifeblood of modern apps, yet we’ve been dependent on a handful of proprietary services. Namma Push changes that. It gives you:

  • Full control — your infrastructure, your data.
  • Superior performance — sub‑50ms latency, no third‑party hops.
  • Lower costs — self‑hosted, pay only for what you use.
  • Privacy by design — no one sees your users’ data.
  • Open source — inspect, modify, and contribute.

We believe every organisation deserves a notification platform that respects its sovereignty. Namma Push is our answer.

📚 Try It Yourself

You can run Namma Push today (pre‑release) with Docker:

docker run -d -p 50051:50051 -p 9090:9090 nammayatri/namma-push:latest
Enter fullscreen mode Exit fullscreen mode

Then visit http://localhost:9090 to create your first tenant and get an API key. Integrate our SDKs (coming soon) and start sending notifications.

Together, we can make Namma Push the go‑to choice for developers who value control, privacy, and performance.

Namma Push — open source, self‑hosted, and ready for the world. 🚀

Top comments (0)