StringConcat - разработка без боли и сожалений

OpenAPI: странности required Недавно столкнулись с интересным моментом при работе по Api-first с OpenAPI. В спеке может присутствовать секция required, которая вроде бы должна строго указывать обязательные поля:

required:
  - field1
  - field2

Но если указать несуществующие поля — генератор всё равно сгенерирует клиент и сервер, без ошибок и предупреждений. Некоторые генераторы вообще позволяют писать required рядом с полем — и клиент всё равно учитывает семантику правильно (но при этом другие генераторы вообще отказываются работать с такой спекой, ибо не канон). Ситуацию можно исправить Redoc CLI. С его линтером можно проверять спеку ещё до генерации и ловить такие моменты, как например required, который ссылается на несуществующие поля (есть даже набор рекомендованых правил). Вроде полезная штука Но, честно говоря, от OpenAPI генераторов хотелось бы побольше строгости и поменьше разночтений относительно структуры спеки

Просматривая комментарии к видео, бросились в глаза фразы вида «Да я тут целый магазин сгенерил, че ты мне тут свистишь, всё работает» Давайте-ка вспомним, чем отличается промышленная разработка энтерпрайз-монстров от MVP (кстати, я подчеркнул, что речь именно про промышленную разработку — но, похоже, это пролетело мимо ушей): 1. Энтерпрайз — это всегда легаси. Легаси не значит плохо, это значит, что вы имеете дело с кодом, который работает уже десятки лет. Никакого контекста не хватит, чтобы впихнуть кодовую базу. 2. Есть вопросы безопасности — куда и что отправляет этот ваш модный Курсор? 3. В таких проектах есть процесс работы с продуктом: планирование, ревью, тестирование, деплой. Написание кода — лишь маленькая часть, и она далеко не самая длительная. 4. Помимо функционала есть требования к качеству ПО: стабильность, поддерживаемость, безопасность. Любое изменение — это риск. Сносить всё и перегенерить заново нельзя, иначе придётся проходить весь процесс заново. 5. Как насчет мониторинга и поддержки? MVP точно предоставляет все метрики, настраивает алеры и т.д.? 6. Технический долг — отдельная тема, накапливается очень быстро, и маленькие изменения через полгода могут остановить всю команду. То на что можно забить в MVP будет неприемлимо в промышленной разработке (хотя кого я обманываю, просто на работе подольше посидите, кек). 7. Обратная совместимость — еще одна причина почему нельзя все снести и построить заново. 8. Экономическая сторона — сколько стоят токены, запросы к ИИ, ресурсы? Какие вычислительные мощности нужны, кто их обслуживает? За чей счет банкет? Наверное еще что-то есть, и вот эти вопросы не позволяют просто взять и впердолить ИИ в уже существующие процессы, хотя прогресс конечно есть и он приведет к определенным изменениям, как мы писали раньше. Но перед этим нужно пройти немалый путь. В связи с этим нам интересно: знаете ли вы большие вайбкод-проекты, которые лежат в общем доступе? Может, вы сами участвуете в таких проектах? Напишите в комментариях — если найдём что-то интересное, можно будет сделать разбор

Вот, кстати, отличная иллюстрация наших разговоров. Серёжа Баранов за короткое время запилил вполне немаленькую тулзу — десятки тысяч строк кода, всё выглядит рабочим. Но если копнуть внутрь, сразу вылезают вопросы по безопасности, ограничениям, NFR и архитектуре в целом. И опять выясняется: нужно понимать весь процесс разработки целиком, а парой тысяч строк кода эти проблемы не дописываются. LLM сильно ускоряют разработку, но «работает» ≠ «готово к продакшену».

А еще есть сомневающиеся в возможностях llm :) 10 минут моего времени 35k строк кода на бэке 40k строк кода на фронте Сказка… а теперь берем эту сказку и SAST’ом по ней • XSS через SVG • allow_methods=["*"] и allow_headers=["*"] • Отсутствие rate limiting • Отсутствие лимитов на размер данных • Race conditions в глобальном состоянии • description может содержать небезопасные данные • нет логирования действий пользователей Ну и понятное дело NFR’ы неизвестны, нужно под нагрузкой подержать, помасштабировать и… что если не держит продукт нагрузку? Нередко строчки кода тут не помогут и Claude тоже в вопросах архитектуры пока не может помочь (дело времени, но пока не может). Поэтому я и говорю – архитектура/дизайн вышли на первый план, ну иначе я не знаю как получить рабочее решение, чтобы оно NFR’ам удовлетворяло.

