A thought based on the question: Kinesis and SQS operate differently. So when you say "the shard will be blocked" - individual consumers on the shard might choose not to consume the next message in the stream but there's no concept of "blocking". Unlike SQS, messages in the stream are visible to all of the consumers so they can choose what they're going to do with each message - which is great if you have several different processes that need to happen on a single message - you can use different consumers and they don't get in each other's way.
So in the Kinesis world, if you want to maintain ordering you can only have a single consumer on the stream (shard, really). If there is a fault the blocking happens in the consumer, not in Kinesis.
Probably not helpful - but I'd question why Kinesis is better than SQS FIFO in this case.
Finally: I'm a little concerned about the comment "SQS FIFO is too slow" - have you tested Kinesis to ensure that it meets your performance requirements?
Given the complexity of the question and the challenges you appear to be facing I'd contact your local AWS Solutions Architect to discuss further...
Why does the Kinesis Firehose output "Throttling error encountered when calling Kinesis".asked 3 months ago
How do we turn off SMPP delivery message when using Pinpoint and SNS for 2 way SMS?asked 5 months ago
How is SNS guaranteed to receive messages from event sources?Accepted Answerasked 2 months ago
guaranteed delivery of events with intermittently offline DeviceAccepted Answerasked 5 months ago
Kinesis fan-outAccepted AnswerEXPERTasked 6 years ago
How to set the starting position for a Kinesis Delivery Stream
Picking the correct Opensearch index date from the Kinesis Delivery Stream
Ordered message delivery to downstream consumers when transient faults occurasked 5 months ago
Dynamo DB Kinesis Steams Best PracticeAccepted Answerasked a year ago
Multiple Kinesis Data Analytics apps to use the same Kinesis firehose delivery stream as sourceAccepted Answerasked 2 years ago