В основе работы ИИ-ассистентов и ИИ-агентов лежат большие языковые модели - Large Language Models. Их существует большое количество и у каждой из них свои характеристики. И постоянно появляются новые модели. Предыдущим постом я скинул новость о выпуске одной из них - Qwen-3. Но что значат все эти описания:

- Выпустили 2 MoE и 6 dense моделей в весах на любой вкус, 0.6В до 235B
- Это MoE всего с 22В активных параметров
- Это полу-ризонеры, как Sonnet 3.7 или Gemini 2.5 Pro
- Претрейнинг был в три этапа
- Пост-трейнинг: файн-тюнинг на CoT + несколько стадий RL

Все эти термины звучат как сложная магия, доступная только учёным в сфере ИИ, и кажется, что простым программистам этого не понять, да и не нужно. На самом деле это не так. Знать это полезно и изучить можно достаточно просто.

Есть отличное видео, где Андрей Карпатый (со-основатель OpenAI и директор по ИИ в Tesla) всего за три с половиной часа объяснит вам, как устроены LLM и как работает пайплайн их обучения. При этом он вообще не касается математики, поэтому материал доступен для понимания любому ИТ-специалисту. После просмотра вы будете понимать большинство из того, что пишут в новостях про LLM. И сможете более осознанно их обсуждать, выбирать и использовать.

Вот ссылка на видео. Есть русские субтитры. Очень рекомендую к просмотру.

https://www.youtube.com/watch?v=7xTGNNLPyMI

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

Андрей Курдюмов создаёт набор данных для хакатона HackLoad 2025, который мы готовим. Они будут использованы для базы пользователей билетного сервиса. Если знаете, какие есть источники имён, напишите ему.

Ticketon опубликовал постмортем по следам сбоя 11 апреля. Я провёл его анализ и постарался извлечь больше технических деталей вместе с рекомендациями по предотвращению таких проблем в будущем.

https://teletype.in/@drimdev/ticketon-postmortem-2025-analysis

На мою статью с анализом постмортема Ticketon написали комментарий:

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

То есть изначально я предположил, что запросы доходили до бекенда Ticketon, но там блокировались из-за неизвестного IP отправителя. Но, судя по комментарию (написал, скорее всего, человек из команды), запросы до бекенда вообще не доходили и вставали в очередь Waiting Room наравне с запросами от пользователей.

Чтобы избежать этой ситуации, в Cloudflare Waiting Room нужно было настроить Bypass Rules, чтобы запросы с IP адресов платёжных провайдеров не попадали в очередь. Либо настроить правило, чтобы туда не попадали запросы на конкретный URL эндпоинта Ticketon. Система правил Cloudflare очень мощная и позволяет настроить много сценариев. Но команда в экстренной ситуации забыла это сделать. Сказалось отсутствие заранее подготовленных инструкций на случай разных сбоев.

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

Cloudflare

Во время анализа сбоя Ticketon мы много говорили о Cloudflare Waiting Room. Я думаю, что сейчас, пока эта ситуация ещё свежа в памяти, было бы хорошо углубиться и поговорить о том, что такое Cloudflare в целом. Как он работает, какие сервисы предоставляет, какие технологии использует. Эта информация будет полезна тем, кто создаёт веб-приложения и хочет, чтобы они работали быстро и надёжно. Также это будет интересно тем, кто хочет работать в Cloudflare или подобных компаниях и хочет понимать, какие технологии для этого нужно знать.

На тему Cloudflare будет несколько постов. В этом и следующем посте мы сконцентрируемся на основной технологии, которая делает возможными все сервисы Cloudflare. Она называется Anycast Network.

Давайте представим, что мы хотим запустить свой сайт по адресу shokan.blog. Первым делом мы его разрабатываем и получаем набор HTML, CSS и JS файлов. Кроме этого может потребоваться разработать API, но для простоты пока это опустим. После того, как сайт разработан, нам нужно его где-то захостить. Для этого мы пользуемся услугами хостингов. К примеру, мы можем использовать Hetzner и арендовать у них виртуальную машину. Предположим, что она находится в Германии. Затем на этой машине мы запускаем веб-сервер (например, NGINX), который будет обрабатывать HTTP запросы от клиентов (обычно это браузеры) и отдавать наши HTML, CSS и JS файлы.

