Short answer: a public HTTPS queue push webhook subscriber in Node.js should verify the signature on the raw request, persist a unique cleanup command, and ack only after that durable write; a bounded worker should own retries. The request should never wait for the marketplace cleanup itself.
That sounds almost too conservative. It is exactly what makes a delayed task boring to operate. A marketplace can tolerate a cleanup running a few minutes late; it can't easily tolerate deleting a listing twice, charging a seller twice, or turning one delivery retry into two irreversible side effects.
Fast ack.
I frame the design around one bounded scenario: an expired marketplace listing is placed on a delayed queue, a push delivery reaches a public endpoint, and a worker removes stale search and reservation data. The endpoint's job is to accept responsibility for that command. It is not the worker, and it is not a second scheduler hiding inside an HTTP request.
What should a public HTTPS queue webhook subscriber verify before ack?
