Why is it risky to perform slow operations inside a subscribing event handler?

A subscribing event handler runs synchronously, inline, on the same thread as the command that published the triggering event, and it runs before that command is considered fully handled. If the handler performs something slow — a heavy database write, a call to an external service, a large computation — that slowness is added directly to the time the original caller waits for a response. There is no queue or buffer absorbing the delay, because the handler is not decoupled from the command at all. This is exactly the opposite of what most projections want: a read-model update should ideally happen without making every write to the system feel slower. For this reason, subscribing processors are reserved for narrow cases where a handler genuinely must complete before the command returns, rather than used as a general default.