Провел System Design Interview для своего менти. Решали вот какую несложную на первый взгляд задачу:

В мобильном приложении нужно отобразить пользователю историю его заправок.

Откуда получаем данные? Сейчас есть 2 партнёра, они пушат в нашу систему заказы по REST API в разных форматах (но все необходимые и даже больше поля есть).

Каждый партнёр отвечает за разные сети заправок. Партнёров потенциально может быть много (десятки).

Пока функциональность довольно скромная, но инвестор верит в это направление, поэтому нужно сразу закладываться на развитие функциональности и рост нагрузки в будущем. Сначала ориентируемся на 100 rps на чтение и 1000 rps на запись.

Получившееся решение представлено на скрине. Запросы партнёров попадают в кластер через Gateway. Data Preparation Service приводит все сообщения к единому формату и пишет в Kafka. Если Kafka недоступна, то PostgreSQL выступает временным хранилищем для реализации паттерна Transactional Outbox. Fuel Stats Service перекладывает данные в MongoDB. Он же по запросу с МП через отдельный Gateway отдает список заказов по пользователю. В Redis на постоянной основе храним данные по заказам таксистов и временно заказы обычных пользователей. Инвалидацию проводим по событиям из Kafka. Для сбора аналитики User Stats Service вычитывает Kafka в отдельной Consumer Group.

Что получилось хорошо?
⭐️ Технологии в целом подобраны адекватно требованиям.
⭐️ Есть предпосылки для применения CQRS.
⭐️ Kafka при необходимости даёт возможность перечитать одни и те же данные разным потребителям, в том числе для целей аналитики.
⭐️ Redis значительно снизит нагрузку на БД.

Что можно улучшить?
🎯 Не храним сырые данные. Это значительно усложняет доработку функциональности в будущем. Недавно как раз писал пост на эту тему.
🎯 PostgreSQL в качестве fallback-сценария для Kafka не самый удачный вариант с точки зрения пропускной способности на запись. В первую очередь нужно уточнить возможность партнёра отправить сообщение повторно перед тем, как усложнять архитектуру решения.
🎯 Data Preparation Service может плохо переживать пиковые нагрузки, особенно если будет нагружен логикой/интеграциями.
🎯 Data Preparation Service потенциально нужно будет разделить под разные схемы сообщений от разных поставщиков при разрастании логики.
🎯 REST API, названия сервисов и модель данных требует дополнительной проработки.
🎯 Fuel Stats Service на будущее лучше освободить от обязанности перекладывать сообщения из Kafka для более гранулярного масштабирования.
🎯 Нужно рассмотреть альтернативы MongoDB, Kafka и Redis (например, Cassandra, NATS/Pulsar, Hazelcast/KeyDB/Valkey) с точки зрения возможностей API, консистентности чтения, пропускной способности на чтение/запись, простоты организации кластера.

Кажется, что замечаний много, но они достаточно быстро закрываются при должной практике. Так что не упускайте возможность при случае заархитектурить новую сложную фичу 😎

P.S. Поздравляю всех с окончанием длинной рабочей недели. Хорошо, что на сегодня я взял отпуск🤣.

Давно нужно было это сделать, но всё руки не доходили... Начал изучать Python.

До этого, конечно, приходилось писать небольшие скрипты, но этот процесс сопровождался непрерывным гуглением синтаксиса. А ведь Python теперь знать обязательно — это базовый язык для AI ML. "Spring AI есть!" — скажете вы. Но он значительно отстает от мирового стандарта...

По рекомендации прошел бесплатный курс от Hexlet по базовому синтаксису. В экспресс-режиме (около 5 часов) прошел все 76 занятий. Очень понравилось! Если и другие курсы от Hexlet такие же последовательные и проработанные, то не могу не позавидовать тем, кто вкатывается сейчас в айти.

Сам я вкатывался в C++ и Java по легендарным книгам C++ за 21 день и Java. Руководство для начинающих больше 10 лет назад. Каждую из них осилил в период летних каникул дней за 30 (по 8-10 рабочих часов каждый день), выполняя все практические задания. Это был настоящий ад 😕 Впоследствии еще 2 раза перечитывал книгу по Java, каждый раз находя новые для себя нюансы, которые не мог воспринять в предыдущих итерациях.

