Taking push notifications off a busy PHP server

Stack. Node.js and Express.js service, MongoDB for storage, and Google Firebase Cloud Messaging (FCM) for delivery. It was split out of the company's busy PHP server so notification work stopped competing with it, and so notifications could scale as a separate service. The business logic was mapped in flow charts first, and the database designed and normalised before the server was built.

How a notification was processed. The PHP server sent one payload: the message, plus the users and groups it was for. The service saved each notification as its own document, created any user accounts that didn't exist yet (for authentication and auditing), and made a registry entry for every recipient. It then posted the messages to FCM in bulk, updating the registry as it went.

Delivery tracking. Each registry entry moved through four states: pending (still to send), sent (FCM confirmed the message was in its queue), received (the device got it) and read (the user opened it). Devices reported received and opened back to the service, so a notification that never arrived could be found and sent again. Statistics were reported per user, per group or per community.

Device API. The service worked both ways. A device could fetch its notifications, update a notification's status, get all unread notifications for a group or category, mark a whole group or category as read, and unsubscribe from groups or categories it no longer wanted.

Security. Server-to-server and user-to-server token authentication, every route token-protected, URL and data sanitisation throughout, and an audit trail on every notification.

Timeline. 2 months, 2020.