А вот и обещаный видосик, если кто еще не видел. Приятного просмотра! YouTube | ВК

Несколько лет назад, когда мы только начинали наш любимый пет-проект StringConcat и делали небольшое референсное приложение, у нас была простая и наивная мечта — как было бы круто, если бы можно было автоматически генерировать содержимое классов. Со структурой проблем не было, а вот наполнение - никак (никаких GPT тоже и в помине не было). Прошло несколько лет и благодаря DDD, чистой архитектуре, собственному небольшому фреймворку, ИИ-агентам и большому количеству выстраданных правил, мы за вечер делаем больше, чем раньше за неделю, и при этом получаем не лапшу, а поддерживаемый и предсказуемый код. И ключевая причина, почему это сработало, — не в инструментах и не в ИИ, а в том, что мы сначала научились моделировать и декомпозировать систему целиком, разбивая её на понятные, изолированные части с узким контекстом. Поэтому ИИ перестал быть игрушкой и начал реально усиливать разработку, а не ускорять генерацию хаоса. Наш курс — про разработку как систему, от требований и моделирования до кода и автотестов. В этом потоке мы покажем, как ИИ вписывается в процесс и как он реально помогает, но суть разработки за вас он не выучит — её нужно понимать полностью. Вы узнаете: - Что писать в требованиях, чтобы команда понимала задачу с первого раза; - Какие инструменты делают разработку удобной; - Как измерять архитектуру цифрами, а не на глазок и поддерживать ее в чистоте; - Как строить модель предметной области через Event Storming, чтобы масштаб катастрофы был понятен сразу; - Как писать тесты, которые помогают в разработке, а не мешают; - И мы даже разберём коммерческое приложение, построенное по принципам DDD и чистой архитектуры, чтобы вы увидели всё вживую, а не на хелловорлде; - Какие практики являются обязательными в лучших домах Парижу у лидеров отрасли; - Поноем про говнокод на работе и обсудим что с ним делать; Суммарно мы проведём с вами более 30 часов практических занятий, не считая лекций в записи и домашек, и за это время сначала сломаем привычное кодерское мировоззрение, а затем соберём его заново — уже в виде инженерного подхода, который реально работает в продакшене. Если вы хотите перестать «просто писать код», начать реально управлять процессом разработки и чувствовать себя гораздо увереннее на всё более нестабильном рынке труда, мы запускаем новый поток курса, который стартует в феврале. Для тех, кто оставит заявку до конца этой недели и попадёт в поток, будет бонус — отдельное руководство по политическим игрищам, а именно как продавать инженерные решения внутри команды и компании, даже если начальство уверено, что «мы так всю жизнь работали, а ты тут книжек начитался». Свободных мест осталось всего 5. Анкета предзаписи — по ссылке.

