Ordering Guarantees in FlinkKinesisProducer

I'm implementing a real-time streaming ETL pipeline using Apache Flink. The pipeline has these characteristics:

• Ingest a single Kinesis stream: stream-A
• The stream has records of type EventA which have a category_id, representing distinct logical streams
• Because of how they are written to Kinesis (separate producer per category_id, writing serially), these logical streams are guaranteed to be read in order by FlinkKinesisConsumer
• Flink does some in-order processing work, keyed by the category_id, generating a stream of EventB data records
• These records are written to Kinesis stream-B
• A separate service ingests the data from stream-B and it is important that this happens in order.

The processing looks something like this:

val in_events = env.addSource(new FlinkKinesisConsumer[EventA]( # these are guaranteed ordered
    "stream-A", 
    new EventASchema, 
    consumerConfig))
val out_events = in_events
  .keyBy(event => event.category_id)
  .process(new EventAStreamProcessor)
out_events.addSink(new FlinkKinesisProducer[EventB](
    "stream-B",
    new EventBSchema, 
    producerConfig))
# a separate service reads the out_events and wants them in-order

Based on the guidelines here, it seems like it is impossible to guarantee the ordering of EventB records written to the sink. I only care that events with the same category_id are written in order, since the downstream service will keyBy this. Thinking from first principles, if I were to implement the threading manually, I would have a separate queue per category_id KeyedStream and ensure those are written serially to Kinesis (this seems like a strict generalization over what is done by default, which is to use a ThreadPool, which has a single global queue). Does the FlinkKinesisProducer support this mechanism or is there a way around this limitation using Flink's keyBy or similar construct? Separate sink per category_id maybe? For this last option, I'm anticipating 100k category_ids so this might have too much of a memory overhead.

One option is to buffer events read from stream-B in the downstream service to order them (with high probability if buffer window is large). This in theory should work, but it makes the downstream service more complex then it needs to be, precludes determinism since it depends on random timing of network calls, and, more importantly, adds latency to the pipeline (though maybe less latency overall then forcing serial writes to stream-B?). So ideally, I'm hoping to go with another option. And, this feels like a common problem, so perhaps there are more clever solutions out there or I'm missing something obvious

Many thanks in advance.