Add walkthrough: webhook event identity and restart-safe retries

[builtbyhuy]

Submitting an independent, runnable walkthrough for the weekly links, following the contribution route in the README.

Walkthrough: Webhook-to-CRM reliability boundary

The reader can send the same synthetic event through two local Python processes and inspect the SQLite ledger to see why a successful redelivery, a changed-payload conflict, and an exhausted retry need different decisions. The walkthrough also explains explicit replay and the audit trail.

The scope is deliberately narrow: CRM responses are simulated, no outbound CRM call is made, and the preview API does not provide cross-request durability. The linked architecture and production-gap notes explain why a real integration would need short transactions, a queue/outbox and remote-side idempotency.

This is my independent work, created with AI assistance, and is submitted transparently for editorial consideration. It is not a client case study or a production reliability claim. No service advertisement is included in the suggested review.

Thank you for considering it. If repository-based walkthroughs are outside the newsletter's format, I understand.

[ananthdurai]

@builtbyhuy what is the data engineering problem it solves?

[builtbyhuy]

The data-engineering problem is handling redelivered events at an ingestion boundary without turning a retry into a second downstream record, or silently accepting changed data under the same event ID.

For example, an upstream system resends an event after a timeout or worker restart. The walkthrough lets a reader inspect three different outcomes: the identical successful event is suppressed; the same ID with changed normalized content is flagged as a conflict; and an exhausted retry remains exhausted across CLI restarts until explicitly replayed. The SQLite event and audit rows make those decisions inspectable.

The CRM is only a simulated sink. This does not implement a warehouse pipeline, distributed exactly-once delivery, or atomicity between a database commit and a real external write. Its contribution is a small runnable lesson on event identity, deduplication and recovery before applying those ideas to a real ingestion pipeline.

I should have made that ingestion angle clearer in the submission. If the newsletter is looking for a complete data-platform example rather than this narrower boundary, this may not be the right fit.