Vlákno názorů k článku Proudy (streams) podporované systémem Redis od atarist - Redis je hodně symatický systém jako key-value storage,...

Redis je hodně symatický systém jako key-value storage, ale snese Streams srovnání například s Kafkou? Proč se ptám - Kafku používáme, ale devops team má pořád nějaké problémy se stabilitou a výpadky. Navíc naše retention policy je pár desítek hodin (48 atd.), takže by takový "nápor" klidně mohl zvládnout i Redis, který tam stejně už máme jako cache.

Používá prosím někdo ze čtenářů Streams aby mohl nakopnout, jestli je to doable a dobrý nápad?

jen pro info - máme cca 1-2 zprávy za sekundu, každá zpráva cca 200 bajtů, takže z dnešního pohledu nic moc provoz.

Pokud jde čistě o výkon, tak je Redis víc než dostačující. Provozuju jednoduchý "broker" v Redisu 4, tzn. pomocí lpush/rpop s provozem přes 3000 zpráv za sekundu (komunikuje tak pár microservices, takže takových front je na jednom serverů několik).
Pochopitelně, nejsou dostupné další pokročilé vlastnosti (potvrzení doručeni, generovaní id, fan-out apod.). Ale právě kvůli efektivitě jsem přešel z RabbitMQ na Redis.

Neviem ci to myslite vazne ale 1-2 spravy za sekundu mozete ukladat do vzdialeho Oracle clustra beziaceho na RaspberryPi.
Ak chcete vyskusat nieco ine skuste este Apache Pulsar ale teda pri tom loade co pisete fakt mozete pouzit aj relacnu DB s ACID TX, stale to bude stihat.

No právě, 1-2 zprávy za sekundu není žádnej extra datovej tok a přece jsou tam pořád pro mě nepochopitelné výpadky a rebalancing konzumentů (ale to je problém trošku někde jinde). Samořejmě může být problém ve stylu depoymentu (to neovlivním - jinej tým v jiné geolokaci, který to prý MUSI dělat), ale stejně bych měl rád v záloze nějaké lehkotonážní řešení stylu Redis.

PS: to, že se o infra služby stará jiný tým, by teoreticky mělo být pro nás lepší a méně náročné, ale mnohdy je tedy opak pravdou.