Skip to content
RED SAGSkills
mediumFull Stack Developer interview question

You need to show in-app notifications in real time. How do you choose between polling, server-sent events and WebSockets, and how would you build it?

What the interviewer wants to hear

  • Polling is simplest but adds latency and load
  • Server-sent events suit one-way server-to-client updates
  • WebSockets suit two-way, low-latency interaction
  • Store notifications in the database as the source of truth
  • Use pub/sub (e.g. Redis) to fan out across server instances
  • Handle reconnects and missed messages

Model answer

Notifications flow one way, from server to client, so I usually choose server-sent events: they work over normal HTTP, reconnect automatically and send a Last-Event-ID so the server can replay missed events. Polling every 30 seconds is a fine first version if real time is not critical. WebSockets are worth the extra complexity when the client also sends frequent messages, as in chat or collaborative editing. Either way, notifications are first written to a database table, which is the source of truth for the unread count and history. After saving, the API publishes an event to Redis pub/sub or a managed real-time service, and every server instance pushes it to connected clients of that user. On serverless platforms, long-lived connections are limited, so a managed service like Ably or Pusher is often simpler.

Can you answer it under time pressure?

Take a timed medium round and get scored on every answer.

Start mock interview

More medium Full Stack Developer questions