Why FCM doesn’t work for 1–1 Chat? (and What Actually Works)

When I first thought about building a chat feature, my instinct was simple:

“Why not just use Firebase Cloud Messaging (FCM) to send messages between users?”

It sounds right. It’s reliable, easy to integrate, and works even when the app is closed.

But once I dug deeper — and thought through real-world scenarios — I realized:

FCM is not a chat system. It’s a notification system.

That distinction changes everything.

Where FCM Falls Short

FCM works great for:

• Notifications
• Alerts
• Background updates

But chat apps need something more:

• Instant delivery
• Ordered messages
• Delivery & read guarantees
• Two-way communication

FCM doesn’t give you these reliably.

That’s why apps like WhatsApp don’t depend on it for actual messaging.

The Mental Shift That Helped Me

I started thinking of things this way:

• WebSocket = Real conversation
• FCM = Doorbell
• Database = Source of truth

That’s when everything clicked.

What Actually Happens in a Real Chat System

Here’s the simplified flow I now rely on:

If the receiver is online

• Message goes via WebSocket
• Delivered instantly

If the receiver is offline

1. Message is sent to server
2. Stored safely in database
3. Receiver is detected as offline
4. FCM sends a notification
5. User opens the app
6. App fetches messages from server
7. Message marked delivered/read

Key insight: The message is never delivered by FCM. It is always fetched from the server.

The Mistake I Almost Made

At one point, I considered sending full chat messages through FCM.

That would have caused:

• Out-of-order messages
• Missed deliveries
• Inconsistent chat state

Not something you want users to experience.

Final Architecture That Makes Sense

A reliable 1–1 chat system looks like this:

• WebSocket → Real-time messaging
• FCM → Notification trigger
• Backend DB → Single source of truth

Simple. Scalable. Predictable.

Closing Thought

If you’re building chat, remember this:

FCM tells the user something happened. Your backend is what actually makes it happen.

Once you internalize that, your system design becomes a lot clearer — and a lot more reliable.