Even though Kafka provides convenience methods to persist the committed offsets for a given consumer group, you’re not required to use that behavior and can write your own if you feel the need. Even so, the use of Kafka the way you’ve described it is a bit awkward for the use case as each client needs to repeatedly search the topic for a specific response. That’s inefficient at best.
You could break the problem into two parts, continuing to use Kafka to deliver requests to and responses from your server. The only piece you’d need to add would be some sort of API layer that your clients talk to and which encapsulates the Kafka-specific logic from your clients. This layer would need a local DB (relational or NoSQL) that could store responses by uuid making it very fast and easy for the API to answer whether a response is available for a specific uuid.