Дякую!
Цікава пропозиція, не розглядали на той час, не певен що ця річ була вже.
Бачу що там є обмеження по state, а також по join операціях. Нам би таке не підійшло.

і виглядає як те що робить Apache Flink. можливо у майбутньому перейдете на нього, якщо процесинг буде ускладнюватися

На жаль на проєкті вже не працюю =( Але як я писав Kafka Streams це тимчасове рішення для міграції, це не stream processing функціонал який нам потрібен. Тобто потреби у використанні stream processing у нас не було взагалі.

До того ж Kafka Streams як на мене швидше і простіше інтегрувати, те про що я згадував в перевагах.

Дякую, цікаво!

Особисто в нашому випадку достатньо Slack каналу було, там можна створити чергу в каналі і проставити дати та час для кожного елемента в черзі. Тобто ми просто додаємо запис в кінець черги і час скільки нам потрібно для тестування. В кінці як ми завершили просто тегаємо в чаті наступну команду і все.

Мені здається що дедікейтед апка для такого це забагато). Якщо немає адекватного корпоративного месенджера то на крайній випадок можна і Google sheets використати, правда не так зручно.

Дякую за коментар, дуже слушне запитання!

чи не буде проблемою, якщо таблиці дуже великі, відповідно треба локально розгорнути KTable теж доволі не маленький

Може бути проблемою, якщо є high-cardinality ключі. Тобто якщо дуже багато унікальних елементів в базі, під капотом вони будуть зберігатися на локальному диску інстансу Kafka Streams. Даних влізе стільки скільки є місця на жорсткому диску. Мені здається що там є retention policy для стану, кожен день видаляються старі дані. Також, RocksDB зберігає лише останній актуальний стан запису(по унікальному ключу) тому це треба мати прям серйозні об’ємми.

Ми пішли трішки іншим шляхом, під кожен інстанс для зберігання стану виділили в клауді EFS від AWS. Це дає швидший старт якщо інстанс впаде і треба підняти новий та збільшує розмір сховища.

якщо декілька зв’язаних записів оновилися у сорс базі в одній транзакції. Чи є гарантія, коли ми робимо Join через KTable, що отримаємо найбільш актуальний стан після коміту транзакції? Мені здається що ні, бо може статися що CDC для однієї з таблиць відпрацює швидше, а в KTable для зв’язаних таблиць ще будуть старі дані.

Взагалі немає гарантії, думаю що це проблема асинхронних систем в цілому. Така сама ситуація могла би виникнути якщо зв’язні дані контролються окремими мікросервісами.

В цілому, Kafka Streams може або почекати певний час і зробити join або взяти дані для join з свого локального сховища, про яке я згадував вище. Якщо подія ще не попала в Kafka-брокер взагалі як подія — то відповідно ніяк і не вийде зробити join, треба чекати.
В більшості випадків ми будемо робити join на найбільш актуальних даних які є або були в стані. Але є альтернативи:

• задати вікно, щоб Kafka Streams почекало певний період часу для JOIN. Звісно що вікна може бути недостатньо, проте наврядчи в нормальних умовах у вас будуть постійно затримки
• Знаю що ще додали фічу версійного сховища versionedkeyvaluestore

Для JOIN операцій важливо врахувати цей момент зі статті також:

Потрібно визначити та слідкувати за оптимальною кількістю partitions для топіків

Топіки можна джойнити лише за умови що вони мають однакову кількість partitions. Якщо ця умова не виконується, то Kafka Streams дозволяє зробити проміжний топік.

Взагалі для JOIN операцій є перелік вимог для топіків. в Confluence є ресурси де вони гарно описують ці моменти.

Дякую, радий що було корисно!

Добрий день.
Вас цікавлять деталі тестування, деплою та релізу чи процесу контролю умовного токену?
Якщо по деплою та релізу — то це нічого унікального, класичні GitHub Actions + ArgoCD, ну і ще пару інструментів.
А стосовно токену — то так як я описав. Команда брала токен коли були задачі на борді, які потрібно було тестувати на dev середовищі. Цей токен гарантував що лише ця команда може деплоїти на дев та в прод для того щоб уникнути конфліктів. Це все відбувалося в Slack каналі де були всі розробники моноліту та тім ліди.

Цікаво що за продукт, розкажете детальніше яку саме проблему він вирішує?