Отмазка «это долго» умерла. Да здравствует «мы просто не умеем» (Все нижесказанное конечно же ИМХО, на истину не претендуем) Последние несколько недель плотно сидел в теме ИИ в разработке. Готовлю ролик (выйдет на днях), но если коротко — у меня для вас две новости. Хорошая: ИИ пока никого не заменяет. Плохая: Это вопрос времени. Потребность в таком количестве белковых «рабочих рук» неизбежно рухнет. И хотя полной картины нет вообще ни у кого (хотя я видел очень много крутых демок), направление движения более чем понятно. Главные мысли за это время: 🔻 Масштабирование хаоса — ИИ не магия и не серебряная пуля. Это мощный ускоритель. Если у вас в проекте архитектура из соплей и палок, а стратегия — накидать лапши и героически её поддерживать, поздравляю: ИИ поможет вам нагенерировать эту лапшу в 10 раз быстрее. Вы утонете в собственном легаси быстрее чем когда либо. 🔻 Смерть отговорки «это долго» Раньше можно было ныть, что писать тесты — это дорого и долго. Теперь эта отмазка мертва. Код генерируется пулеметной очередью, и без автотестов отдел ручного QA захлебнется в слезах уже через неделю. Теперь придется признать честно: мы не пишем тесты не потому что долго, а потому что не умеем. 🔻 Конец эпохи «я просто кодер» Позиция «я пришел писать код, не грузите меня бизнесом и требованиями» стремительно обесценивается. Сам по себе код становится дешевым сырьем. Мы еще года полтора назад в одном из роликов говорили (и нас в комментах за это закидали помидорами), что профессия делится на два лагеря: ⁃ Инженеры: Понимают процесс целиком — от требований до продакшена. ⁃ Все остальные: Скоро выяснят, что знание синтаксиса языка и нюансов по склейке кривых библиотек между собой больше не тянет на полноценную зарплату. 🔻 Вендоры напряглись Продавцы дорогих коробочных решений, которые работают кое-как, а их доработка стоит миллионы (да и вообще у нас в беклоге такого нет), должны начинать нервничать. Бизнес-логику теперь проще и дешевле отреверсить и собрать свое, чем годами платить за чужое раздутое ПО. Итого: Сказки про то, что можно ничего не понимать и ИИ всё сделает сам — для бедных. Выигрывают те, у кого и без ИИ был порядок в процессах, архитектуре, дизайне. А остальные просто быстрее добегут до тупика. Если хотите победить — учитесь понимать систему целиком, иначе останетесь за бортом истории вместе с верстальщиками на таблицах.

Устали от поедания салатов, поэтому взяли и смоделировали с Кириллом Мокевниным целую систему. Приятного просмотра! https://www.youtube.com/watch?v=gyaDwoDvsWY

Бизнес-схема года: Как мне предложили ничего не делать и получать сингапурскую зарплату Обычно мой инбокс забит однотипными письмами от HR про "молодую динамичную команду" и "печеньки в офисе", но сегодня матрица дала сбой и подкинула мне кое-что поинтереснее ✍️ Пишет некий Thai Can (звучит как девиз, но это имя). Программист из Вьетнама, JS/C# сеньор-помидор. Суть стартапа: Вьетнам — бедный, Сингапур — богатый. Я нанимаю его "в черную", он кодит за меня за свои вьетнамские копейки, а я получаю свою сингапурскую котлету и «сосредотачиваюсь на более важных вещах». Ну и конечно, никто ничего не узнает. План надежный, как швейцарские часы. Это письмо заставило меня задуматься (нет, не о том, чтобы согласиться), а о том, в какой параллельной вселенной это вообще могло бы сработать. Почему в Jago Bank этот «аттракцион невиданной щедрости» обречен: - Разработка — это не только стучать по клавишам. У нас (особенно на позициях Senior+) кодинг занимает дай бог 40% времени. Остальное — это бесконечные попытки понять, кому эта фича нужна, что конкретно там нужно и как не уронить прод. Если я найму Тая, мне придется работать переводчиком с «бизнесового» на «технический» фул-тайм. - Слабоумие и отвага. Дать левому чуваку из интернета доступы к банковской инфрастуктуре? Звучит как начало отличной истории для прокурора. А если код утечет — IP будет мой, логин мой, а тюрьма — общая (хотя нет, только моя). - Синдром Staff Engineer. На моем уровне всем плевать, сколько кода я написал. Если я вдруг начну выдавать x3 объема, начальство даже бровью не поведет. А вот если качество кода просядет (а оно просядет, ведь Тай не в контексте наших костылей), коллеги меня сожрут. Где этот бизнес-план мог бы взлететь? ✅ В галерах, где аналитик пишет ТЗ, закрывшись в бункере, потом выбегает, швыряет его в разрабов и баррикадирует дверь, пока не побили вопросами. ✅ На позиции мидла-формошлепа, где KPI — это количество закрытых тикетов. ✅ Если вы адепт секты Over-employment и любите жить на адреналине. И финальный гвоздь: Этот предприимчивый вьетнамец хочет забрать у меня самое приятное — Творение (коддинг), и великодушно оставить мне унылые митинги, согласования и политику?! Ха! Ну уж нет. Страдать на созвонах — это работа, а писать код я и сам люблю. 👇 Что думаете? Сработало бы такое в вашей компании или СБ вычислит через 5 минут? И признавайтесь, есть знакомые, кто успешно "делегировал" себя?

