We love cloud-native solutions almost as much as we love our legendary buckwheat baguette. Apart from that we do love to share our experience. Check out the story of building a nation-wide solutions to service millions of Silpo, Fora and other businesses Guests daily. By taking an example of our new Commodity Accounting Platform (CAP), we will showcase technologies and processes we use and why, and finally - the challenges we overcome. Let’s make Ukraine great again, together!

1. Як українська компанія
Fozzy Group будує
next gen cloud-native
платформи
Еволюційна архітектура

2. Fozzy Group: Факти
Fozzy Group - одна з найбільших торгово-промислових груп України.
та інші
350+ супермаркетів 300+ магазинів
біля дому
90+ маркетів 7 гіпермаркетів 90+
аптек
А також Логістика, e-com (доставка «Сільпо» та LOKO), онлайн магазини Maudau та E-Zoo, власні виробництва та
50 000+ працівників Fozzy Group є користувачами наших продуктів.

3. TEMABIT: Хто ми?
TemaBit - українська IT компанія, яка є частиною Fozzy Group
Про нас в цифрах:
10+
років досвіду
1 300+
працівників
02
центри
розробки
R&D
центр
Ми змінюємо користувацький досвід українців і втілюємо
сміливі рішення для групи компаній Fozzy Group

4. Ми змінюємо користувацький досвід українців і втілюємо
сміливі рішення для групи компаній Fozzy Group
Хто я?
Сергій Медведєв
Chief IT Architect Fozzy Group
Керівник Департаменту IT Architecture Temabit
• Підвищене серцебиття від технологій в IT вже 20+ років
• Пройшов довгий шлях в різних доменах від інженера до архітектора
• У 2015 році перейшов у сферу розробки програмного забезпечення як
Enterprise Architect
• Починаючи з 2022 року, поєднував контрактну роботу Enterprise
Architect з посадою CTO в рамках власної компанії apricusit.com
• З 2023 року в Fozzy Group

5. Нова cloud-native Платформа Товарного обліку
(Commodity Accounting Platform - CAP): ДЕ, СКІЛЬКИ, ЧОГО (якого товару)
в кожний момент часу
BUSINESS CASE

6. Near real-time відповіді на питання ДЕ, СКІЛЬКИ, ЧОГО в
розрізі
✓ Артікулів (Article)
✓ Артікулів по businessUnit чи Store Location
в кожний момент часу
Expected result:

7. ВИКЛИК В ЦИФРАХ
1 300+ Магазинів, РЦ,
Складів
300+ Машин
Факт від «Сільпо»:
• в середньому, 10 000 000 транзакцій по переміщенню Article/день
• 25 транзакцій/сек при піках в 2-3 рази більше
Challenges:
• Технічна: як відслідкувати зміни кількості по кожному Article?
• Логічна: як забезпечити правильну послідовність обробки переміщень товару?
• Інфраструктурна: як забезпечити performance?
СКІЛЬКИ?
ДЕ? ЧОГО?
250 000+ артикулів
(тільки в Сільпо)
• Продали?
• Везуть?
• Залишилось?

8. Architecture: helicopter view

9. ES + CQRS = рішення
Architecture: гіпотеза

10. Трохи теорії: ES and CQRS

11. • Яка сутність буде агрегатом?
де бізнес логіка?
• Яка "глибина" агрегату?
Швидкість "завантаження" state? Cost?
• Як робити "build"/"rebuild" проекції?
Performance and cost
ES + CQRS: ключові питання

12. DDD and CQRS in action...
ПОШУК ВАРІАНТІВ РІШЕННЯ

13. Крок 1: "в лоб"
✓ Кожен Article – агрегат
✓ Raise events змін по Article
+ businessUnit
✓ Побудувати проекції:
по кожному businessUnit+ Article
по кожному Article
ІДЕЯ
Кількість events і обробок:
10 000 000 x2 це min
Місяць: 30 x (10 000 000 x 2)
=
600 000 000 events/
month

14. Артикул – агрегат
PROS
• Точність в розрізі Article
• Велика ступінь гнучкості
• Швидко обробляється
CONS
• С точки зору бізнесу: обробляються не Article, а документи - потрібна
розподілена транзакція + щось про документ
• Велика "глибина" ES агрегатів - важко "піднімати" стан
• проблеми rebuild проекцій - compute intensive, довго

15. ПРОБЛЕМА:
бізнес обліковує ДОКУМЕНТИ, а ми побудували events в
рамках АРТИКУЛІВ... невірний DDD

16. Крок 2: Документ - агрегат
✓ Кожен документ – агрегат,
i.e. container "операцій"
✓ Raise events змін по Article +
businessUnit
ü Будуємо проекції:
• по кожному businessUnit+
Article
• по кожному Article
✓ Повна зворотна сумістність
по "read"
ІДЕЯ

17. Документ - агрегат
ЗМІНА
PROS
• Документ обробляється атомарно
• Велика ступінь гнучкості
• Не "глибокий" агрегат
CONS
• Немає гарантії "послідовність" обробок по Article (вони тепер в різних
документах)
• проблеми rebuild проекцій - послідовна обробка events
Кількість events і обробок
(min):
600 000 000 events/month

18. ПРОБЛЕМА:
як гарантувати ПОСЛІДОВНІСТЬ events в рамках
АРТИКУЛУ, якщо вони приходять з РІЗНИХ типів
ДОКУМЕНТІВ в паралелі?

19. ПОТРІБНА ЗМІНА АРХІТЕКТУРИ...
щось, що гарантує послідовність і паралельну
обробку

20. Трохи теорії: Stream Processing

21. ✓ Кожен документ – агрегат
✓ Raise events створення і
змін документів
✓ Розбираємо документ на
операції і відправляємо в
Kafka Streams як events
(stateful)
✓ Topic per article
✓ Будуємо проекції в Kafka
Streams (stateful)
ІДЕЯ
Крок 3: "Революційна" еволюція

22. PROS
• Документ обробляється атомарно
• Точність і гарантія послідовності в розрізі Article
• Велика ступінь гнучкості
• Супер швидко обробляється - в паралелі per Article
• Не "глибокий" агрегат
CONS
• Складніша інфраструктура
• Складніша розробка - потрібен інший mindset
ES + CQRS + Stream Processing

23. Ключові технології
martendb.io
ES:
martendb.io
CQRS:
wolverine.netlify.app kafka.apache.org
Stream
processing:
aws.amazon.com
Cloud:

24. Реальна архітектура

25. Evolutionary architecture is an approach to build software
that's designed to evolve over time as business priorities
change, customer demands shift, and new technologies
emerge.
Останній слайд
ДЯКУЮ!