Виртуальная машина с нашим сайтом имеет публичный IP адрес. Предположим что это 150.10.27.114. Но нам нужно доменное имя, чтобы его можно было забить в браузере. Для этого мы идём в сервис регистрации доменных имён типа GoDaddy и покупаем там нужное имя. Затем мы в админке GoDaddy настраиваем DNS - прописываем, какому IP соответствует купленное имя. Мы создаём DNS-запись "shokan.blog -> 150.10.27.114". После этого наш сайт начинает работать.

Давайте посмотрим, что происходит, когда пользователь вводит в браузере shokan.blog. Сначала с компьютера отправляется DNS запрос на получение IP адреса. Опустим детали работы DNS, но в итоге запрос приходит в GoDaddy и тот отвечает, что домену shokan.blog соответствует адрес 150.10.27.114. После этого браузер отправляет HTTP-запрос на этот адрес, запрос доходит до виртуальной машины Hetzner и та отправляет браузеру файлы сайта. В итоге пользователь видит наш сайт у себя на экране.

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

Обе эти проблемы может решить Cloudflare.

Cloudflare имеет по всему миру более 300 дата-центров. Они, к примеру, есть в Сиднее, Алматы, Красноярске, Амстердаме и в множестве других городов. И мы можем сделать так, что запросы на получение нашего сайта будут отправляться не на нашу виртуальную машину в Германии, а в ближайший дата-центр Cloudflare. И Cloudflare отдаст HTML, CSS и JS файлы нашего сайта из своего кеша. То есть запроса на нашу виртуальную машину не будет вообще. Это решает обе проблемы. Все пользователи смогут быстро открывать наш сайт, сколько бы их не было и где бы они не находились.

В следующем посте разберёмся, как это работает технически.

#cloudflare #anycast

Первым делом мы должны создать аккаунт в Cloudflare и перенести домен shokan.blog с GoDaddy на Cloudflare. Опустим детали, как это делается, но в итоге на DNS запросы будет отвечать Cloudflare. И вместо того, чтобы для домена shokan.blog отдавать IP адрес нашей виртуальной машины, он будет отдавать свой IP адрес. То есть браузер пользователя для получения сайта будет слать запросы не на нашу машину, а в дата-центр Cloudflare.

Но в какой конкретно дата-центр будут отправляться запросы? Мы привыкли, что конкретный IP адрес соответствует конкретному серверу в конкретной точке мира (есть ряд исключений, но пока их опустим). Эта схема называется Unicast.

Cloudflare для маршрутизации запросов использует другую схему. Она называется Anycast. Суть заключается в том, что IP адрес указывает сразу на все дата-центры и запрос маршрутизируется в тот дата-центр, который ближе всего к отправителю запроса. Предположим, что Cloudflare для домена shokan.blog вернул адрес 104.17.175.85. Если пользователь находится в Австралии, то запрос по этому адресу 104.17.175.85 будет отправлен в дата-центр в Сиднее. А если пользователь находится в Казахстане, то запрос по этому же адресу 104.17.175.85 будет отправлен в дата-центр в Алматы. Технически Anycast настраивается с помощью протоколов маршрутизации, таких как BGP. Кому интересно, тут можно почитать детальнее.

В результате переноса домена в Cloudflare и использования Anycast весь трафик на сайт shokan.blog начинает проксироваться, то есть идти через дата-центры Cloudflare. И это позволяет использовать много сервисов для ускорения и повышения надёжности работы сайта. Один из них это Cloudflare Waiting Room, который использовал Ticketon. Надеюсь, теперь стало более понятно, как он работает - все запросы сначала идут в Cloudflare, а он уже решает пропустить их дальше или начать делать редиректы на страницу виртуальной очереди, если запросов слишком много.

Благодаря проксированию также работает кеширование файлов сайта. Когда Cloudflare первый раз получает запрос на shokan.blog, то он пересылает запрос на нашу виртуальную машину в Германии, получает файлы, сохраняет их в кеш, и только потом отправляет их пользователю. И на все последующие запросы он уже не шлёт запросы на нашу виртуальную машину, а просто отдаёт их из кеша.

