A support ticket said the invest button felt broken. People were tapping it twice.
The handler took about three seconds. When I traced it, almost nothing in there was work the caller needed an answer about. Writing the order was fast. The slow part was everything that happened because of the order: notification fan-out to push and messengers, analytics events, a couple of downstream calls nobody was waiting to read back.
So the user's action was coupled to the consequences of their action. A messaging provider got slow, and placing an order got slow with it. Someone else's latency spike turned into a failure in my core flow.
I moved the consequences out. The handler does one thing now: commit the state change and record an event in the same transaction. Everything else gets consumed off the queue by workers that can retry on their own time. Response is roughly 200ms, and the provider's bad days stay the provider's.
The part that bites: emit that event outside the transaction, and you have traded a slow endpoint for a lost notification. Fast and silently wrong is the worse bug.
The double-tap was the real signal, by the way. A slow write path shows up as duplicate intent long before anyone looks at a latency graph.
There is probably something still sitting in your request path that nobody is waiting to read...