Привет, Хабр! Меня зовут Андрей Чернов, я Java-архитектор микросервисов в СберТехе — компании, которая создала цифровую облачную платформу Platform V для разработки бизнес-приложений. Наша команда развивает продукт Platform V SessionsData — высокопроизводительное распределённое in-memory-хранилище для общего контекста сессионных и key-value-запросов, которое СберБанк Онлайн использует в качестве микросервиса на своей серверной стороне. Продукт актуален не только для решения задач СберБанка Онлайн: он доступен рынку и может использоваться для аналогичных целей в любых отраслях.

В статье расскажу, почему мы решили создать собственный микросервис, чем он нам помогает, а также как мы справлялись с нагрузкой СберБанка Онлайн. У статьи будет продолжение. Во второй части поговорим о том, как мы достигаем высокой доступности сервиса, а в третьей — какие доработки нужны нам, чтобы развивать Platform V SessionsData.

У многих из нас, при использовании какого-либо инструмента программирования, возникал вопрос: “Как? Как это работает?”. Часто при возникновении подобных вопросов я обращаюсь к гуглу, который популярным образом рассказывает общие принципы работы того или иного механизма. Но наверняка среди читателей есть те, которые, прочитав несколько статей, подумали: "Да, это интересно и, вроде, понятно. Но все таки, как оно работает?".

Понимание размера объектов в Java — важный шаг для оптимизации памяти в высоконагруженных системах. 

В новом переводе от команды Spring АйО вы узнаете про использование HotSpot JVM таких механизмов, как сжатые указатели (Compressed Oops) и компактные заголовки объектов (Compact Object Headers), необходимых для минимизации объема занимаемой памяти.

Всем привет! Меня зовут Александр, и сегодня я расскажу о результатах перевода учебного проекта со Spring WebFlux и Netty на Spring MVC и Tomcat с виртуальными потоками и проверки обоих вариантов под нагрузкой в 2000rps. В качестве подопытного будет выступать система микросервисов, разработанная в рамках курса CloudJava.

В конце июля 2016 года в корпоративном блоге Uber появилась поистине историческая статья о причинах перехода компании с PostgreSQL на MySQL. С тех пор в жарких обсуждениях этого материала было сломано немало копий, аргументы Uber были тщательно препарированы, компанию обвинили в предвзятости, технической неграмотности, неспособности эффективно взаимодействовать с сообществом и других смертных грехах, при этом по горячим следам в Postgres было внесено несколько изменений, призванных решить некоторые из описанных проблем. Список последствий на этом не заканчивается, и его можно продолжать еще очень долго.

Наверное, не будет преувеличением сказать, что за последние несколько лет это стало одним из самых громких и резонансных событий, связанных с СУБД PostgreSQL, которую мы, к слову сказать, очень любим и широко используем. Эта ситуация наверняка пошла на пользу не только упомянутым системам, но и движению Free and Open Source в целом. При этом, к сожалению, русского перевода статьи так и не появилось. Ввиду значимости события, а также подробного и интересного с технической точки зрения изложения материала, в котором в стиле «Postgres vs MySQL» идет сравнение физической структуры данных на диске, организации первичных и вторичных индексов, репликации, MVCC, обновлений и поддержки большого количества соединений, мы решили восполнить этот пробел и сделать перевод оригинальной статьи. Результат вы можете найти под катом.

Привет, Хабр! Меня зовут Игорь Березняк, и мы с командой делаем Техплатформу Городских сервисов Яндекса. Я уже писал на Хабре про архитектуру платформы, рассказывал на «Хайлоаде» (и на Хабре) про шардирование и миграцию на YDB.

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

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

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

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

Привет! Меня зовут Саша Михеев, и я работаю в Авито над развитием персонализации пользователей. Делаю так, чтобы покупатели видели объявления, которые могут их заинтересовать. В статье рассказываю, как мы внедряли «трансформеры», чтобы улучшить рекомендации для пользователей.

Статья будет полезна data scientist-ам, ML-инженерам, ML-Ops-специалистам и продакт-менеджерам.

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

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