Надеюсь, читатели смогли понять основные принципы работы Cloudflare. (Если нет, задавайте вопросы в комментариях.) Дальше я периодически буду писать посты, где будем углубляться и изучать конкретные сервисы. А также посмотрим, какие технологии использует Cloudflare для своей работы. Возможно, кто-то из вас захочет их изучить и устроиться в эту компанию. Оставайтесь на связи, будет интересно и полезно 🚀

#cloudflare #anycast

https://vas3k.club/post/28485

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

Однако, результат пока совсем неудовлетворительный. Но, всё равно, делюсь. Буду продолжать работать над этим.

Саму статью очень рекомендую почитать, поскольку она описывает самую суть моего подхода к использованию LLM в работе как над кодом, так и над текстом.

Данияр написал отличную статью, где сравнил два подхода к разработке с использованием ИИ - вайбкодинг и метакодинг. Мне статья понравилась тем, что метакодинг описывает то, как я использую ИИ в своей работе:

Метакодинг — это программирование с высоты птичьего полета. Метакодер не просто скармливает задачу нейросети и ждёт результата, он выстраивает архитектуру взаимодействия с ИИ: создает систему артефактов (документация, схемы, тесты), работает на уровне абстракций и контрактов, а затем использует LLM как инструмент имплементации своего видения.

Звучит скучно? А вот и нет. Именно здесь начинается настоящий хардкор.

Метакодер не просто дирижёр. Он знает, когда оркестр фальшивит — и как это предотвратить.

Ключевое отличие метакодинга — осознанность. Метакодер понимает не только «как» заставить модель генерировать нужный код, но и «почему» именно это решение оптимально. Он видит код не как магический артефакт, созданный шайтан-машиной, а как систему, где каждая часть имеет своё строго определённое место, и к точно такому же выводу придёт любой, кто ознакомится с документацией проекта, будь то машина или человек. Метакодер использует LLM не как джинна, который исполняет желания, как бы двусмысленно они ни были сформулированы, а как опытного новоприбывшего коллегу, который имеет все необходимые навыки для решения задачи, но просто не знает, куда смотреть чтобы понять что к чему.

Ценно, что появляется новый термин "метакодинг". Думаю, что он приживётся в индустрии и позволит разработчикам более осознанно выбрать, как им использовать ИИ. Прочитайте статью - она того стоит.

Недавно мы обсуждали ситуацию со сбоем при продаже билетов на концерт Дженнифер Лопес в Астане. И вот недавно появилась ещё одна новость - кроме Астаны певица выступит ещё и в Алматы. Концерт будет 10 августа и билеты будет продавать всё тот же Ticketon. Техническое сообщество стало ждать, как сервис отработает на этот раз.

Продажа билетов стартовала сегодня 28 мая в 10 утра. Скорее всего, на момент написания этого поста все билеты уже распроданы. Но нам интересно не это. Нам интересно, какие технические решения применил Ticketon, чтобы избежать проблем, связанных с большим наплывом покупателей. Он, как и в прошлый раз, использовал виртуальную очередь. Только подключил её планово до начала продажи билетов, а не экстренно, как 11 апреля. И уже можно сказать, что это сработало и билеты были проданы без проблем.

Когда я услышал, что Ticketon будет снова продавать билеты, я предположил, что они будут использовать Cloudflare Waiting Room. Но, если посмотреть на скриншот страницы очереди, то видно, что это не так. Страница хостится на домене queue-it.net. Это домен сервиса Queue-it. Но почему они не стали использовать Cloudflare?

Ответа на этот вопрос мы можем и не узнать. (Кто знает точно, напишите, пожалуйста, в комментариях, если это не закрытая информация.) Возможно, была ощутимая разница в стоимости. Но, так как стоимости использования Queue-it нет в публичном доступе, провести сравнение мы не сможем. Что мы можем сделать, так это сравнить то, как технически производится подключение виртуальной очереди. И уже на основании этого посмотреть, есть ли преимущества у Queue-it.