Я тут неожиданно для себя обнаружил, что пора обновить роутер. Не потому что старый плохо работал — нет, он ещё бодр, как Java 8 в проде. А потому что пришёл Wi-Fi 7 и Wi-Fi 6E, а вместе с ними — священный диапазон 6 GHz, который пока не засран соседями. Надо брать, пока можно. Скорости, конечно, обещают чудовищные. Я ещё помню времена, когда от одного провода зависело — будет у тебя 10 или 100 Mbps. А теперь вот это всё, без тени стыда: 11520 Mbps (6 GHz, EHT320) + 5760 Mbps (5 GHz, EHT240) + 1376 Mbps (2.4 GHz, EHT40) Да, мне тоже не совсем понятно где и когда я буду это использовать, но звучит убедительно, а значит — надо. Самый мучительный процесс после покупки роутера — выбор имени Wi-Fi сети. Тут важна архитектура, доменная модель и, конечно, чувство юмора. Мы с ChatGPT, как большие фанаты Star Wars, решили проблему за вас. Теперь мучаться придётся только один раз — при выборе роутера. Готовые имена сетей: • Obi-WAN Kenobi • The LANdalorian • Rogue WAN • Wi-Fi Awakens • Return of the Ping • A New Hop • These Are Not the Droids • R2-D2.4GHz • The Force Is Strong • You Underestimate My Bandwidth • May the Wi-Fi Be With You • LAN Solo Роутер в итоге взял TP-Link EB810v, за 170USD с рук. Цена нового около 500USD (очень люблю когда хорошие роутеры идут в подписке у провайдера. Их можно потом найти по бросовым ценам). Если кому интересно — спрашивайте. Если не интересно — всё равно назовите сеть красиво.

Реальность vs Ожидания: что мы узнали из общения с вами За последние недели мы провели плотные сеанс обратной связи по курсу "Разработка без боли и сожалений". Нам было важно поговорить с двумя разными группами: - С теми, кто только планирует обучение и ищет точки роста. - С выпускниками, кто уже пережил курс и успешно внедрил практики в работу своих команд. Это был не просто разговор, а глубокий разбор полетов. Мы узнали: - Что реально работает в бою, а что — не сработало. - Где ожидания совпали с реальностью, а где были сюрпризы. - С какими вызовами вы сталкиваетесь прямо сейчас. Этот срез реальности помог нам скорректировать фокус, чтобы разбирать не сухую теорию, а живые, актуальные кейсы. 🚀 Что дальше? Следующий поток стартует в феврале. Мы уже обновляем программу с учетом полученных инсайтов. Главная новинка: добавим блок про то, как заставить ИИ реально помогать, а не генерировать рандомные баги. Спойлер: в связке с DDD получается настоящая ИМБА. Если вы рассматриваете участие — мы открыли предзапись. Это ни к чему не обязывает, но вы точно не пропустите старт и получите лучшие условия. 👉 [Ссылка на предзапись] Спасибо всем, кто поделился опытом и помог сделать продукт лучше!

Пост №3. Сухие цифры для Скруджей Макдаков 💰 Сколько стоит стать улиткой? Подбиваем бабки нашего эксперимента с автодомом в Тасмании. Если вы думали, что это дешевый способ путешествовать — у меня для вас плохие новости. Итого за неделю (цены в USD): 📉 Аренда дома: $1000. 📉 Стоянки (чтобы поспать легально): $200. 📉 Топливо: $200 (я ожидал, что этот сарай жрет больше, приятный сюрприз). 📉 Еда, рестораны, вино (много вина) и кофе: $1000. Итого: ~$2400 за неделю на четверых. Вердикт: Смысл брать дом, а не отель + авто? Не собираешь чемоданы. Дети далеко от водителя. Можно проснуться с видом на виноградник и сразу начать... дегустировать. Повторил бы я? Да. Но беруши купил бы заранее.

