Kafka Is Dead, Long Live Kafka

Re:Kafka Is Dead, Long Live Kafka by regularfry on Wednesday August 09, 2023 @04:28AM (#37060017)

This is where the "or persistence" bit comes in, but the trade-off isn't as you describe. One way to approach it would be for B to set a flag against the user in the database they must already have, because they have users so that A can process password resets on its own schedule. It's add a column versus add a message queue. Databases already come with locking primitives and well understood patterns, no reinvention needed.

[ Parent | on HN ]

Re:Kafka Is Dead, Long Live Kafka by valenterry on Wednesday August 09, 2023 @09:29AM (#37062370)

You are now assuming that they indeed have a database nd store users in there, and not use a 3rd party system that might not even allow to attach meta data (or at least make it difficult).

[ Parent | on HN ]

Re:Kafka Is Dead, Long Live Kafka by regularfry on Wednesday August 09, 2023 @11:47AM (#37064443)

In which case why is the password reset my problem at all?

But even if I've handed off identity management entirely, I almost certainly do have some per-user state. Otherwise... what on earth am I doing with users in the first place?

[ Parent | on HN ]

Re:Kafka Is Dead, Long Live Kafka by valenterry on Wednesday August 09, 2023 @12:43PM (#37065316)

Well, maybe because the 3rd party service is not reliable or you want to send an additional mail.

But okay, fair point - password-reset is maybe not the greatest example. But it doesn't invalidate the general point (I gave a couple of other examples).

> Otherwise... what on earth am I doing with users in the first place?

Maybe just making sure that the user is known and has paid for plan X (if the 3rd party service offers that).

[ Parent | on HN ]