А у вас как быстро получилось первые навыки получить?

P.S. В контексте прохождения курса по Python показалось забавной фраза:

Этим языки программирования отличаются от разговорных языков: здесь нет места для интерпретаций.

Fluentd, или «Король умер, да здравствует король!»?

Последнее время настраивал пайплайны для работы с логами на Fluentd. Что это за зверь?

Fluentd is an open source data collector, which lets you unify the data collection and consumption for a better use and understanding of data.

Fluentd входит в список Graduated-проектов CNCF (Cloud Native Computing Foundation), что очень престижно и приносит много денег (крупные компании готовы внедрять инструмент, развивать его и платить за поддержку).

Это было не первое мое знакомство с этим инструментом, но точно самое плотное. Буду честен, оно мне не понравилось 🤣 Казалось бы, просто имхо, но сейчас в индустрии прослеживается тенденция по переезду на другие коллекторы логов.

Fluentd в своё время отжал часть рынка у жирного JVM-based Logstash'а. Теперь, кажется, пришло и его время ⛽️ У меня на слуху Vector, Fluent Bit (младший брат Fluentd), OTel (OpenTelemetry) Collector, но есть и другие.

Что не понравилось лично мне?

1. Поверхностная документация. Началось знакомство с того, что в разделе с документацией есть вкладки с версиями 0.12 и 1.0, хотя подразумеваются 0.12 и latest (сейчас 1.19.1). Как об этом догадываться?

Документация, наверное, не самая плохая из того, что я видел, но в то же время постоянно заставляла искать статьи, ответы на stackoverflow и примеры на GitHub. Всё бы ничего, но...

2. Помимо документации в сети очень мало материалов. Как будто технологией пользуется полтора землекопа. Но ведь это де-юре актуальный стандарт! Вы скажете, что я разучился гуглить. Но...

3. Нейронки тоже не справились. Последние Qwen и ChatGPT на простейшие запросы подсовывали абсолютно нерабочие конфигурации. Мне приходилось настойчиво указывать на их неправоту, о которой они забывали уже через сообщение. Видимо, дело все же не во мне. Одной из возможных причин можно считать то, что ...

4. Плагины написаны вразнобой. Снимаю шляпу перед разработчиками Fluentd, которые сделали возможность расширять функциональность плагинами. За 10++ лет их написали великое множество, но не все из них хорошо описаны и гибки в настройке. Получился настоящий зоопарк.

Например, не все input-плагины поддерживают проставление тега (tag), приходится вертеться с лейблами и rewrite_tag_filter. Один input-плагин поддерживает несколько путей через запятую и шаблонизацию, другой — только один и без шаблонов. Некоторые параметры поддерживают динамические конфигурации, а некоторые — нет. Проверять это часто приходилось методом научного тыка.

Но это все, конечно, просто неприятные мелочи, которые кажутся неприемлемыми для проекта такого уровня. Хотя, если все бы было хорошо, то кто бы платил за поддержку такого простого инструмента 😃?

Основное же, с чем мне пока не пришлось столкнуться, но что точно волнует индустрию, это...

0. Ruby и производительность

Fluentd и плагины написаны на Ruby (очень грубо — интерпретируемая Java со всеми слабыми сторонами использования виртуальной машины). Первый коммит на GitHub датируется аж 19 июня 2011 года.

Нагрузка на коллекторы логов с тех пор выросла на порядки. Насколько я понял из тестов производительности, Fluentd с ней справляется, однако потребляет значительно больше ресурсов: 1 и 2 (чуть ли не единственное, что удалось найти кроме явного упоминания в документации Fluent Bit). Уровень ссылок, конечно, не впечатляет, но считывается именно такое настроение.

Примерно по той же причине мы в свое время уходили с Hazelcast на Redis: уж очень большой оверхед привносит виртуальная машина + у Redis больше коммьюнити и он более активно развивается.