Пост №2. Быт, дети и алкоголизм как стратегия 🏠 Выживание в автодоме: инструкция по применению Продолжаю рассказ про наш тасманский вояж. Многие думают, что автодом — это про экономию. Ха! Мы почти не сэкономили, зато познали дзен бытовой лени. Главный плюс Вам не нужно каждый день играть в тетрис с чемоданами. Просто сгребаешь в кучу всё, что может кататься по салону и убить кого-то на повороте, загоняешь детей внутрь — и погнали. Личное пространство Оказывается, 5-6 метров дистанции между родителями и детьми творят чудеса. Мы с женой в кабине — приличные люди, обсуждаем высокие материи. Дети сзади валяются на кровати (да, так ехать кайфово, пока не начнешь тормозить). Идиллия. Планирование? Не слышали Project Management остался на работе. Наш метод — «слабоумие и отвага». Был только список мест, а где ночевать — решали по факту. Перспектива остаться ночью в поле не пугает, когда твой дом едет с тобой. А вот стоянки платные. Просто ровная площадка — $12. Хочешь воды, электричества и слить... накопленное? Гони $15–30. Бесплатно стоять нельзя, дальнобойщик Джо должен платить. Комфорт На удивление, это полноценный дом. Две кровати, душ, туалет, холодильник. Жена даже умудрилась пожарить настоящий стейк на микро-плите! Мы пришли к выводу, что могли бы так прожить еще пару недель. Чилить в кемпингах, обсуждать артрит с австралийскими пенсионерами и деградировать. 🍷 Лайфхак для алкоголиков-эстетов: Некоторые винодельни Тасмании разрешают кемперам ночевать на их территории. Тур от винодельни к винокурне с ночевкой на месте дегустации — звучит как идеальный план на старость.

Я проехал 1000 км в автодоме и вынужден поделиться этим экспериенсом с вами Сегодня никакой душноты про DDD. Поделюсь с вами пережитым в отпуске! Решил, что простого отпуска мне мало, и вывез жену с двумя детьми в Тасманию. Чтобы жизнь медом не казалась, мы арендовали автодом. Неделю мы в нем спали, ели и, простите, производили удобрения. Ощущения за рулем За эту неделю я превратился в сурового дальнобойщика Джо. Наш дом на колесах размером с ПАЗик (3.5 метра в высоту!), а дороги в Тасмании строили для хоббитов. Едешь, потеешь: слева 15 см до обрыва, справа 15 см до встречки. А навстречу летит такой же перепуганный Джо, в глазах которого читается молитва и полное непонимание габаритов. Самое смешное, что для управления этой махиной годятся наши обычные права категории B. Видимо, считается, что если ты смог сдать на «Ладе», то и сарай на колесах укротишь. Акустический комфорт (его нет) Автодом — это симфония разрушения. Ощущение, что везешь бабушку на дачу вместе со всем содержимым ее сарая. Где-то сзади ритмично лязгает эмалированное ведро, над ухом скрипит кровать, периодически что-то с грохотом падает. Езда по городам — отдельный тест на стрессоустойчивость. Видел австралийца, который к такому же автодому прицепил сзади легковушку на жесткой сцепке. Правда, они застряли на подъеме. Не уверен, что уровень стресса у них снизился, но попытка засчитана. Есть, конечно, вариант с прицепом-трейлером. Едешь в джипе, кайфуешь, а дом болтается сзади. Но туда нельзя посадить детей. Хотя... если у вас есть парочка запасных, то почему бы и нет? 🔜 В следующем посте расскажу, каково это — жить в коробке вчетвером и не убить друг друга.

Как сделать систему непригодной к использованию и назвать это гибкостью Еще разок про универсальщину. Попался прямо таки каноничный пример как делать не нужно. Итак, есть вендор. В их системе весомая часть действий — это документ (так исторически сложилось). Не важно, что происходит: создаём заявку, выполняем операцию, меняем состояние — всегда создаётся документ. Для всех документов используется универсальный интерфейс: мы указываем тип документа и передаём набор полей, который якобы его описывает. Примерно вот так:

POST /documents
{
  "type": "X",
  "field1": "...",
  "field2": "...",
  "field3": "а может и не нужно"
}

