Why Users Who DM Each Other Are 4x More Likely to Come Back — And What That Means for Your Architecture

If you're building a social app, there's a retention stat worth internalizing before you write a single line of feed-ranking code: users who DM each other are reportedly about 4x more likely to return daily than users who don't. That number comes from industry analysis of social app engagement patterns, and while any single stat like this deserves some skepticism about methodology, it lines up with what most social products discover the hard way — the feed gets people in the door, but private messaging is what makes them stay.

This has a real architectural implication that a lot of early-stage social apps miss: DMs aren't a nice-to-have bolted onto a content platform. If retention data says messaging drives return visits, then your real-time messaging layer deserves the same architectural seriousness as your feed — not a rushed implementation shipped after the "core" product is done.

Here's what building that layer properly actually involves.

Why DMs are architecturally harder than they look

On paper, direct messaging looks simple: user A sends a message, user B receives it. In practice, a production-grade DM system has to handle:

Real-time delivery to online users
Reliable delivery to offline users (queued, delivered on reconnect)
Read receipts and typing indicators
Horizontal scaling across multiple server instances
Media attachments
Message ordering and idempotency (no duplicates on reconnect/retry)

Each of these is a small feature individually, but together they turn "just send a message" into a distributed systems problem.

The core pattern: WebSockets + a pub/sub layer

A single WebSocket server can hold persistent connections to your users, but the moment you run more than one server instance — which you will, the second you need to scale past a single box — you hit a fundamental problem: user A's connection lives on server 1, user B's connection lives on server 2. Server 1 has no direct way to push a message to a socket held by server 2.

The standard fix is a pub/sub layer sitting between your WebSocket servers, most commonly Redis Pub/Sub:

// server.js (simplified)
const io = require('socket.io')(httpServer);
const redis = require('ioredis');

const pub = new redis();
const sub = new redis();

sub.subscribe('dm-channel');

// When a message arrives from Redis, broadcast to any
// locally-connected socket for the recipient
sub.on('message', (channel, payload) => {
  const { recipientId, message } = JSON.parse(payload);
  io.to(recipientId).emit('new_message', message);
});

// When a user sends a DM
io.on('connection', (socket) => {
  socket.on('send_message', async (data) => {
    const message = await persistMessage(data); // write to DB first
    pub.publish('dm-channel', JSON.stringify({
      recipientId: data.recipientId,
      message,
    }));
  });
});

Every server instance subscribes to the same Redis channel, so it doesn't matter which server holds the recipient's socket connection — the message gets fanned out to all instances, and whichever one has that user connected delivers it. This is the pattern behind most production Socket.io deployments at scale, and it's the first thing to get right before adding any of the features below.

Handling offline delivery

Pub/sub solves the case where both users are online. It does nothing for the far more common case: the recipient isn't connected right now.

The fix is straightforward but easy to skip under deadline pressure — persist before you publish, never the other way around:

async function sendMessage(senderId, recipientId, content) {
  // 1. Write to durable storage FIRST
  const message = await db.messages.create({
    senderId, recipientId, content,
    status: 'sent',
    createdAt: new Date(),
  });

  // 2. Then attempt real-time delivery
  const delivered = await tryRealtimeDelivery(recipientId, message);

  if (!delivered) {
    // 3. Fall back to push notification
    await sendPushNotification(recipientId, message);
  }

  return message;
}

When the recipient reconnects, they fetch undelivered messages from the database rather than relying on having "missed" a real-time event — the real-time layer is an optimization on top of durable storage, not a replacement for it. This ordering matters: teams that build the real-time path first and treat persistence as an afterthought tend to lose messages under load or during deploys.

Read receipts and typing indicators without melting your server

These features feel small but generate a surprising amount of traffic if implemented naively — a typing indicator sent on every keystroke, for a group chat with 50 members, gets expensive fast.

Two practical fixes:

Debounce typing events client-side, and only re-broadcast if state actually changed:

let typingTimeout;
input.addEventListener('input', () => {
  if (!isTyping) {
    socket.emit('typing_start', { chatId });
    isTyping = true;
  }
  clearTimeout(typingTimeout);
  typingTimeout = setTimeout(() => {
    socket.emit('typing_stop', { chatId });
    isTyping = false;
  }, 2000);
});

Batch read receipts rather than firing one event per message read — mark a conversation "read up to message X" instead of acknowledging every individual message, which cuts an O(n) stream of receipt events down to a single state update per read session.

Idempotency: the bug that shows up only under load

WebSocket reconnects are inevitable — flaky mobile networks, app backgrounding, server restarts during deploys. If your client retries a "send message" call after a dropped connection without an idempotency key, you'll eventually ship duplicate messages to production, usually discovered by an annoyed beta user rather than in testing.

The fix is a client-generated idempotency key on every send:

socket.emit('send_message', {
  clientMessageId: uuidv4(), // generated once, reused on retry
  recipientId,
  content,
});

async function persistMessage(data) {
  // Upsert on clientMessageId prevents duplicates
  return db.messages.upsert({
    where: { clientMessageId: data.clientMessageId },
    create: { ...data },
    update: {}, // no-op if it already exists
  });
}

This is a small addition that prevents an entire category of "why did my message send twice" bug reports.

What this means for your build priority

If the retention data holds — and directionally, it matches what most social products observe — then the architectural takeaway isn't just "add DMs." It's that DMs deserve to be treated as core infrastructure, on par with your feed and auth system, rather than a checkbox feature squeezed in after the "real" product ships. That means:

Budgeting real engineering time for the pub/sub and persistence layer, not just a WebSocket happy path
Load-testing reconnect and offline-delivery paths before launch, not after complaints
Treating message delivery reliability as a metric you actually monitor, the same way you'd monitor feed load time

A feed brings people to your app. A conversation they're waiting on is what brings them back tomorrow — and that only works if the messaging layer underneath it doesn't drop messages, double-send them, or fall over the moment you scale past one server.

Want a follow-up piece diving deeper into one layer — message ordering/idempotency at scale, push notification fallback strategy, or scaling Redis Pub/Sub past a single Redis instance?

DEV Community