И преимущества есть. Чтобы подключить Cloudflare Waiting Room, нужно обязательно проксировать трафик через их дата-центры. Я детально описал, как это работает, в предыдущих постах. Queue-it, наоборот, позволяет подключить виртуальную очередь без проксирования трафика. Вот какие варианты интеграции он предлагает:

1. Прямая ссылка на виртуальную очередь
2. Интеграция на стороне клиента с помощью JavaScript
3. Интеграция на стороне CDN-сервисов, таких как Cloudflare
4. Интеграция на стороне обратных прокси и балансировщиков
5. Интеграция на стороне бекенда

Как видно, Queue-it предлагает намного больше вариантов подключения. Возможно, это и стало причиной их выбора командой Ticketon.

В последующих постах мы разберём, как работает каждый вариант подключения виртуальной очереди Queue-it. Интересно будет увидеть, как одну и ту же задачу можно решить разными способами. (Будет что рассказать на System Design Interview, когда вы будете устраиваться в топовые компании.) Кроме того, в процессе анализа мы поймём, как работают Cloudflare Workers и некоторые другие сервисы. Это тоже будет полезно для развития навыков системного дизайна.

Подписывайтесь на канал, будет полезно и интересно 🚀 @drim_channel

#ticketon #cloudflare #queue_it

Cloudflare CDN

Всем привет! В прошлый раз мы говорили об Anycast и о том, как Cloudflare направляет трафик на ближайший к пользователю дата-центр. В том посте мы вкратце затронули, что Cloudflare может сохранять (кешировать) файлы вашего сайта, чтобы не беспокоить постоянно ваш основной сервер.

Эта технология называется Content Delivery Network (CDN). И это одна из ключевых функций, которая становится доступна благодаря тому, что весь трафик идёт через Cloudflare. Логика простая: когда дата-центр Cloudflare получает запрос на файл с вашего сайта (картинку, скрипт, видео), он сначала проверяет, нет ли у него в кеше свежей копии этого файла.

* Если копия есть (Cache Hit), он мгновенно отдаёт её пользователю. Ваш сервер в этот момент даже не узнает, что был какой-то запрос.
* Если копии нет (Cache Miss), Cloudflare обращается к вашему серверу, забирает файл, сохраняет его в свой кеш для будущих запросов и отдаёт пользователю.

Чтобы не быть голословным, я прикрепляю скриншот из панели управления одного из моих реальных проектов. Цифры говорят сами за себя. За последние 24 часа было обработано 538.13 миллиона запросов. Из них 526.68 миллиона были отданы напрямую из кеша Cloudflare. До моего сервера дошло всего 11.46 миллиона запросов.

Простая математика показывает, что почти 98% всех запросов были обработаны из кеша! Это значит, что CDN снизил нагрузку на мой сервер почти в 47 раз. Это колоссальная экономия ресурсов и надёжная защита от сбоев при любом наплыве посетителей.

И, что очень важно, CDN доступен на бесплатном тарифе Cloudflare!

Как включить и настроить CDN?

Хорошая новость в том, что базовое кеширование включается автоматически, как только вы переносите свой домен на Cloudflare. Он по умолчанию начинает кешировать статические файлы.

Для более тонкой настройки нужно зайти в панель управления Cloudflare, выбрать ваш домен и перейти в раздел Caching > Configuration.

Здесь можно настроить несколько ключевых вещей:

* Caching Level. Уровень кеширования. Он определяет, какие данные нужно кешировать.
* Browser Cache TTL. Как долго браузер пользователя должен хранить у себя копию файлов. Это уже кеширование на стороне клиента.

Для большинства сайтов стандартных настроек более чем достаточно. Если же вам нужны более сложные правила (например, кешировать определённые страницы, но не кешировать другие), можно использовать Cache Rules.

Что кешируется, а что нет?

По умолчанию кешируются: статические ресурсы. Это файлы, которые не меняются от пользователя к пользователю.

* CSS, JavaScript файлы
* Изображения (JPG, PNG, GIF, SVG)
* Шрифты (WOFF, TTF)
* Документы (PDF)

По умолчанию НЕ кешируются: динамические запросы. Это контент, который генерируется персонально для пользователя или изменяет данные на сервере, например:

* API-запросы. Например, когда вы отправляете комментарий или ставите лайк, этот запрос (POST /api/comments) должен дойти до сервера, чтобы он сохранил данные в базу. Кешировать его нельзя.
* Ответы для залогиненных пользователей. Страница профиля /profile у каждого пользователя своя, и её нельзя показывать всем из кеша.

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

Но как Cloudflare, браузер и сервер договариваются между собой о том, что и на какое время можно кешировать? Для этого в вебе существует специальный стандартный механизм, который управляет всем процессом с помощью HTTP-заголовков (например, Cache-Control, Expires, ETag). Именно через них наш сервер может дать точные инструкции любому кеширующему прокси или браузеру.

Этот механизм и другие тонкости кеширования мы подробно разберём в следующем посте. А пока рекомендую ознакомиться с официальной документацией Cloudflare Cache/CDN.

Подписывайтесь на канал, будет полезно и интересно 🚀 @drim_channel

#cloudflare #cdn #cache

В апреле мы анонсировали проведение хакатона HackLoad 2025 по проектированию высоконагруженного билетного сервиса. Вот страница хакатона https://hackload.kz/, там описаны все детали. Уже определены конкретные даты - с 15 по 17 августа. Регистрация будет проходить с 1 по 25 июля. Команды могут участвовать как офлайн в Алматы, так и онлайн. Команда организаторов состоит из 4 человек - Станислава Беляева, Андрея Курдюмова, Теймура Шайкемелова и меня (Дмитрия Мельника).

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

Лекции будут напрямую применимы к задаче проектирования билетного сервиса. То есть на каждой лекции предлагаемые технологии и подходы будут демонстрироваться на тех или иных частях билетного сервиса. Вот темы:

1. Паттерн «Сага» для распределенных транзакций

Кратко сравним монолит и микросервисы. Разберём паттерн «Сага» для обеспечения целостности данных в микросервисах (заказ, оплата, резервирование места). В основу положим классификацию саг из книги "Software Architecture: The Hard Parts": Epic Saga, Phone Tag Saga, Fairy Tale Saga, Time Travel Saga, Fantasy Fiction Saga, Horror Story, Parallel Saga, Anthology Saga.

2. Масштабирование под высокую нагрузку

Проектирование систем для пиковых нагрузок в момент старта продаж. Разберем вертикальное масштабирование, горизонтальное масштабирование, балансировщики нагрузки и методы оптимизации баз данных (индексы, read-реплики, шардирование), чтобы сервис не «упал» от наплыва пользователей. Также коснемся ускорения системы с помощью кеширования (Redis) и CDN.

3. Организация конкурентного доступа

Научимся решать главную проблему билетных сервисов — как избежать «двойной продажи» одного и того же места. Изучим на практике разные виды конкурентности (оптимистичная и пессимистичная на уровне БД и на уровне приложения) и использование очередей для надежной обработки заказов.

4. Создание отказоустойчивых систем

Научимся обеспечивать стабильность сервиса при внутренних сбоях и при сбоях внешних API (например, API стадиона). Разберем паттерны Timeouts, Retries, Bulkhead, Circuit Breaker и другие.

5. Интеграция платежных провайдеров

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

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

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

#hackload #architecture #lectures

Открытие регистрации на HackLoad 2025

Мы открываем регистрацию на хакатон HackLoad 2025! Для этого мы запустили веб-приложение, куда вам нужно перейти и заполнить форму регистрации. Адрес приложения - https://hub.hackload.kz/

На текущий момент приложение представляет собой простую форму регистрации. Там вам нужно будет залогиниться с помощью Google или GitHub, а затем указать краткую информацию о себе. Если вы уже сформировали команду, то первым должен зарегистрироваться лидер команды. Он должен будет ввести название команды, которая будет автоматически создана. Затем в своём профиле он увидит ссылку, которую нужно будет разослать участникам команды, чтобы они также зарегистрировались. Если вы ещё не выбрали команду, укажите этот вариант на форме регистрации. Выбрать команду можно будет позже.

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

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