Менеджмент вовремя подсуетился и ещё в 2014 году вышел Fluent Bit — более производительный и менее ресурсоемкий младший брат главного героя, написанный на C. На главной странице Fluentd в самом верху красуется баннер со ссылкой на обучение в Fluent Bit Academy, а в блоге CNCF недавно вышла статья от мейнтейнеров Fluent Bit с migration guide. Не знаю как, но Fluent Bit тоже считается Graduated-проектом (under the umbrella of Fluentd 😐). Как это возможно для двух разных программных продуктов? Непонятно 💸, хотя продукт хорош.

Апдейты!

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

1️⃣ В дополнение к Qingping Air Quality Monitor первого поколения приобрел монитор второго поколения

Напомню про хороший обзор здесь. Что изменилось?
* поставили более продвинутые сенсоры CO2 и VOC (летучие органические соединения)
* в дополнение к сенсору твердых частиц до 2.5 микронов PM2.5 добавили сенсор PM10 (до 10 микронов)
* в целом сенсор PM теперь заменяемый (в первой модели он приказал долго жить), даже нашел его на Ali
* появилась возможность подключить к Алисе (еще не проверял)
* увеличили экран почти на дюйм (разница колоссальная)
* добавили измерение уровня шума (ок, пусть будет)
* в целом появилось больше гибкости в настройке

Пока они оба стоят у рабочего места (сверяю показания), но потом один из них переедет в спальню.

2️⃣ В спальню и кабинет поставил бризеры

Остановился на Тион 4S. Удовольствие не дешевое, но теперь нет необходимости постоянно открывать/закрывать окна или выверять щель для проветривания, чтобы впустить свежий, но очень холодный воздух (функция подогрева воздуха прекрасно справляется со своей задачей). Ночью теперь тоже спать очень комфортно. На второй скорости (из 6) бризер практически не слышно, но показатели CO2 остаются в норме.

3️⃣ Начал активнее пользоваться увлажнителем воздуха, чтобы не сушить слизистые

Несмотря на то, что относительная влажность (ОВ) воздуха на улице зимой может быть высокой (90%+), абсолютная влажность воздуха остается очень низкой из-за низкой емкости холодного воздуха. При нагревании в помещении такого воздуха ОВ снижается ниже комфортных 40%+.

На что тут стоит обратить внимание при выборе?
* тип увлажнения (ультразвуковые / естественного типа)
* как мыть / обслуживать
* за счет чего обеспечиваются антибактериальные свойства (серебряные картриджи / добавки в воду / антимикробные фильтры / УФ-лампы)
* объем бака с водой (как часто будете доливать воду)
* производительность под вашу квадратуру
* шум в ночном режиме и соответствующая производительность (к сожалению, почти нигде не афишируется)
* расходные материалы и их наличие в продаже

Мне верой и правдой трудится купленный более 5 лет назад iClima LUX-8000. Для того, чтобы реже его обслуживать (основная проблема всех увлажнителей воздуха) докупил серебряный стержень от мойки другого производителя.

Тут отмечу, что ультразвуковые увлажнители сложнее держать в чистоте. Они испаряют все, что в них налито, поэтому антибактериальный эффект можно достичь только (?) с помощью УФ-лампы. С учетом всего перечисленного перспективно выглядит их новая модель. Еще из интересных вариантов могу отметить Boneco, Venta, Stadler Form и Panasonic. Но, конечно, понимание об удачности той или иной модели приходит только по итогам эксплуатации хотя бы в течение сезона.

4️⃣ Поставил умные терморадиаторы на батареи.

Теперь есть возможность более точно регулировать температуру и делать спальню на ночь более прохладной.

Чувствую себя прекрасно, чего и вам желаю! Крепкого здоровья, всех благ ❤️

Все же заметили, что пошел повальный тренд внедрения геймификации? Многие любят играть в компьютерные (мои любимые — серия Command & Conquer: Red Alert и первая Stronghold Crusader), мобильные и браузерные игры, чувствовать азарт, наблюдать за своим прогрессом, выигрывать. Значит этими нашими слабостями можно воспользоваться, чем и пользуются индустрии 👉

Для меня это особенно заметно в мобильных приложениях маркетплейсов и банков. Понятно, почему: у них есть большие бюджеты и в то же время плотное взаимодействие с партнёрами-продавцами. Крючки могут быть самыми разными: кэшбэки, скидки на товары, розыгрыш ценных и не очень призов и т.д.

