Kafka Connect vs custom consumers¶

Сравнения · Раздел03

Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.

Версии указаны в заголовках и связанных статьях. Численные показатели производительности не заявляются.

Критерии выбора¶

Критерий	Connect4.1 + plugin	Custom client/application
Workload / architecture	Standard source/sink integration	Business-specific validation/effects/retry logic
Consistency / transaction boundary	Plugin-specific source/sink contract	Explicit implementation of offsets/idempotency/transactions
Latency path	Batch/flush/plugin queues	Poll/handler/DB/network/config
Throughput / scalability	Tasks/source splits/target capacity	Partition ownership/custom parallelism/safe frontier
Operational complexity / cost	Managed framework/plugin lifecycle/REST/internal topics	Application code/tests/rebalance/error ownership

flowchart TB
  Kafka --> Connect[Worker and plugin task]
  Kafka --> Custom[Application poll loop]
  Connect --> Plugin[Plugin flush and safe offsets]
  Custom --> Inbox[Explicit inbox and effect transaction]
  Plugin --> Target[External target boundary]
  Inbox --> Target

Конкретные сценарии¶

Стандартная CDC source → Debezium/Connect. Уникальный inbox+projection financial reporting effect → custom consumer может выразить needed atomicity. Connect sink подходит только после проверки target transaction/idempotency semantics, не по наличию connector name.

Ограничения и восстановление¶

Custom consumer не проще из-за 30 строк poll loop: rebalance, poison messages, safe commits, upgrades и observability требуют кода. Connect valid config не доказывает корректность business mapping.

Как проверить выбор¶

Зафиксировать query/event mix, schema/payload, skew, working set/state, retention, target effect и допустимую stale-read policy. Проверять lost ACK, restart/rebalance, poison record, late correction и rebuild generation. Сравнивать TCO с одинаковыми durability/replication требованиями, включая engineering, maintenance и restore. Универсальный winner отсутствует.

Типичные ошибки проектирования¶

Сравнивать разные boundaries как одинаковую гарантию; игнорировать recovery и source retention; публиковать чужие latency/TPS как свои измерения; забывать target operations.

Вопросы на собеседовании¶

Когда стоит сочетать варианты? Когда они отвечают на разные уровни/нагрузки и contracts переходов определены. Дополнительный компонент добавляет ownership, lag, recovery и стоимость, поэтому нужна измеримая польза.

Практические упражнения¶

Составьте ADR для одного сценария: invariant, rejected alternative, failure matrix, recovery evidence и план честных измерений. Укажите, какие guarantees ещё UNKNOWN.