Звучит гибко, но на практике это превращается в проблему: - есть одна универсальная дата-модель, где все поля опциональные; - невозможно понять, какие поля нужно заполнять и как именно; - одно и то же поле может означать совершенно разные вещи в разных типах документов; - без нормальной документации (а её, как правило, нет) пользоваться этим почти невозможно. Ну и вишенка на торте — у документа может быть свой набор состояний или действий. Как результат — целый кабинет аналитиков и разработчиков пытается расшифровать что происходит и как с этим жить. Вывод простой: даже если внутри системы всё построено на документах — не делайте универсальные интерфейсы. Типизированные контракты и явные модели почти всегда выигрывают у гибкости ради гибкости.

Может показаться, что выход — просто брать опенсорс вместо всех этих вендоров. Но и здесь хватает юридических и организационных рисков. Одно дело — суперпопулярный PostgreSQL, другое — какой-нибудь нишевый фреймворк, который завтра может тихо умереть, а специалистов по ним больше не существует. Да и сами опенсорс-проекты умеют переобуваться. Относительно свежий пример — MinIO. На главной странице теперь честно пишут:

This project is currently under maintenance and is not accepting new changes. 
For enterprise support and actively maintained versions, please see MinIO AIStor.

А ещё раньше они фактически убрали консоль администрирования (если я правильно понял), объяснив:

Honestly, it is hard to duplicate this work for the community branch…

Без обид — жестокие улицы Сан-Франциско каждый день требуют дозы Enterprise-лицензии. Но с опенсорсом хотя бы остаётся код: можно форкнуть, допилить, поддерживать сами или в сообществе. С коммерческим продуктом всё жестче: если компания закрылась — код ушёл вместе с ней в закат над Golden Gate. Обезопасить себя от всех рисков — задача нетривиальная и не всегда лежит в технической плоскости. Но если есть возможность — подстелите себе солому из исходников

Как я предлагал вернуть Монолит и сэкономить миллионы. Лично мне вариант с Redis понравился больше всего. Быстро, дерзко, молодежно. Но была одна проблема: Redis работает идеально ровно до тех пор, пока данные влезают в оперативку. Как только память заканчивается — карета превращается в тыкву. А постоянное переливание данных в Postgres через стримы выглядело как надежный, но все-таки костыль. И тут меня осенило. Я пришел к нашему Principal Engineer с Гениальным Планом™.

— Слушай, — говорю я с максимально серьезным лицом. — Я тут порылся в закромах Google Cloud. У них есть машина с 5 ТБ оперативной памяти. — И? — Стоит всего $10k в месяц. Я прикинул: туда влезут все наши данные года за три. Вообще всё. И никаких костылей с переливкой.

Диалог вышел коротким: PE:

— А через 3 года, я полагаю, ты уволишься? Я: — Зачем же? Через 3 года у Гугла появится инстанс на 7 ТБ. Просто переедем на него за ночь.

------ Самое смешное в этой машине — это процессор. Там 200+ ядер. А наш любимый Redis, как мы помним, однопоточный. Ему нужно 1.5 ядра: 1 ядро — крутить транзакции. 0.5 ядра — на IO и «на чай» операционной системе. Остальные 198.5 ядер будут простаивать. Хотя, почему простаивать? Можно запустить майнинг Биткоина. Глядишь, и стоимость аренды отобьем, и в финтех-отчетах покажем «альтернативные источники дохода». ------ В теории, на одну такую машину влезет весь наш немаленький банк. Целиком. Если перестать играть в микросервисы, Kubernetes и распределенные системы, а просто собрать честный, старый добрый Монолит. Ну ладно, для отказоустойчивости возьмем две такие машины. Master и Slave. Всё равно экономия на инфраструктуре выйдет раз в 10. Никаких сетевых задержек, никаких проблем с согласованностью, деплой простым копированием бинарника. Звучит как полный бред сумасшедшего. Или всё-таки нет? #Юмор

