Splitting Python event alerts between email and SMS by bounce risk

A practical approach to startup event alerts is to use policy rather than a single provider, sending routine notices by email and reserving SMS for time-sensitive events where delay is costly. The article argues that shared suppression state matters more than price, since bad addresses, hard bounces, stale numbers, retries, and opt-outs can create recurring engineering work. It recommends normalizing delivery events from both channels into one Python pipeline, using a small delivery state machine with explicit states such as delivered, retryable failure, and permanent failure. Channel adapters should handle provider-specific callbacks while the application owns alert intent, retry scheduling, and suppression decisions. Callbacks should be stored raw and applied idempotently so duplicates cannot accidentally clear suppression records.