Message Queue Setup (RabbitMQ/Kafka) for Mobile Applications
When a mobile client sends a purchase request, it shouldn't wait while the server processes payment, updates inventory, credits bonuses, sends emails and push notifications. Message queues break this synchronous chain—the HTTP handler records a task and immediately responds 202 Accepted.
RabbitMQ or Kafka—How to Choose
There's no need to declare one "better"—they solve different problems.
RabbitMQ—message broker with routing, priorities, and dead-letter queues. Task: "execute something once" (send email, transcode video, update database record). Consumer acknowledges processing (basic.ack)—message is deleted. Simple operational model, Management UI included.
Kafka—distributed event log. Task: "store event stream for multiple consumers, with replay capability." user.registered—subscribed by analytics, email, and CRM services. Each reads independently at its own offset. On error—replay from the right position. RabbitMQ cannot do this.
| Criterion | RabbitMQ | Kafka |
|---|---|---|
| Execute task once | Yes | Awkward |
| Multiple independent consumers | Via Fanout Exchange | Native (consumer groups) |
| Event replay | No | Yes (retention period) |
| Message ordering | Within single queue | Within single partition |
| Operational complexity | Low | High (ZooKeeper / KRaft) |
Configuration for Typical Mobile Apps
Push notifications via RabbitMQ. HTTP handler publishes {user_id, title, body, data} to push.notifications queue. Workers (parallel instances) consume, send via FCM/APNs. Dead-letter queue push.notifications.failed—for messages that fail after N retries. Periodic job analyzes DLQ and retries or logs.
Critical: set prefetch_count = 1 for workers making HTTP calls (FCM, APNs). Without this, RabbitMQ delivers 250 messages at once; the worker hits Firebase rate limits and hangs while messages wait unacknowledged.
Kafka for event streaming. Example: tracking user actions in mobile app. Every tap, scroll, screen view—events in mobile.user.events topic. Consumers: real-time dashboard (Flink), hourly batch (Spark), A/B testing service. Retention: 7 days. Partitions: 24 (matching peak worker count). Partition key: user_id, ensuring one user's events stay ordered in one partition.
Real case: marketplace with mobile app, 60,000 orders daily. Synchronous order processing took 1.2 seconds: inventory check, reservation, cashback credit, email + push. Users waited. After implementing RabbitMQ: HTTP handler writes order to PostgreSQL and publishes order.created—response in 80ms. Workers asynchronously handle the rest. Users receive push in 3–5 seconds instead of staring at a spinner.
Idempotency—Mandatory Requirement
Brokers don't guarantee "exactly once" in general. RabbitMQ with "at-least-once" delivery means a consumer might receive a message twice on reconnect. Consumers must be idempotent: reprocessing doesn't create duplicates. Method: unique message_id in database, INSERT ... ON CONFLICT DO NOTHING.
Timeline: RabbitMQ for push + basic tasks—3–5 days. Kafka cluster with monitoring, Schema Registry, consumer groups for multiple services—2–3 weeks.