Notix

What It Is

When building multiple SaaS products and custom dashboards for clients at DOTIX, a frustrating pattern kept repeating: every single application needed to send notifications to users, admins, or internal teams.

In each new project, we were forced to re-integrate the same SMS providers, email APIs (SendGrid/Resend), WhatsApp business bots, push notification services, and webhooks. Worse, every dashboard had to individually handle delivery retries, rate limits, network timeouts, delivery logging, and secret rotation.

I conceived and built Notix to solve this bottleneck permanently. Now, any dashboard or backend service makes one simple API call, and Notix handles the entire multi-channel fanout, queuing, reliability, and logging in the background.

---

What It Does

• Single Dispatch API: Applications send a standard JSON payload specifying the alert content and intended target channels (e.g. ["email", "whatsapp", "sms"]).
• Multi-Channel Bursting: One event (such as a payment receipt or critical security warning) can be dispatched concurrently across Email, SMS, WhatsApp, and Webhooks without the client app needing multiple SDKs.
• Asynchronous Queue & Auto-Retry Engine: If a downstream provider fails or is rate-limited, Notix queues the message in Redis and retries with exponential backoff rather than dropping the alert or hanging the client application.
• Centralized Audit & Delivery Logs: Complete observability into message status (queued, delivered, bounced, failed) across all channels from a single dashboard.

---

Architecture & My Contribution

I solely originated, architected, and engineered Notix to serve as an internal and B2B platform:

1. Gateway Design & Unified Schema:

   • Standardized notification templates and recipient resolution into a clean, intuitive REST contract.
   • Built a provider abstraction layer so switching email or SMS providers behind the scenes requires zero code changes in client applications.

2. Resilient Background Processing:

   • Used Redis queues and worker threads to decouple API ingestion from provider dispatching, keeping client HTTP responses sub-50ms.
   • Built robust fallback logic (e.g., if WhatsApp delivery fails or is unreachable, optionally fall back to SMS).

3. Rate Limiting & Cost Controls:

   • Implemented tenant-level throttling to prevent rogue loops from exhausting third-party API quotas or incurring accidental provider charges.

4. Product Leadership & Client Adoption:

   • Integrated Notix across all internal DOTIX SaaS projects and rolled it out as an infrastructure service for client development contracts.

---

Skills Used & Developed

• System Design & API Gateway Patterns: Decoupled architecture, clean provider abstraction, and fault tolerance.
• Distributed Queuing & Reliability: Redis worker queues, exponential backoff, dead-letter queues, and idempotency keys.
• Multi-Channel Protocol Integration: Mail transfer agents (SMTP/API), WhatsApp Cloud/Web APIs, Twilio/SMS APIs, and webhook dispatchers.
• Observability: Centralized log streaming and delivery status tracking.

---

Key Learnings & Takeaways

• Notice internal friction early: If your engineering team writes the same integration code three times across different repositories, it's time to extract it into a dedicated microservice or platform.
• Decouple notification delivery from transactional flows: Never let a slow or failing third-party email provider block a critical checkout or user sign-up response. Ingest immediately, respond fast, and queue delivery in the background.