Высоконагруженные системы *

В 2025 году платформа VK Видео стала лидером в России по ежедневной и ежемесячной аудитории. За этим результатом стоит не только рост числа авторов и объёма контента. В его основе системное развитие технологий: мы последовательно масштабируем инфраструктуру, совершенствуем пайплайны обработки видео и инвестируем силы в стабильность воспроизведения на всех пользовательских устройствах и при любых условиях сети. Это постоянная инженерная работа, направленная на предсказуемое и стабильное качество сервиса при быстрорастущей нагрузке. 

Меня зовут Алексей Шпагин, я руководитель разработки бэкенда видеоплатформы VK. В статье расскажу о технологиях, лежащих в основе VK Видео, и жизненном цикле контента на платформе: от загрузки и обработки до доставки зрителям.

В 2026 году асинхронный Python уже никого не удивляет. Мы привыкли к автоскейлингу в облаках, но что делать, если ваш бюджет на инфраструктуру равен нулю, а в распоряжении есть только «печка» из 2012 года? Рассказываю про личный опыт выжимания максимума из FastAPI на AMD FX-8320: от тюнинга ядра Linux и PostgreSQL до миграции на Ed25519 и использования Rust-сервера Granian.

В современном финтехе скорость, надежность и глубина предоставляемой информации особенно важны. За интуитивно понятным интерфейсом, который видит трейдер, скрывается сложная архитектура из взаимосвязанных сервисов, отвечающих за сбор, обработку и доставку рыночных данных в реальном времени. Мы — команда MarketData компании «Финам», в этой статье мы рассказываем, как устроена наша система изнутри.

Загружал пару лет переписки из Telegram в Apache Doris на ноутбуке. Первый запуск 2 часа. После оптимизации 206 400 сообщений за 5 секунд.

Полез в исходники разобраться, почему Stream Load (HTTP-загрузка данных) в Doris работает так быстро. В статье разбор C++ кода: от HTTP PUT до Segment-файла на диске.

Что внутри:
— 14 шагов одного HTTP-запроса (с диаграммой и кодом)
— StreamLoadPipe: буфер 4 MB с backpressure
— Иерархия записи: LoadChannel → DeltaWriter → MemTable → async flush
— 6 практических выводов: что крутить, что мерить, где смотреть compaction score

Когда у вас 50+ узлов Tarantool в кластере, ручное управление соединениями превращается в боль. Узлы падают, реплики становятся мастерами, новые инстансы добавляются — и все это нужно отслеживать в реальном времени. 

Рассказываем, как мы спроектировали go-discovery — библиотеку для автоматического обнаружения узлов кластера Tarantool 3.0.

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

В этой статье я расскажу, как устроен централизованный, надёжный и удобный способ асинхронного взаимодействия сервисов внутри Wildberries. Я Виктор Такташов, Golang-разработчик в команде Trust & Safety. С задачами Highload знаком не понаслышке, потому что когда-то занимался сервером популярной онлайн-игры. К тому же я больше шести лет занимался борьбой, так что с проблемами расправляюсь умело и хладнокровно :-)

Почему мы решили сделать Databus

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

Примеры на Ruby, Go, Java.

Привет, Habr! Наша команда LLM-разработки подготовила статью о реальном практическом опыте тюнинга и тонкой настройке RAG-системы в области охраны труда. Каждый, кто начинал работать с LLM, проходил через этот «медовый месяц»: вы берете LangChain, загружаете с десяток PDF-файлов в ChromaDB, пишете простенький промпт — и происходит магия. Бот отвечает, эксперты в восторге, MVP готов за выходные.

Но магия исчезает ровно в тот момент, когда в базу знаний прилетает тысяча документов, а цена ошибки из «просто забавной галлюцинации» превращается в юридические риски и штрафы. В нашем проекте «Марк» (протестировать тут: @AI_assistantOT_bot)  — ИИ-эксперте по охране труда — мы столкнулись именно с этим: наивный RAG на больших данных не просто работает хуже, он разваливается.

Мы заглянем под капот системы, которая прошла путь от локального скрипта до сложной архитектуры на LangGraph.

Мы подробно разберем:

За почти десять лет, прошедших с момента выхода MySQL 5.7, в мире баз данных многое изменилось. Появились новые подходы к обработке данных, ужесточились требования к безопасности, и даже сам характер приложений стал совершенно иным. MySQL 8.0, увидевший свет в 2018 году, попытался ответить на все эти вызовы, привнеся не только новую функциональность, но и фундаментально иной подход к хранению и обработке данных. 

