Understanding Emitter concurrency

[sgdesmet]

I have a situation where we need to process a large amount of incoming webhooks, with bursty traffic.
To do so, the messages should be put on an SQS Queue for later processing.
Exploring reactive messaging to achieve this (using Quarkus), the current approach looks more or less like this:

    @Inject
    @Channel("webhooks_enqueue")
    MutinyEmitter<WebhookPayload> messageEmitter;
    
    @POST
    @RunOnVirtualThread
    public void receiveWebhook(Webhook w) {

        // wait for message to be enqueued in case of buffer overflow, but respect
        // SLAs from webhook caller.
        messageEmitter.sendMessage( Message.of( w ) ).await().atMost( Duration.ofMillis( 250 ) );
    }

However, during intensive benchmarking the io.smallrye.mutiny.TimeoutException is often thrown, indicating that the underlying producer can't keep up. Increasing the connection pool for the AWS SDK client has no effect, indicating that this isn't the limiting factor. Additionally, using the SQSClient directly instead of an Emitter results in much higher throughput when enqueueing messages, without the webhook endpoint timing out.
Are there options for increasing parallelism with Emitters? For incoming channels there are options for defining consumer concurrency and worker pool threads, but this doesn't appear to be the case for outgoing channels.