Documentation
v0.6
Overview
About Notiway

About Notiway

Notiway is a gateway for delivering in-app notifications from distributed applications. It runs entirely within your infrastructure and is designed to solve all common notification-related challenges in modern applications.

Built with a pluggable architecture, Notiway offers open-source plugins for all major components like authentication, buffer, broker, storage, monitoring, and multitenancy, giving you full transparency and control. The core engine remains proprietary to ensure stability and performance, while you retain the flexibility to customize or replace any plugin to fit your specific needs.

What Problems Does Notiway Solve?

Notiway addresses the following challenges:

  • Connection Management: Handle connecting, reconnecting, and disconnecting from multiple client devices seamlessly
  • Routing: Route notifications to a single user, all users within a tenant, or across your entire application
  • Authentication: Validate incoming requests against any authentication provider or custom logic
  • Multitenancy: Isolate and validate tenants when needed
  • Scaling: Stateless architecture enables horizontal scaling based on the number of connected users or resource consumption
  • Cost Efficiency: Minimal footprint designed for cost-effective operation based on expected throughput
  • Fast Response: Minimalistic design ensures fast notification processing and delivery
  • Notification Standardization: Enforces a consistent structure for all incoming and outgoing notifications
  • Notification Persistence: Persist notifications for a defined period, ensuring offline users receive messages when they reconnect

How It Works

Notiway is built on SignalR, which handles WebSocket connections, automatic reconnects, and protocol negotiation out of the box. Unlike standard SignalR deployments that rely on Redis as a backplane for scaling, Notiway implements its own scaling mechanism, the broker plugin acts as the backplane, distributing notifications across all gateway instances without requiring a dedicated Redis setup.

System Diagram 

  architecture-beta
    group api(cloud)[Notiway]

    service producer(mdi:application)[Your Service]
    service core(mdi:brain)[Core] in api
    service db(mdi:database)[Storage] in api
    service buffer(mdi:tray-full)[Buffer] in api
    service broker(mdi:hub)[Broker] in api
    service client(mdi:account)[Client]

    producer:L -- R:broker
    broker:L -- R:buffer
    buffer:L -- R:core
    core:B -- T:db
    core:L -- R:client

Notification Flow

When your service publishes a notification to the broker (SNS, Redis, RabbitMQ, etc.), Notiway takes it from there:

  1. The Broker forward message to Buffer of each instance
  2. The Core dequeues the notification and inspects its routing metadata
  3. Based on the audience type, the core identifies the target connections which can be a single user, all users in a tenant, a named group, or everyone
  4. If persistence is enabled, the Storage plugin saves the notification so offline users receive it on reconnect
  5. The notification is pushed to all matching connected clients over their open WebSocket connection

Client Connection Flow

  1. A client contact the gateway using HTTP request.
  2. Notiway authenticates the request using the configured Auth plugin
  3. The request is upgraded to a persistent WebSocket connection
  4. The client subscribes to the notification types it wants to receive
  5. From that point, the gateway routes matching notifications directly to that client in real time
  6. On reconnect, any persisted notifications are replayed immediately
Advantages