Production Case Study: Amazon Style Notification Platform

Now connect the full system. Imagine an ecommerce platform where a customer buys a product, payment succeeds, warehouse packs it, courier picks it up, and the package is delivered.

The same event-driven foundation works beyond ecommerce. In the AI compliance marketplace case study, business onboarding, document processing, review, and approval states create similarly important notification events.

Business Journey

1. 01
   Customer
2. 02
   Adds product
3. 03
   Checkout
4. 04
   Payment
5. 05
   Warehouse
6. 06
   Courier
7. 07
   Delivered

Every step can create notifications for different people.

Event Map

Complete Architecture

Complete Notification Platform

Architecture flow

Business domains

Own business transactionsProduct Services

Transactional handoff

Commits events atomicallyOutbox Tables

Event transport

Distributes durable eventsEvent Broker

Notification domain

Applies preferences and policyNotification Service

State and buffering

System of recordPostgreSQL

Fast lookupRedis Cache

Priority buffersQueues

Parallel processing

Scales by channel and priorityWorker Fleet

Delivery channels

Inbox deliveryEmail

Mobile deliverySMS

Device deliveryPush

Product inboxIn-app

Checkout Example

When payment succeeds, the payment service writes the payment row and outbox event in one transaction.

BEGIN;

UPDATE payments
SET status = 'success'
WHERE id = 'pay_123';

INSERT INTO outbox_events (id, event_type, payload, status)
VALUES (
  'evt_payment_123',
  'PaymentSuccess',
  '{"paymentId":"pay_123","orderId":"ord_123","userId":"user_123"}',
  'pending'
);

COMMIT;

The outbox relay publishes PaymentSuccess. Notification Service consumes it, checks preferences, creates notification rows, and enqueues jobs.

Channel Decisions

Payment success:

Out for delivery:

Security alert:

Queue Routing

function selectQueue(notification: NotificationJob) {
  if (notification.category === "security") return "security-critical";
  if (notification.channel === "sms") return "sms-urgent";
  if (notification.channel === "email") return "transactional-email";
  if (notification.channel === "push") return "transactional-push";
  return "marketing-bulk";
}

This function protects urgent notifications from bulk traffic.

Retry and DLQ

Monitoring

For this case study, alerts should cover:

Production Walkthrough

1. Customer pays for order.
2. Payment service commits payment and outbox event.
3. Event broker receives PaymentSuccess.
4. Notification Service creates email and in-app notifications.
5. Email job enters transactional email queue.
6. Worker renders invoice email template.
7. Provider accepts email and returns message ID.
8. Delivery attempt is marked accepted.
9. Provider webhook later marks delivered or bounced.
10. Dashboard shows status to support.

Common Mistakes

1. One queue for all ecommerce notifications.
2. No outbox around payment events.
3. Treating provider accepted as final delivery.
4. Sending SMS for every step and creating cost waste.
5. No support-facing status trail.

Interview Questions

1. Walk through order confirmation from event to email delivery.
2. Which notifications should use SMS in ecommerce?
3. How would you prevent duplicate invoice emails?
4. What metrics prove the system is healthy?

Exercise

Extend this design for returns and refunds. Define events, receivers, channels, queues, retries, and monitoring alerts.