Финал: Битва баз данных. Кто стал сердцем банка? [В прошлых сериях]: нас отшил дерзкий стартап, мы обиделись и пошли пилить своё решение. Задача была простая, как кирпич: найти хранилище, которое выдержит наши амбиции. 🎯 Цель: — 100 TPS (транзакций в секунду) на один аккаунт (с блокировками). — 1000 TPS на рандомные аккаунты. Мы прогнали всех кандидатов через мясорубку нагрузочного тестирования. И вот результаты, от которых мы то плакали, то смеялись. 1. Postgres (Старый конь борозды не портит) Взяли его чисто как baseline, чтобы было с чем сравнивать. Вся логика строго на хранимках (Stored Procedures), один поход из приложения в базу. Результат: Один аккаунт: 1 300 TPS (В 13 раз больше требуемого! Мы слегка присели). Много аккаунтов: 9 000 TPS. Внезапно «скучный» SQL показал, что списывать его со счетов рановато. 2. Redis + Postgres (Форсаж) Схема: Редис считает математику в памяти, а потом стримами (Streams) скидывает данные в Постгрес на вечное хранение. Результат: Один аккаунт: 23 000 TPS. Много аккаунтов: 23 000 TPS. Ему вообще плевать. Редис однопоточный, ему все равно хоть один аккаунт, хоть много. Скорость света. 3. TigerBeetle (Тот самый стартап) Результат: Один аккаунт: 27 000 TPS. Много аккаунтов: 77 000 TPS. Обещанного миллиона мы не увидели, но цифры всё равно мощные. Правда, прямо посреди теста мы словили эксепшн:

Whoops, there is a bug in SDK…

Мелочь, а неприятно. Представили, как ловим этот «Whoops» в продакшене в «Черную пятницу», и перекрестились. 4. Google Spanner (Боль и унижение) Напомню, Гугл продавал нам это как «Решение Всех Проблем Человечества». Результат: Один аккаунт: 78 TPS. (Нет, я не забыл букву «K». Просто 78). Много аккаунтов: 870 TPS. (Тоже просто 870). Мы протерли глаза. Перезагрузили серверы. Цифры не изменились. Звоним в Гугл: «Ребята, что за фигня? Где обещанная магия?» Нам вежливо посочувствовали и выдали гениальные советы: - «А вы поставьте перед Спаннером Redis». (Спасибо, Кэп! А Спаннер тогда зачем?). - Скинули статью на Medium: «Какие костыли прикрутить, чтобы базы данных хоть как-то работало с hot accounts». - Рассказали вдохновляющую историю, как один банк реализовал на Спаннере... фичу кэшбека. (Кэшбека, Карл! Не леджера). Когда мы наконец прорвались через продажников к суровым технарям, те вздохнули и признались: «Ну да, сотню TPS выжмете, больше — вряд ли. Архитектура такая». Занавес. ------ Итоговое решение Мы выбрали Postgres. Почему: - Запас прочности: Он выдал 1300 TPS на один аккаунт при требовании в 100. Этого нам хватит на годы. - Надежность: Это скучная, предсказуемая технология. Никаких «Whoops» в SDK. - Архитектура: Мы спроектировали систему так, чтобы оставить перед Постгресом «Redis-shaped hole» (дырку в форме Редиса). - Если (или когда) мы вырастем до космических масштабов, мы просто вставим туда Redis, как деталь пазла. А пока — зачем платить сложностью за то, что старый добрый SQL делает бесплатно? А теперь предлагаю погуглить "Spanners British slang". В общем, хорошую штуку Спаннером не назовут

