DEV Community

Surhid Amatya
Surhid Amatya

Posted on

From memory to machines: how notifications actually work


Here we talked about the Notification.. Now let’s connect that human idea to the system behind it.

Marketing and engineering look at notifications very differently.

How marketing thinks

  1. We want to send messages.
  2. We want people to remember us.
  3. We want them to come back.

How engineering thinks

  1. We need reliability.
  2. We need scale.
  3. We need control.

Both are right. Both are incomplete alone.

A notification system exists to make them meet in the middle. The real flow, explained simply

Let’s use a food delivery example. You place an order.

What happens next?

`[ Order Placed ]
       |
       v
[ Notification Service ]`
Enter fullscreen mode Exit fullscreen mode

The order service does not send a push directly. It only says:
“Something happened.”

The brain: Notification Service

The Notification Service is like a smart receptionist. Before sending anything, it asks questions.

[ Notification Service ]
        |
        |-- Is the user logged in?
        |-- Do they allow notifications?
        |-- Have we sent too many today?
        |-- What device are they using?
        |-- Push? Email? SMS?
Enter fullscreen mode Exit fullscreen mode

This is where marketing intent meets engineering rules.

Marketing says: “Send an update.”

Engineering asks: “To whom, how, and safely?”

Giving the message a human voice. Once the system decides to send, it prepares the message.

[ Template ]
   |
   v
"Your order is on the way"

[ Personalization ]
   |
   v
"Hi Ram, your order is on the way"

Enter fullscreen mode Exit fullscreen mode

Without this step, notifications feel robotic. With it, they feel personal.

Just like calling someone by name at the door.

Delivery workers (the invisible heroes). Now the message needs to reach the user.

[ Workers ]
   |
   |-- Push (APNS / FCM)
   |-- Email (SMTP)
   |-- SMS
Enter fullscreen mode Exit fullscreen mode

Workers are like delivery people.

  1. If one road is blocked, they retry.
  2. If a service is slow, they wait.
  3. If something fails, they queue again.

This is where trust is built. Closing the loop: learning from users. After delivery, the system watches.

[ User ]
   |
   |-- Opened?
   |-- Clicked?
   |-- Ignored?
   |-- Disabled notifications?
Enter fullscreen mode Exit fullscreen mode

That data goes back.

Now:

  1. Marketing learns what people care about
  2. Engineering learns what breaks
  3. Product learns what matters
  4. Next notification becomes smarter.

Real-life version of this loop

A laptop shop gives you a branded bag.

[ Free Bag ]
     |
     v
[ Daily Use ]
     |
     v
[ Brand Recall ]
     |
     v
[ Return Customer ]
Enter fullscreen mode Exit fullscreen mode

Same loop. Different medium.

Why does this matter?

Most teams build notifications like plumbing.

Pipes in.
Messages out.

The best teams build notifications like memory design. They ask:

  1. What should users remember?
  2. When should they remember it?
  3. How gently can we remind them?
  4. When does it become noise?

It’s not just architecture. It’s psychology turned into systems.

Notifications are not just saying: “Something happened.”

They are saying: “Remember us when it matters.”

And when marketing and engineering agree on that, you stop sending messages and start building relationships.

Top comments (0)