We had a mix of realtime (continuous) consumers and batch consumers that consumed directly from Kafka, but also archived that data to S3 for future batch processing.

Operations were quite simple for us, but we were also used to running Zookeeper before, so YMMV. If you can get away with Kinesis, it's simpler operationally, but Kafka isn't difficult compared to most systems.

If it was a clean failure, no big deal. If the disk started having issues and taking a long time for IO to come back, all partitions with replicas or leaders on that node were slow. That's kind of the state of the world with most distributed things though: a bad node is worse than a dead node.

"no leader for partition" is something I see frequently.

In Kafka's defence a better managed cluster might do better. In nsq's defence: nobody has to manage it, it just runs.

Kafka is a distributed, partitioned log. Messages published to a partition in a given order will be stored in that order and replicated in that order, and consumed in that same order. Kafka writes all of your data to disk, and waits for replicas to acknowledge it (depending on your producer configuration). Kafka does considerably more work than nsq.

I like nsq, it works well, but they aren't at all designed to solve the same problems.

I mentioned the issues above because they'd happened, but in years of running Kafka it was never Kafka's fault.

> "no leader for partition" is something I see frequently.

Something is wrong with your cluster if it's constantly switching leadership. Leadership should be stable -- and furthermore, partitions have preferred leaders, so they should stay with specific nodes until that node goes down. Kafka has a process which shifts leadership back to preferred leaders automatically (unless it's off). Check your logs.

I can't remember if it's an issue for change capture since in theory you have some insert timestamp column anyway.