←back to thread

IBM to acquire Confluent

(www.confluent.io)
443 points abd12 | 5 comments | 08 Dec 25 13:43 UTC | HN request time: 0s | source
Show context
zkmon ◴[08 Dec 25 14:43 UTC] No.46192765[source]▶
Kafka is already past it's prime time. Time for new solutions for the oldest problem - sending a message.
replies(7): >>46193002 #>>46193131 #>>46193219 #>>46193482 #>>46193569 #>>46194911 #>>46211679 #
spyspy ◴[08 Dec 25 15:13 UTC] No.46193131[source]▶
I'm still convinced the vast majority of kafka implementations could be replaced with `SELECT * FROM mytable ORDER BY timestamp ASC`
replies(4): >>46193299 #>>46193568 #>>46194052 #>>46197629 #
1. Romario77 ◴[08 Dec 25 16:14 UTC] No.46194052[source]▶
pull vs push. Plus if you start storing the last timestamp so you only select the delta and if you start sharding your db and dealing with complexities of having different time on different tables/replication issues it quickly becomes evident that Kafka is better in this regard.

But yeah, for a lot of implementations you don't need streaming. But for pull based apps you design your architecture differently, some things are a lot easier than it is with DB, some things are harder.

replies(1): >>46194695 #
2. ahoka ◴[08 Dec 25 16:59 UTC] No.46194695[source]▶
Funny you mention that, because Kafka consumers actually pull messages.
replies(2): >>46197552 #>>46199337 #
3. politelemon ◴[08 Dec 25 20:55 UTC] No.46197552[source]▶
What is the reason for using Kafka then, sorry if I'm missing something fundamental.
replies(1): >>46200547 #
4. ycombinatrix ◴[08 Dec 25 23:47 UTC] No.46199337[source]▶
Not by busy waiting in a loop on a database query though.
5. pram ◴[09 Dec 25 02:22 UTC] No.46200547{3}[source]▶
A Kafka consumer does a lot of work coordinating distributed clients in a group, managing the current offset, balancing the readers across partitions, etc which is native broker functionality. Saying you can replace it all with a simple JDBC client or something isn't true (if you need that stuff!)