Долго – это сколько? 10 мс? 100 мс?

В рэббите например вариант по умолчанию: возвращается ок, если сообщение закинуто в соединение до рэббита. Это происходит за пару мс. Вариант с гарантированной отправкой - надо указывать callback, потому что гарантия - это запись на диск, и рэббит по понятным причинам делает эти записи пачками через значительные промежутки времени, поэтому надо ждать.
Возможно с кафкой похожая схема - иначе говоря при использовании синхронного метода не гарантируется доставка в кластер
Если Кафка подтверждает только после записи на диск, как рэббит, то это может быть довольно долго (200-500 мс)

Так время можно тюнить, чтобы был приемлемый p95.

Посмотрю, спасибо.

Но заходя вперед, хотелось бы узнать best practise.

Делать асинхронно или синхронно вполне пойдет?

Эмпирически установил, что от запроса до сохранения в кафку и ответа 200 ушло 150мс

Зависит от задачи. Синхронная запись хороша тем, что пользователь получит 200, если данные точно записались. Соответственно, если делать асинхронно, то придётся дополнительно городить какой-то механизм подтверждения.

При этом важно понимать, что синхронно или асинхронно – никак не влияет на end-to-end latency.

По факту то асинхронное подтверждение будет дольше, как мне кажется

Но + что соединение не висит открытым, между продюсером и клиентом, который ждет подтверждения

Если используется какой-нибудь long polling, то тоже самое выйдет.

согласен, но тогда зачем асинхронное подтверждение вообще?

End-to-end latency от этого не будет зависеть Consumer сможет прочитать данные независио от того, обработал callback Producer или нет (и соответственно, каким образом обработал).

ой сложна

В моей картине мира в этом нет никакой пользы (кроме сценариев fire-and-forget, где подтверждения нет в принципе). На клиенте всегда можно отправлять данные через асинхронный HTTP-клиент и какую угодно логику уже строить вокруг этого.

Ну можно вместо полинга замутить сокеты и дергать его, когда будет успех. Клиент при этом может заниматься чем вздумается в ожидании ответа.

Но ваш посыл ясен.

Просто на этапе архитектуры хотелось предусмотреть возможность не фризить клиента в ожидании успешной отправки в топик, в случае если Кафка будет недоступна долгое время и запрос займёт больше секунды.

Ребят, добрый день!
Новичек в работе с кафкой, поэтому нужна помощь)
Есть такой конфиг докера

version: '3.7'
networks:
  analytic:
    driver: bridge
services:
  zookeeper:
    image: bitnami/zookeeper:3.6.2
    env_file: zookeeper/.env
    networks:
      - analytic
    ports:
      - 2181:2181
  kafka:
    image: bitnami/kafka:2.6.0
    ports:
      - 9092:9092
    environment:
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      ALLOW_PLAINTEXT_LISTENER: 1
    depends_on:
      - zookeeper
    networks:
      - analytic

При попытке отправить сообщение ничего не выходит

kafkacat -L -b 127.0.0.1:9092
Metadata for all topics (from broker -1: 127.0.0.1:9092/bootstrap):
 1 brokers:
  broker 1010 at bcd7d80f3442:9092 (controller)
 2 topics:
  topic "events" with 1 partitions:
    partition 0, leader -1, replicas: 1005, isrs: 1005, Broker: Leader not available
  topic "__consumer_offsets" with 50 partitions:
    partition 0, leader -1, replicas: 1001, isrs: 1001, Broker: Leader not available
    ....


echo '{"action": "read","event": "sdfsdf","service_name": "profile","session": "c3f94c52-6e05-4cfd-b974-14850a1335ba","user": "254c966d-f361-4f38-862d-4ee9717d8224"}' | kafkacat -P -b 127.0.0.1:9092 -t events

Что я делаю не так ?)