При этом механика для завоевания внимания пользователя и его свободного времени обычно довольно "ядовитая" — задания и награды появляются каждый день, соответственно от вас требуется ежедневная активность. "Электронные" адвент-календари под Новый год — самый яркий пример. Даже не представляю, насколько выросли метрики DAU и время, проведенное в приложениях у тех, кто успел подсуетиться.

Признаюсь, сам грешен. Друг работает в Telegram — скинул в конце ноября мне их предновогоднюю игру Gift Fest, в которой можно выиграть реальные деньги. И я выиграл:

Поздравляем, ты выиграл в Розыгрыше №3 Wallet Акции и Фонды — $1 в токенизированных акциях (TSLAx, AAPLx, NVDAx, GOOGLx)!

Точно стоило потраченного времени 😃 Простые механики + азарт сделали свое дело. Эта игра хоть и сжигает время, но достаточно безобидна.

А вот кэшбэки и промкоды в банках и маркетплейсах, на мой взгляд, опаснее. В голове пользователя начинают постоянно проскальзывать мысли: "А ведь я могу получить хороший кэшбэк на товар, который мне нужен. Это не требует от меня почти никаких усилий, но сэкономит заработанные большим трудом деньги". Это побуждает все больше времени тратить в приложении, чтобы заполучить выгоду. Обычно установленных банковских и приложений маркетплейсов несколько, что усугубляет ситуацию: "Сейчас я найду, где максимальная скидка на эту подписку. Я точно где-то её видел. Не могу же я её упустить."

Это начинает напоминать лудоманию: один раз удачно получилось "выиграть" на покупке — и мозг ждёт повторения чуда. А "подкормить" нас несложно: по истории покупок можно достаточно точно подсовывать персонализированный кэшбэк.

Ещё заметил, что некоторые сервисы, если ими пользоваться точечно, проводя лишь избранные транзакции, будут долго и упорно подсовывать очень выгодные предложения, пытаясь переманить вас на свою сторону.

Кажется, немало людей уже заработали тревожность от недополучения часто эфемерной прибыли. Неудивительно, что даже термин для этого есть — FOMO, Fear of Missing Out — синдром упущенной выгоды / страх пропустить что-то интересное.

Нужна ли нам вся эта гонка или лучше вложить свои силы в что-то более важное?

P.S. Осталось только выгодно подарки все под Новый год купить 💳

Постепенно выхожу из зимней спячки. Мысли пришли в движение, и я наконец понял для себя, за что люблю Новый год.

Перелистывание календаря в этот день для многих — событие, которое наполнено особым символизмом. Люди в этот день делятся теплыми пожеланиями и ставят цели. И эти цели обычно про то, как стать лучше в следующем году.

«Я должен подставить в этом году ещё больше людей», «в этом году я хочу разочароваться в людях окончательно», «мои ошибки в этом году должны стать фатальными». Ничего подобного я никогда не слышал, по крайней мере вслух.

И не так важно, что большинству поставленных амбициозных и не очень целей не суждено сбыться по самым разным причинам. Некоторые забывают о них буквально первого января или в лучшем случае сразу после праздников. Важен сам факт: для многих это возможность на момент остановиться и задуматься, куда стоит идти дальше, чем заниматься и как жить...

Вообще-то этим можно заниматься не привязываясь к конкретной дате, которая наступает неизменно, но всего раз в году. Просто так принято. И это, как по мне, уже неплохо.

А Новый год я люблю за длинные выходные 😃

Почему каждый раз не делают собственное (простое / понятное / маленькое) решение, а берут Open Source?

Мы в банке часто пишем свои стартеры, библиотеки, боты и т.д. Хорошо ли это? Предлагаю обсудить.

1️⃣ Нет универсальности

Универсальность — обоюдоострый клинок. С одной стороны заточенное под решение нашей задачи ПО будет лучше справляться (по крайней мере после нескольких итераций разработки 😃) с этой самой задачей. С другой стороны любой шаг в сторону от исходной проблемы, о которой мы ранее даже не могли подумать, может потребовать значительной переработки архитектуры / кодовой базы исходного решения. Взрослый Open Source уже прошёл через все эти грабли, так как используется многими командами для решения разных задач со своими ограничениями.

