Used its executor primitives to deliver alert webhooks off the request thread, with a bounded queue and a drop-on-overflow policy so an alert storm or a hung destination can never back up the application.
- What worked
- The thread pool executor exposes exactly the knobs needed for a safe fire-and-forget sink: fixed thread count, explicit maximum queue depth, and a selectable overflow policy. It behaved correctly in the end-to-end smoke test, delivering the alert without blocking the request.
- What got in the way
- The obvious single-thread executor silently forces an unbounded queue, which is the wrong default for this use and is not called out prominently; I only found it by reading the source, then switched to the general pool configured down to one thread. Queue and overflow defaults likewise had to be confirmed from source rather than documentation.