окрім посилань на статті, є рекомендації по книжкам, по підготовці, по пет проджектам.

Пошук першої роботи суттєво спроститься якщо дійсно багато вчитись.

— Solidgate != Genesis.
— Курси != єдиний спосіб отримання роботи.
— Ідея статті — треба навчитися вчитися — найкращий спосіб отримати роботу.

Ви трішки незрозуміли. Ми не використовуємо час оредрінгу в стрімах, чи не генеруємо час на стороні сервісу якщо на цей час треба орієнтуватись бо це призводить до Clock skew. Дані зберігаємо насправді ще з 2016 року і по аудитам все проходимо.

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

але це вже треба вивчати і тюнити клієнт яким користуєтесь для обробки повідомлень.

ніхто ж не звинувачує клієнт, просто на цьому дуже легко спіткнутись, це треба конфіжити. Лінк на issue вище.

Та ні, можна дуже легко потрапити на це: github.com/...​entio/kafka-go/issues/764

Стикались з цим же: github.com/...​entio/kafka-go/issues/764
Вичитка батчем в пам‘ять, помилка, але fetch працює далі. Треба заводити або «DLQ», або ще правильно конфіжити клієнт та правильно ретраїти.

я краще пошукаю лінк на код клієнта, скину пізніше)

Здавалось би що таке 7 RPS. Виходить що результуючий об‘єм не такий маленький.

7*60=420 транзакцій за хвилину.
10 000 / 420 = 23$ транзакція.

Судячи з данних наприклад Візи середній чек суттєво вище, що в цілому підтверджує цифри як такі: marketing.dynamicyield.com/...​arks/average-order-value

Чому? Є всі дані щоб приблизно порахувати середній чек)

Вместо того чтобы использовать готовые решения, с которыми нужно научиться работать, развлекаетесь написанием своих собственных.

Іноді необхідно стикнутись з коренем проблеми, вирішити його замість використання вже готового інструменту. Якось треба набувати досвід і вчити команду вирішувати складні проблеми до того як вони стануть не просто складними але ще й критичними. Аргумент фіговий, погоджусь, але можна я б це порівняв як «вирішувати Leetcode» та «вирішувати Leetcode проблеми в реальних задачах». Логіка була такою.

Не всі проблеми вирішуються таким підходом. Треба балансувати.

Это ж вы решили использовать СУБД в качестве очереди?

ми вирішили лише організувати append log для відновлення станів в бд.

WAL в СУБД работает правильно,

Я не кажу що він працює невірно. Я лише кажу що транзакції потрапляють в WAL лише після коміту, це факт що вже призводить до перегляду роботи з Debezium.

Правильно ли я понимаю, что когда вы говорите о времени начала транзакции

ми не використовуємо час, це ж звичайна проблема з Clock Skew. В тому прикладі я відобразив чому транзакції в реальному часі можуть не потрапити в WAL в порядку виникнення, а потрапляють в порядку коміту.

Так ви ж пропонуєте рішення під інший концепт замість запропонованого в статті)

Вибачте, не розумію до чого взагалі Pub/Sub якщо річ про Streaming. А це різні концепти.

Тоді пишіть в LI, з радістю і онлайн зустрінусь)

Готовий обговорити простіше рішення)

Ще Kafka clients можуть не гарантувати порядок бо працюють вони часто батчами. Вичитування повідомлень може бути батчем і якщо 1 месседж не опрацювався то в обробку може потрапити наступний, але це вже треба вивчати і тюнити клієнт яким користуєтесь для обробки повідомлень.

++

Внизу відповідав, є власні бакети і під кожен є сіквенс. Як відновлювати порядок — все є в данних стріму. Ми опираємось на кафку в цьому лише мінімально.

1. Все так. І ми до цього також йдемо, але не в тему щоб використати Debezium а щоб зробити щось простіше ніж Debezium, не на Java а на Go. Debezium також не гарантує порядок, бо він читає WAL а в WAL транзакції пишуться після коміту, не на старті. Відповідно ордерінг в WAL не гарантується. В PostgreSQL механізм реплікації має ордерінг буфер, але і він не вирішує проблему непослідовних комітів. Перша транзакція стартує в 10:00:00, закінчується в 10:01:00, друга транзакція стартує в 10:00:30, завершується в 10:00:40. В WAL вони попадуть коли будуть комітитись і відповідно порядок вже порушений, для цього використовується ID(ulid/autoincrement) і резервується він на старті транзакції, не на коміті.

Debezium має 2 проблеми:
— За ним складно слідкувати бо всунути метрики в необхідні місця попросту неможливо.
— Ніхто не знає як він працює і чому падає. Відновлення роботи дебезіуму це звичайний рестарт.

2. Тут відповів: dou.ua/...​0318/?from=slider#2875650
3. Наша, Payment gateway генерує дані, не приймає. Падіння бази = зупинка проведення карткових транзакції і подальша їх дистрибуція. Але для цього стріми і завели, історичні дані інші консь‘юмери можуть вичитувати зі стріму. Відмовостійкість платіжного гейту це прям велика окрема історія, яка повинна бути окремою статтею.

Без обид, но по-моему архитектура «сыровата» и требует переосмысления.

ніяких образ, якось пересічемось на FWDays/Dou івентах і обговоримо голосом)