Skip to the content
Nikhith ReddyLet’s talk
  1. Work
  2. When the CRM goes down.

Rapport · Engineering case study

The CRM can fail. The product should keep working.

An external system should not decide whether the product can save a change. I separated the local write from delivery, then designed the path back from failure.

Explore the decisions
  • PythonDelivery worker
  • PostgreSQLTransactional outbox
  • RedisRate limiting

The decisions

Three decisions, the reasoning behind each, and what changed as a result.

Reliable external deliveryExample delivery
Separate saving from sending

The CRM is down. The saved deal isn’t.

One PostgreSQL transaction
PostgreSQL logoDeal savedAcme · Closed won · rev 7
Delivery event savedOutbox · deal.updated
Python logoWorker sends later
External CRMDelivery pending

The saved deal does not depend on this response.

Watch the outage unfold, or hold a phase. The business change remains saved throughout.

How it works

A quick guide to the interactive flow on this page.

Dynamic contentClick each step to see a different part of the story.

The outcome

Application writes are separated from CRM delivery.

The transactional outbox, worker, retry policy, and write guards make external delivery a recoverable process instead of part of the user’s request.