Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kafka as an Antipattern

joshaustin.tech

Post reply on HN
Print view View original

41–50 of 102 posts

Re: Kafka as an Antipattern

#41

Post by steve_adams_86 »

alexchamberlain wrote: post #14
pjscott wrote: post #10

Earlier quoted context omitted.

Yes. For perspective, that's about one message every ten seconds.

Sorry for the naivety/not obvious from the comments: is that too much or too little? (I've used RabbitMQ much more than Kafka.)

I once worked on a chat-based system that handled load like this, and it was initially built with kafka. I worked out that the cost per message was several cents, haha. I replaced it with a redis queue, which was all I knew at the time, and it ran on a digitalocean droplet for CAD $5 per month for around 18 months before they scaled it up. It was handling ~100 messages per second peak at the end, which is still very low. The cause for concern was that the droplet silently failed due to memory issues on a particularly busy day, so it seemed reasonable to jump to the next tier to avoid that issue for a while.

For what it's worth I never intended for the 1CPU/1GB VM to go to production, but I was a consultant and they just ran with it. And it worked!

They swore off of kafka forever after the pains they had with it. Another consultant built that system for them, so it wasn't an internal decision exactly and they had no idea what they were getting into. I've heard of similar experiences since. I've sometimes hoped to land on a project where kafka was well suited to the problem, though; I learned a lot about it back then and it seemed incredibly cool. I was kind of envious of all these projects fully utilizing it!

Re: Kafka as an Antipattern

#42

Post by wayfinder »

SanderNL wrote: post #28

8000 messages a day, tops? That’s 5 a minute. Does that warrant “infrastructure”? I think a gameboy’s Z80 could handle that load. I don’t want to be dismissive, but I often see these big numbers being posted, like “14M messages” or “thousands of messages” and then adding “per year” or something, which brings it down to toy level load. Even the first “serious” example is about “thousands of messages” per minute. Say 5…

Yeah that’s nothing.

My busy discussion forum built in PHP running on a toaster of a server was handling way more load than that 15 years ago.

Re: Kafka as an Antipattern

#43

Post by SuperCuber »

alexchamberlain wrote: post #14
pjscott wrote: post #10

Earlier quoted context omitted.

Yes. For perspective, that's about one message every ten seconds.

Sorry for the naivety/not obvious from the comments: is that too much or too little? (I've used RabbitMQ much more than Kafka.)

too little

Re: Kafka as an Antipattern

#44

Post by tda »

The main problem I have with Kafka is that their sales team is too good: at my previous employer the CIO was convinced we needed Kafka and bought a contract for sever 100k. But we already had all our events in a postgres database.

Admittedly that database had some complicated queries with lots of business logic to get a useful view on the data. But at first I hoped Kafka would somehow make this easier, but of course our particular usecase with a low event volume (hundreds per day), high latency tolerance (next day reporting was considered good enough), highly complex business logic (various computations that required knowledge of what was done previously) all made Kafka just about the least suitable tool for the job.

Of course the contract was already signed (I was naturally never consulted up front), so this resulted in lots of solution looking for a problem. No suitable problem was found so I ended up leaving enterprise world for a scale-up and the CIO is still doing whatever he wants for god knows why

Re: Kafka as an Antipattern

#45

Post by _jal »

alexchamberlain wrote: post #14
pjscott wrote: post #10

Earlier quoted context omitted.

Yes. For perspective, that's about one message every ten seconds.

Sorry for the naivety/not obvious from the comments: is that too much or too little? (I've used RabbitMQ much more than Kafka.)

It is using a dump truck to sugar your coffee.

Re: Kafka as an Antipattern

#47

Post by baz00 »

SanderNL wrote: post #28

8000 messages a day, tops? That’s 5 a minute. Does that warrant “infrastructure”? I think a gameboy’s Z80 could handle that load. I don’t want to be dismissive, but I often see these big numbers being posted, like “14M messages” or “thousands of messages” and then adding “per year” or something, which brings it down to toy level load. Even the first “serious” example is about “thousands of messages” per minute. Say 5…

I think you're probably being slightly dismissive. It's not necessarily about load but various other concerns like durability, delivery latency and how failures are handled. There's a big difference between messaging and reliable messaging. I have messaging systems that take 10-20 messages a day but must deliver those messages and do it on a deadline. For that you do need infrastructure (and no that isn't a queue inside a SQL database).

Re: Kafka as an Antipattern

#48

Post by chrsig »

ssrc wrote: post #36
imachine1980_ wrote: post #13

Earlier quoted context omitted.

>small scale kafka, though. It's conceptually great to have everything work off of logs, but kafka does add a non trivial operational burden. does something like that exist ???

Depending on the meaning of "small-scale kafka", both RabbitMQ and redis do support streams.

One of my desires would be for it to be persistent. Hopefully with the option of different storage tiers, so as logs became older they could be moved to less costly medium and transparently fetched when requested.

Having an event sourced system doesn't make much sense unless you maintain messages from the start of the system. You can snapshot state and resume in order to quickly rebuild from a known good state. That doesn't help if there was a logic error corrupting every state from the start, and a full rebuild is required.

I'm unsure how redis streams behave with regard to cache eviction, nor am I familiar enough with rabbitmq to comment on it's behavior. It's been 10 years since I used either, and at the time neither were good solutions for a log based system.

Re: Kafka as an Antipattern

#49

Post by rewmie »

SanderNL wrote: post #28

8000 messages a day, tops? That’s 5 a minute. Does that warrant “infrastructure”? I think a gameboy’s Z80 could handle that load. I don’t want to be dismissive, but I often see these big numbers being posted, like “14M messages” or “thousands of messages” and then adding “per year” or something, which brings it down to toy level load. Even the first “serious” example is about “thousands of messages” per minute. Say 5…

> 8000 messages a day, tops? That’s 5 a minute. Does that warrant “infrastructure”? I think a gameboy’s Z80 could handle that load.

The blog post is quite clear in stating that their pain points had nothing to do with scaling or throughput. The author explicitly mentions idempotency, custom headers, and authentication.

I think you're ranting about a strawman you put up.

Re: Kafka as an Antipattern

#50

Post by chrsig »

mu53 wrote: post #39
imachine1980_ wrote: post #13

Earlier quoted context omitted.

>small scale kafka, though. It's conceptually great to have everything work off of logs, but kafka does add a non trivial operational burden. does something like that exist ???

I think it'd be very easy to write your own. I used postgres subscribe/listen built in combined with a database table to get a distributed message system. Writing a distributed, scalable system is really hard, and beyond the API, that is the real value for kafka

It's relatively easy -- removing any networking requirements drastically simplifies the problem. There's still some non-trivial bits that vary depending on granularity for concurrency.

It's a weekend project to demonstrate the concept, maybe a few weeks to really flesh it out and iron out quirks. I imagine if you're willing to use sqlite as a backend for persistence, it gets a bit easier.

Post reply on HN