Тем не менее, большое количество команд остаются верны MySQL 5.7, и на то есть веские причины. Для этой статьи мы в команде платформы данных Yandex Cloud постарались непредвзято посмотреть на производительность обеих версий и протестировать её на реальных нагрузках облачной платформы, а не в рамках стерильного тестового стенда. После прочтения вы сможете обоснованно решить, обновляться ли в ближайшем будущем, или точно понять, почему именно в вашем случаем этого делать не стоит.

Uber держит огромные объёмы данных сразу в своих дата-центрах и в облаке, поэтому их нужно постоянно и быстро копировать между регионами для аналитики и аварийного восстановления.

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

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

Здесь рассказано, как именно Linux обрабатывает системные вызовы в архитектуре x86-64, и почему при профилировании они выглядят как дорогостоящие операции.

Контейнеры давно стали стандартом современной разработки. Согласно отчету Docker State of Application Development 2025, они используются примерно в 92% IT-организаций и фактически стали универсальным способом упаковки и запуска приложений независимо от платформы и окружения. Это тот случай, когда инфраструктура перестает мешать и начинает экономить время.

Именно поэтому Digital Q.DataBase доступна, в том числе, в виде Docker-образа. Это позволяет за несколько минут попробовать Oracle- и MS SQL-совместимую СУБД на Windows, Linux и macOS, ограничившись несколькими командами, без сложной установки и длительного онбординга. Полноценная рабочая среда готова к использованию сразу после старта контейнера.

По сути, после того как вы скачали архив и подготовили директорию, для запуска Digital Q.DataBase достаточно четырех команд.

Привет, Хаброжители!

От выбора подхода к поглощению данных может зависеть успех или провал работы конвейера данных

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

Микросервисы на схемах выглядят стройно, но в проде часто вырождаются в распределённый монолит: общая БД, синхронные цепочки вызовов и каскадные падения. В этой статье разберемся, как проводить границы сервисов так, чтобы система оставалась автономной — почему декомпозиция по слоям ломает независимость, как опираться на bounded context и бизнес-возможности, как аккуратно выводить legacy через Strangler, и где на практике помогают Database per Service, CQRS и Saga.

Всем привет! Меня зовут Максим, я Go-разработчик в Wildberries & Russ. В высоконагруженных системах сотни сервисов взаимодействуют ежесекундно, и любой малейший простой системы напрямую влияет на прибыль бизнеса. Чтобы уметь быстро находить причины и устранять их за короткие сроки придуманы инструменты, обеспечивающие наблюдаемость приложения. Сегодня поговорим о том, как обеспечить observability и почему без нее жизнь продукта превращается в «черный ящик».

Привет! Меня зовут Антон, я ведущий программист департамента аналитических решений ЮMoney. Хочу поделиться историей о том, как наша команда ускорила один из самых рутинных процессов в работе дата-инженера — загрузку информации из нового источника данных в хранилище. Мы не просто оптимизировали процесс, а практически свели к нулю многодневную рутину и тем самым высвободили время для решения более интересных задач.

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

Когда система растёт, нагрузка на базу становится критичной, а готовых решений для шардирования PostgreSQL не хватает. Стандартные подходы не подошли — поэтому команда сделала свое решение для шардирования в ядре процессинга заказов. Оно позволяет решардировать данные без простоев и деградации метрик.

Привет, Хабр! Меня зовут Игорь Березняк, я руковожу группой процессинга в Техплатформе Городских сервисов Яндекса. В этой статье по мотивам моего доклада на Highload++ расскажу, как мы проектировали шардирование PostgreSQL, чтобы выдерживать нагрузку, сохранить доступность и уложиться в строгие требования по latency.

Transactional outbox обычно внедряют ради консистентности, а в итоге получают новый источник «случайной» задержки и постоянный фон нагрузки на базу из-за поллинга. В этой короткой статье разберем простой поворот идеи: не выбрасывая outbox и relay-процесс, попробовать отправлять событие сразу после коммита и превращать поллинг в редкий fallback. Посмотрим, что это даёт по задержкам и нагрузке, и какие неприятные нюансы всплывают с порядком доставки, дублями и наблюдаемостью.

Всем привет! Меня зовут Денис Захаров, я инженер в Автотеке Авито. В этой статье я расскажу о нелёгкой судьбе SRE на своём опыте: с чем я столкнулся в работе и как в общих чертах SRE-направление представлено в Авито. Статья будет полезна как разработчикам, так и малюткам, желающим узнать, что есть в мире IT. 

Мы сравнили OpenLiteSpeed и классический LEMP для WordPress на реальных серверах. RPS, latency, TTFB, потребление CPU и RAM, поведение под нагрузкой до 500 пользователей. И вот какие итоги у нас получились.