2️⃣ Нет "бесплатных" мейнтейнеров

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

Разработчики обычно не любят вникать в очень специфичные решения, которые более нигде, кроме как в вашей компании не используются. Будет проще, если это библиотека, которая решает распространенные задачи по типу кэширования / логирования / работы с БД и т.п.

3️⃣ Ограниченное коммьюнити

Вы будете чуть ли не один на один со своей проблемой, как с точки зрения разработки, так и с точки зрения эксплуатации. Хорошо, если вокруг внутреннего решения организовалось сильное комьюнити, которое подскажет и может подхватить написание кода. Если внутренний заинтересованный мейнтейнер всего один, то велика вероятность, что без него всё развитие проекта сойдёт на нет.

4️⃣ Вы всегда альфа- или бета-тестер

Обычно новые внутренние решения проходят процедуру "пилота", когда на нескольких командах-добровольцах отлавливаются детские проблемы. Моя команда много раз в числе первых подключала новые библиотеки, сервисы, процессы и т.д. И каждый раз это была боль, которую нам приходилось перетерпеть: это и падающие тесты, и несостыковки контрактов, и баги, из-за которых съезжал релизный цикл. Радует то, что мы до сих пор используем все те решения, они показали свою состоятельность. Но и флэшбэки одолевают нас до сих пор 😢 А прямо сейчас правлю баг в библиотеке кэширования на стыке near-cache и синхронизации записи несколькими потоками по одному ключу... Кстати, этому багу год, но нарвались в проде на него почему-то только сейчас.

5️⃣ Вопросы безопасности

Безопасная разработка — по сути отдельная высокооплачиваемая профессия профессия, которую надо бы иметь всем, но большинство разработчиков имеют слабое (ограниченное) представление. Почему? Это сложно → таких людей мало (а задач много) → они занимаются своими узкоспециализированными вопросами, на всех их не хватает.

Понятное дело, что Open Source тоже дырявый, но он больше челенджится энтузиастами и становится лучше. Внутренние решения могут игнорировать этот аспект вовсе. И уж точно сложно представить, что кто-то пойдет пилить свой легковесный аналог Keycloak'а.

———

Тем не менее внутренние разработки должны быть. Мы упростили множество процессов и рутины благодаря им. Со временем плохие / невостребованные решения отмирают, а хорошие — приживаются и эффективно решают поставленные задачи, часто сами перерастая в Open Source решения.

На работе прилетело несколько интересных задач. Сегодня поделюсь одной из них.

Саппорт (функциональное сопровождение) прода пришел с жалобой на то, что алертинг, настроенный на логи, не может нормально работать. Причина простая: у большинства документов в Elasticsearch (ES), который мы используем как хранилище логов, по одной и той же ошибке (один и тот же logger.error(...) в коде) разное значение поля message.

Почему так происходит? В поле message кроме непосредственно описания происходящего мы часто фиксируем уникальные идентификаторы / параметры / свойства (и т.п.) важные для последующего анализа. И именно по этому полю не😃 происходит группировка сообщений с последующим не😃 срабатыванием настроенных алертов. С причиной разобрались: сообщения разные, а значит в одну группу они не попадут.

Важно отметить еще один неприятный побочный эффект. Если посмотреть на то, как работает ES, то, очевидно, мы получаем распухшие индексы и медленные агрегации.

Как решить проблему? Убрать лишнее из message. Совсем? Потеряем в информативности. Тогда вынесем "лишнее" в отдельное новое поле документа по аналогии с тем, как это делают с userId и traceId и другими. Как его назвать? Мне пока нравится универсальное context, так как содержимое от лога к логу в среднем будет абсолютно разное.

Раз уж придется лезть в эту историю, то как будто хочется заиметь еще одно поле, которое будет отвечать за категорию (идентификатор) проблемы. Каждая категория — отдельный код. Мы заранее составляем справочник таких кодов и в логах используем их. Один и тот же код может использоваться сразу во многих местах для однотипных ситуаций. Кажется, что это должно быть удобно как для алертинга, так и для анализа, в т. ч. построения дашбордов. Надо подумать 🎹