By answering these questions, I began to shape the architecture of RelayGrid. In this post, I want to share some of the decisions I’ve made, the mistakes I’ve corrected, and how the system is evolving.

Defining Channels and Templates

In RelayGrid, a Channel is the mechanism used to deliver a notification. Whether it is Push, Email, or SMS, each medium is treated as a distinct channel. For instance, a company might use several different email identities for automated communications, such as noreply@company.com, contact@company.com, or support@company.com. In RelayGrid, each of these is represented as a unique channel.

To make sending these messages efficient, we use Templates. A template is a pre-configured bundle of data that prevents users from having to redefine settings for every single message. A template consists of:

• One or more attached channels

• A subject line and body (with HTML/CSS for emails)

• An optional Email layout with HTML/CSS support for branded notifications.

By using dynamic attributes in a notification’s subject and body, users can inject personalized data into these templates, ensuring that every notification feels tailor-made for the recipient.

The Pivot: Rethinking “Notification Users”

One of the most important lessons I’ve learned while developing RelayGrid is how we model “Notification Users” (the recipients)

In my initial design, I tied a notification user to a specific channel. I quickly realized this was a very problematic architectural decision. For example, if an account had five different email channels for various use cases, a single end-user’s email address would have to be stored five separate times in the database. This created unnecessary data redundancy, introduced complexity trying to keep all the records in sync, and made management a nightmare for account admins.

I had to pivot. I realized that while a channel is specific, a user’s contact information is not. Today, I have decoupled them. A notification user contact information is attached to a contact type rather than the individual channel instance. This keeps the database clean, reduces redundancy and complexity, and makes the system much easier to scale.

What’s next?

RelayGrid is under active development, and its architecture is evolving as new features are being developed and tested. As I uncover new edge cases and scaling challenges, the system shifts to accommodate the new requirements. Engineering is rarely about making the “perfect” first decision; it’s about building a system that is flexible enough to be corrected.

Currently, my focus is on implementing SMS deliveries.

If you want to follow the technical journey of building a multi-channel notification infrastructure SaaS, subscribe below to stay posted on my progress.

Subscribe now

Why am I building this platform?

It started with a rant on Tech YouTube. I was watching a creator complain about the absolute chaos of Google’s notification system, and a dangerous thought entered my mind: How hard could it be to do this better?

Spoiler alert… IT IS HARD!

In my day job as a software engineer, I solve complex problems every day, but they are a completely different type of problems. The architecture required to handle real-time, scalable notifications comes with its own unique challenges and pitfalls. What started as a classic “hold my beer” moment, quickly turned into a deep dive into a domain I’ve never dealt with professionally.

I am using my evenings and weekends, sometimes nights, to learn and work on something new and exciting. I’ll be documenting my process, the wins, failures, and the lessons learned. Hell, I’m event learning about SMS, RCS, and telecom industry requirements now.

I’ll be sharing my experience and my learning here. Subscribe, if you’d like to follow along!