Concepts
Back to Articles

Building a Scalable Notification System with AWS Amplify

IT Thulani Apr 16, 2026 4 min read
Building a Scalable Notification System with AWS Amplify

I’m currently developing a Human Resource Management System (HRMS) for a growing company with my team using AWS. In there, one of the key features I needed was a notification system. At first, it seemed simple - just send a message when something happens. But when I went deeper, I realized building a reliable and scalable notification system requires proper architecture.

 

Starting with a Simple Approach

Initially, I implemented notification system using AWS Amplify AppSync directly.

The flow was simple:

  • First foremost frontend triggers a mutation (for example think, an employee had applied a leave request for his manager. Then the manager reviewed it and for some reason he rejected that request. Now the system needs to inform that employee as “Your leave request has rejected by the manager”. So, frontend tells the backend that a notification event happened.)

  • AppSync calls a Lambda function

  • Then Lambda stores the notification in DynamoDB

  • UI listens using subscriptions and updates instantly. (Pushes the notification to the user’s frontend instantly. The bell icon updates without refreshing the page.)

This worked well for basic use cases, as it was easy to implement and fast to integrate. However, I started thinking about real-world scenarios.

Notification System Workflow (using AWS Amplify AppSync directly)

The Problem I Noticed

This system works fine for a simple system with fewer users and small traffic. But, as this is a real-world project for a growing IT company, what happens if:

  • Too many notifications are triggered at once? (for example, think managers receive notifications about leave requests and  device issue reports from many employees at a same time)

  • The Lambda function is busy?

  • There are sudden spikes in system activity? (During peak time)

In this setup, everything depends on immediate processing (Do everything right now, if can’t fail). That results:

 

  • If something fails, the notification might be lost

  • The system is not fully scalable

  • Backend services may become overloaded

 

Moving to a Better Architecture (SQS-Based)

To solve this, I updated the system using Amazon SQS (Simple Queue Service).

The new flow became:

  1. Frontend triggers an AppSync mutation

  2. First Lambda (Producer) sends the message to SQS

  3. This SQS acts like a buffer and stores the message safely according to the order which they arrive, until they process one by one.

  4. Next Lambda (Consumer) processes the message

  5. Notification is saved in DynamoDB

  6. AppSync subscription updates the UI instantly.

 

 Notification System Workflow (SQS based)

 

Why This Approach is Better

If a backend service crashes. Without queue, notification can be lost. But with SQS, messages stay in queue safely and lambda processes it later. So, nothing is lost.

Using SQS introduced a big improvement:

  • Reliability - Messages are stored in the queue even if the system is busy. (for example, think 100 notifications happen at once. SQS stores them safely and processes them one by one)

  • Scalability - The system can handle large spikes without breaking.

  • Decoupling - Each part of the system works independently.

  • Retry Mechanism - If processing fails, SQS can retry automatically.

 

Real Example from My Project

When admin assigning a device to an employee:

Admin assigns device

        ↓

AppSync mutation called (forward the request to the lambda 1)

        ↓

Lambda 1 → sends message to SQS

        ↓

SQS stores message temporally

        ↓

Lambda 2 → processes message (get one by one message from the queue and process them)

        ↓

DynamoDB → saves notification

        ↓

AppSync Subscription (Real-time listener that auto-updates UI when a mutation happens)

        ↓

Employee sees Bell notification instantly without refreshing the page

What I Learned

This experience helped me understand:

  • The difference between simple vs scalable architecture

  • Why queues are important in real-world systems

  • How AWS services work together with:

    • AppSync

    • Lambda

    • SQS

    • DynamoDB

 

Conclusion

At the beginning, I thought notifications were just about sending messages. But now I understand they are about reliability, scalability and user experience

"Good systems don’t just work — they keep working under pressure."

This project was a great learning experience in building real-world cloud architecture.

If you're building something similar, I highly recommend starting simple, but always think about how to scale when your system grows.