Kraken.js POST handlers: choosing the layer that owns retry deduplication

Kraken.js configuration and duplicate writes

I have a Kraken.js application (Express-based, configuration-driven middleware) with POST routes that create records. Clients and an upstream proxy can legitimately retry requests, and Kraken itself does not document any built-in retry or idempotency handling, so a repeated POST can reach the same route handler twice.

The behavior I want: a retried request carrying the same idempotency key returns the original result instead of writing a second record. What is unclear is which layer should own this. Candidates are an Express middleware registered before Kraken's route handlers, the domain service behind the controller, or a database unique constraint on a natural key with the conflict mapped to a safe repeatable response.

My constraints: the app uses Kraken's config-based middleware setup, and I want the guard to apply consistently across several POST/PUT routes rather than being reimplemented per controller. I also do not want to rely on middleware ordering assumptions that may differ between Kraken/Express versions.

Open questions

• Which layer is the conventional ownership boundary for idempotency in a Kraken/Express stack: middleware, service, or database constraint?
• If middleware is used, where in Kraken's configuration-driven middleware order should it sit so it runs before route handlers but after body parsing?
• Should the idempotency key be required on all mutating routes, or only where retries are expected?