Все дальнейшие анонсы я буду делать на этом канале. Кроме этого, мы будем публиковать их в группе "Тимлид не кодит" @teamleads_kz. Вступайте туда, чтобы быть в курсе новостей и иметь возможность обсуждать интересующие вас вопросы. Также можете задавать вопросы в комментариях к этому посту, я на всё отвечу.

Если вы ещё не слышали про хакатон, то вот его информационная страница - https://hackload.kz/.

До хакатона осталось 1,5 месяца. Начинается жаркая пора подготовки и обучения! ☀️ Подписывайтесь на канал @drimdev, будем готовиться и расти вместе 🚀

#hackload

📣 2 июля мы объявили об открытии регистрации на хакатон HackLoad 2025. После этого нам начало поступать много вопросов. Вся информация доступна на сайте https://hackload.kz/. Изучите его. Кроме того, я решил написал отдельный пост (этот), где собрать все детали о хакатоне.

💥 Идея проведения хакатона родилась после сбоя Тикетона во время продажи билетов на концерт Дженнифер Лопес в Астане. Эта ситуация вызвала много критики в ИТ-сообществе. Мы решили перевести её в конструктивное русло и предложить всем желающим создать билетный сервис, устойчивый к большим нагрузкам и внутренним и внешним сбоям. Так родился хакатон HackLoad 2025.

📍Хакатон будет проходить в Алматы с 15 по 17 августа. Место проведения мы сообщим позже. Можно участвовать как на месте, так и онлайн.

⚙️ В хакатоне будет два трека: для начинающих и для продвинутых. В первом треке задание будет проще, во втором - сложнее. Трек для начинающих подходит для студентов и джуниоров.

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

🎯 Задача участников хакатона - создать бекенд билетного сервиса. Фронтенд делать будет не нужно. Мы, как организаторы хакатона, предоставим описание API сервиса, и командам нужно будет его реализовать. Во время реализации у команд будет возможность запускать нагрузочное тестирование и оценивать, как их приложения будут себя вести. Также бекенд нужно будет интегрировать с 2 внешними сервисами: платёжным провайдером и системой стадиона, где будет проходить концерт. Система стадиона будет отслеживать проданные места. Мы предоставим командам реализации обоих этих сервисов.

🚲 Команды могут использовать любые удобные им технологии.

🔨 Когда команды завершат создание билетных сервисов, мы по очереди запустим несколько сценариев нагрузочного тестирования. Выиграют те команды, чьи сервисы не упадут и покажут лучшие метрики (летенси, пропускная способность и другие). Также будет оцениваться потребление вычислительных ресурсов сервисами.

✉️ Задания будут опубликованы 5 августа. Можно будет начать прорабатывать их заранее. Задача создания билетного сервиса достаточно объемная и может потребоваться подготовка, чтобы затем за 3 дня успеть его реализовать.

👩‍💻👨‍💻Регистрация открылась 2 июля и будет закрыта 25 июля. У каждой команды должен быть лидер, и он должен зарегистрироваться первым, чтобы создать команду. Затем остальные участники при регистрации смогут выбрать эту команду. Максимальное количество участников в команде - 4 человека. Регистрироваться можно без команды и выбрать её позже. Участовать могут люди как из Казахстана, так и из других стран. Сайт для регистрации - https://hub.hackload.kz/.

👥 Организаторы хакатона - Станислав Беляев, Андрей Курдюмов, Теймур Шейкемелов и я, Дмитрий Мельник.

💰 Спонсорами хакатона будут 2 крупные казахстанские компании. О них мы расскажем немного позже.

ℹ️ Чтобы получать дальнейшую информацию и задавать вопросы, вступайте в группу "Тимлид не кодит". Также в скором времени мы создадим отдельный чат для участников хакатона.

🏆 В завершение повторю слоган хакатона:

В HackLoad мы верим в создание возможностей для разработчиков решать реальные задачи в совместной, образовательной среде. Наше мероприятие направлено на развитие как навыков, так и сообщества.

🥇 Регистрируйтесь на хакатон и получите новые знания, ценный опыт и важные знакомства.

🚀 P.S. Подписывайтесь на канал @drimdev, будет полезно и интересно!