Dispatchlane is planned as a Postgres-centred backend for integration reliability.
The first production shape is a modular monolith with separate runtime roles:
apifor ingestion and operator APIsworkerfor outbound delivery executionmaintenancefor recovery and background housekeeping
Dispatchlane is intended to provide:
- durable webhook receipt
- source verification
- canonical event persistence
- deduplication
- delivery attempt tracking
- retry scheduling
- dead-letter handling
- replay
- operator inspection
The architecture should favour:
- explicit state transitions
- immutable historical records
- auditability
- production-style observability
- operationally honest guarantees
The system should not pretend to provide exactly-once delivery. The initial delivery model is at-least-once with replay-safe persistence and strong operator visibility.