Я поставил себе OpenClaw — технология, которая взорвала интернет. Куча роликов, ии-экспертов и блоггеров начали показывать как они настроили себе личного помощника. Я две недели активно им пользуюсь. Решил записать ролик и собрать статью про важные аспекты работы с ним.

Сразу обозначу: не будет «это меняет мир», «я уволил всех сотрудников», «агенты работают вместо меня». Будет сухо, по делу: скучная, но реальная польза без хайпа. У данной статьи есть также видео-версия: VKVideo / YouTube.

Сколько будет корень из нуля? Даже школьник ответит не задумываясь: ноль. Но если задать этот вопрос JIT‑компилятору Maglev внутри движка V8, то при определённых обстоятельствах он сначала скажет: «ноль», а потом решит сэкономить на проверке безопасности и отдаст злоумышленнику доступ к памяти браузера.

Меня зовут Паша Кузьмин, я занимаюсь практической безопасностью Яндекс Браузера и проекта Chromium. В нашей команде мы регулярно разбираем уязвимости и исследуем методы атак — чтобы защищать пользователей до того, как их атакуют злоумышленники. Сегодня расскажу про CVE-2025-9864 — уязвимость, которую я нашёл в движке V8.

Это история о том, как безобидный Math.sqrt(0) превращается в use‑after‑free, а затем в произвольное чтение и запись памяти. Разберём проблему по шагам: от теории до работающего эксплойта.

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

В январе Дэвид Киппинг приехал в Принстон читать коллоквиум по астрономии. В коридоре Института перспективных исследований он разминулся с Эдом Виттеном — одним из отцов теории струн. Просто разминулся, как люди часто расходятся в коридорах. По этому же коридору ходили Эйнштейн, Оппенгеймер, Гёдель. Место не из тех, где привыкли потакать чуши.

А дальше завертелось.

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

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

Рынок массово предлагает бороться со вторым подбородком как с жиром: жечь его перцем или холодить ментолом, пока щипать не начнёт так, что уже не до красоты.

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

Всем привет!

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

Формально CI/CD в GitHub и GitLab решают одну и ту же задачу, но на практике подходы, терминология и детали конфигурации отличаются. Из-за этого попытки «сделать как в GitHub Actions» часто приводят к путанице и ошибкам.

У меня уже есть статья про CI/CD и workflow, но она целиком посвящена GitHub Actions. Чтобы сократить количество вопросов, разночтений и бессонных ночей у стажёров, я решил написать отдельную статью про CI/CD именно в GitLab — с учётом его особенностей и типичных подводных камней.

Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и практическими примерами из реальных проектов. А прямо сейчас у нас там ещё и проходит новогодний розыгрыш.

Привет! Меня зовут Владислав Миронов. Я отвечаю за внедрение LLM в процессы QA Яндекса и в этой статье расскажу, каких результатов мы достигли — от генерации тест‑кейсов и автотестов до помощи в ручном тестировании. Поделюсь не только успехами, но и тем, какие компромиссы и организационные решения понадобились, чтобы всё это заработало.

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

Спойлер: рассчитывать можно на многое, но и вложиться придётся основательно. Парой промптов тут, к сожалению, не обойтись.

Привет, дорогой читатель. Меня зовут Богдан Гончаренко, я ведущий продуктовый дизайнер, ex-EPAM и Сбер Казахстан. Я веду авторский телеграм-канал о продуктовом дизайне, исследованиях и т. д.

HADI – ответ на ваши проблемы, связанные с гипотезами. Все мы хотим, чтобы наша работа приносила результат. А чтобы всем было удобно, я сделал шаблон для Notion, который вы можете скопировать себе и использовать на здоровье. О шаблоне позже, а пока:

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

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).

В статье рассмотрим 3 способа настройки VPN-подключения с VLESS и Reality.

VLESS — это современный протокол передачи данных ориентированный на конфиденциальность, его еще часто называют VLESS VPN, хотя строго говоря, речь пойдет об установке прокси с протоколом VLESS на базе сервера XRay с Reality.

Начнем с самого простого и универсального варианта, не требующего технических знаний.