DIY для банка: выбираем базу данных, когда стартап нас отшил В предыдущей серии я рассказывал, как TigerBeetle — стартап нашей мечты — отправил нас во френдзону. Пришлось засучить рукава и делать «сердце» банка самим. Но на чем писать? Чтобы не было мучительно больно за бесцельно прожитые спринты, мы сформулировали требования. Задача: - 1000 TPS (транзакций в секунду) на рандомных аккаунтах. - 100 TPS на одного «жирного» клиента. С первым пунктом всё понятно: если руки растут из плеч, любая современная БД это вывезет. А вот второй пункт — это боль. Нужно заблокировать аккаунт, посчитать баланс, записать проводку и разблокировать. Арифметика беспощадна: 1 секунда / 100 транзакций = 10 мс на всё про всё. Тут уже на Python не попишешь, тут думать надо. В кастинг на роль «сердца» попали четыре кандидата: 1. Postgres (Классика) Старый добрый слон. Чтобы уложиться в 10 мс, всю логику придется зашивать в хранимки (Stored Procedures). Гонять данные туда-сюда между приложением и БД — непозволительная роскошь. Сомнения: Наша текущая система на MySQL выдает жалкие 7 TPS. Вендор клянется мамой, что это предел физики. Мы, конечно, умнее, но сможем ли мы быть умнее на порядок? Вопрос открытый. 2. Redis + Postgres (Безумный Макс) Идея для смелых: ставим Redis перед Постгресом. — «Но это же просто кэш!» — кричат пуристы. — «Подержите мое пиво», — отвечаем мы. Почему это круто: - Single-threaded: Редис однопоточный. Никаких гонок (race conditions). Атомарность из коробки. - Lua scripts: Логику можно исполнять прямо внутри памяти. Быстро, дерзко. - Надежность: У Редиса есть стримы. Можно реализовать Transaction Outbox паттерн без танцев с бубном, Kafka и Debezium. Данные льются в Postgres в фоне. - Персистенс: Да, вся база должна лезть в RAM. Но Редис умеет сбрасывать данные на диск и реплицировать на слейвы. Если настроить прямыми руками — надежно, как швейцарские часы. 3. TigerBeetle (Бывшая) Те самые ребята, которые нас отшили. Заявляют 1 000 000 TPS. Даже на один аккаунт. Звучит как сказка, но проверить надо. Вдруг врут? А если не врут — будем кусать локти (или снова проситься к ним). 4. Google Spanner (Швейцарский нож) Самый загадочный зверь. Спрашиваешь у Гугла, что такое Spanner, и тебе отвечают: «ЭТО ВСЁ». Хочешь SQL? Spanner. Хочешь Key-Value? Spanner. Графы? Spanner. AI? Разумеется, Spanner! Там скоро можно будет писать запросы в духе: «AI, проверь, хватит ли у юзера 123 денег на пиво, и если да — переведи». На презентации меня сдержало только хорошее воспитание, чтобы не спросить: «А блокчейн вы туда еще не впихнули?». Похоже, это единственное, чего там нет. Проблема: Это распределенная БД. Она сама решает, где хранить данные. Скорее всего, она раскидает счета по разным нодам, и каждый перевод превратится в multi-node transaction. А это медленно. Но Гугл так настойчиво поил нас кофе и водил по виски-барам, что мы решили дать Спаннеру шанс. Из вежливости. ------ Результаты эпичной битвы и реальные цифры нагрузочного тестирования — в следующем посте. А пока вангуем в комментариях. В каком порядке тулзы пришли к финишу (от лучшей производительности к худшей). И какую технологию выбрали бы лично вы? Кто будет ближе всех — тот настоящий HighLoad архитектор.

Мы в Satori тоже регулярно сталкиваемся с вендорами ПО. Раньше я как-то не особо обращал на это внимание… но теперь я просто в восхищении от того, как изящно устроен этот рынок. Узнал потрясающие вещи: - Оказывается, API можно смело поставлять без документации — вы же умные, сами разберетесь. - Можно брать деньги за доработки, а потом бодро сообщать: «Ну… не получилось». - На вопрос «почему столько багов и есть ли у вас тесты?» присылать набор юнит-тестов, сгенерированный вчера ИИ, причём таких, что они не проверяют вообще ничего. - Спокойно тестировать прямо на проде клиента — идеально же, всё под рукой. - Игнорировать вопросы даже в платной техпододдержке — бережём энергию. - На срочные запросы отвечать: «Единственный человек, который в теме, у нас сейчас в отпуске». - Требовать оплату за работы, которых в природе не существовало. - На просьбу о функциональности говорить: «Этого нет в нашем беклоге и никогда не появится». - Продавать «коробочное решение», которое по факту — франкенштейн из копролита, костыля и поделия джуна после курсов. - Обвинять заказчика, в том что он нормально задачу не ставит и не проверяет - И главное, абсолютный шедевр: подсадить клиента на «бесплатное решение», а потом элегантно выкручивать ему руки за доработки. Вот это я понимаю, бизнес-модель!