What this prompt does
This prompt asks the AI to design a multi-channel notification service delivering [daily_notifications] per day across [channels]. It covers ten requirements: multi-channel delivery including [extra_channels], a template engine using [template_format], per-channel per-category preferences, batching and digests over a [batch_window], delivery tracking and retries, priority routing, anti-fatigue rate limiting, A/B testing, an analytics dashboard, and a provider abstraction for vendor switching.
The structure works because notifications quietly accumulate complexity: every channel has its own delivery semantics, every user has preferences, and every provider can fail. Passing [daily_notifications] sizes the queue throughput, while [channels] and [extra_channels] define how many delivery adapters you build. [template_format] (like Handlebars with MJML for email) drives the rendering layer, and [batch_window] controls how aggressively notifications are grouped into digests to avoid fatigue. The provider-abstraction requirement is what makes vendor failover and switching possible without rewrites.
When to use it
- You're building notifications into a SaaS product and need more than a single email send
- You need per-channel, per-category user preferences done right
- You want intelligent batching and digests over a
[batch_window]to fight notification fatigue - You need a provider abstraction so you can fail over or swap vendors
- You're designing priority routing so urgent messages bypass batching
- You need delivery tracking and retries that account for each channel's quirks
Example output
Expect a design with a database schema (notifications, templates, preferences), a queue architecture for ingest and per-channel delivery, a template-rendering layer using [template_format], a batching/digest design keyed to [batch_window], a provider-abstraction interface with failover logic, and an analytics section covering delivery, open, and click rates. It reads like a backend RFC you could hand to a team.
Pro tips
- Set
[daily_notifications]to your real volume; it drives whether a single queue suffices or you need per-channel partitioning - Keep
[channels]to what you'll genuinely support at launch — each one is a real adapter with its own failure modes - Use
[template_format]that matches your team's skills; MJML is great for responsive email but adds a build step - Tune
[batch_window]carefully — too long and notifications feel stale, too short and you defeat the anti-fatigue goal - Insist on the provider abstraction; hardcoding one vendor is the mistake that makes switching painful later
- Ask the model to detail priority routing so urgent notifications skip the
[batch_window]entirely
