Инженерный дайджест — 2026-10-10

Risk Management

Financial Stability Board

Thematic review on public sector backstop funding mechanisms: Peer review report

Открыть оригинал ↗ Перевод заголовка: Тематический обзор механизмов государственной поддержки в сфере финансирования: отчёт о взаимной проверке

Большинство стран-членов ФСБ не реализуют ключевой атрибут 6 — наличие надёжного механизма государственной поддержки в случае разрешения банка, что ослабляет способность властей управлять системными банками и угрожает глобальной финансовой стабильности. Ключевой атрибут 6 предписывает наличие в случае нехватки собственных или рыночных ресурсов государственного механизма временного финансирования как последнего резерва, чтобы избежать хаотичного падения и траты налогоплательщиков. В отчёте оцениваются три аспекта: наличие механизма, способного обеспечить крупные объёмы и скорость финансирования при разрешении; наличие инструментов возврата расходов налогоплательщикам; и наличие мер, предотвращающих моральный риск и подчёркивающих «последний резерв» характер таких механизмов. Также представлены лучшие практики, уроки и общие трудности при внедрении таких механизмов.

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

Когда пригодится

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

Вопросы для размышления

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

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

Какие альтернативные инструменты могут заменить или дополнить государственную поддержку, не создавая морального риска и сохраняя эффективность разрешения?

FSB report assesses jurisdictions on public sector backstops

Открыть оригинал ↗ Перевод заголовка: Финансовая стабильность в Британии оценивает страны по механизмам государственной поддержки в секторе финансов

Отчёт Финансового совета по стабильности (FSB) оценивает готовность различных юрисдикций к предоставлению государственной финансовой поддержки при кризисе в банковской системе. Механизмы государственной поддержки (PBFs) рассматриваются как последний резерв, который позволяет избежать принудительного вхождения в публичное владение банка, если все другие источники ликвидности исчерпаны. Несмотря на прогресс, в большинстве стран остаются значительные пробелы в реализации рекомендаций FSB, и требуется ускорение действий до кризиса, а не реакция в условиях давления.

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

Когда пригодится

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

Вопросы для размышления

Какие конкретные компромиссы между прозрачностью и оперативностью могут возникнуть при реализации PBF в условиях политической нестабильности?

В каких условиях PBF может привести к увеличению системных рисков, если не сопровождается строгим контролем и оценкой рисков?

Какова сложность реализации PBF в странах с разными уровнями финансовой инфраструктуры и регуляторной зрелостью?

AI

Cloudflare Blog

Introducing Clef-omni with full multimodality, plus a faster Clef and a cheaper Clef-flash

Открыть оригинал ↗ Перевод заголовка: Вводится Clef-omni с полной мультимодальностью, а также более быстрый и дешёвый Clef и Clef-flash

Cloudflare представляет Clef-omni — модель, способную обрабатывать текст, изображения, аудио и видео в одном запросе, что кардинально расширяет возможности мультимодальных решений. В отличие от традиционных текстовых моделей, Clef-omni объединяет все модальности в единый поток, избегая сложных цепочек преобразований, таких как транскрипция или извлечение кадров. Модель основана на Qwen3-Omni-30B-A3B-Instruct с MoE, где устранены компоненты текст-к-аудио, но сохранена способность к одновременной обработке всех типов входных данных. В результате достигается высокая скорость и точность: текст — около 130 мс, изображения — 150 мс, а видео до 1,5 секунды, всё в одном API-запросе. Также Clef-omni демонстрирует сильные результаты на тестах, превосходя Jev по точности в ключевых задачах, включая обнаружение мошенничества и инвойсов.

Когда пригодится

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

Вопросы для размышления

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

Какова оценка надёжности и согласованности Clef-omni при обработке аудио и видео, если в них присутствуют шумы или нестабильные сигналы?

В каких условиях (по размеру, типу или структуре входных данных) может снизиться эффективность Clef-omni из-за несогласованности между модальностями?

Habr AI

LLM-разработка в 2026: навыки, кейсы, требования

Открыть оригинал ↗ Перевод заголовка: LLM-разработка в 2026: навыки, кейсы, требования

В 2026 году спрос на специалистов по LLM-разработке растёт, но кадрового дефицит остаётся серьёзной проблемой. Рынок активно ищет интеграторов, способных внедрять ИИ в бизнес-процессы, а не просто использовать модели как «магические инструменты». Основные технологии — RAG и агенты — позволяют создавать системы, которые понимают намерения пользователей и выполняют действия, такие как создание задач или отправка писем. Важно понимать, что эффективность не зависит от масштаба модели, а от правильного выбора инструмента: малые, открытые модели могут решать 90% задач дешевле и быстрее, чем большие. В продакшене критичны вопросы безопасности, утечек данных и метрик качества — особенно при работе с персональной информацией. Зарплаты варьируются от 110 000 до 250 000+ рублей, в зависимости от уровня и ответственности.

Когда пригодится

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

Вопросы для размышления

В каких условиях малая модель (например, GLM или Gemma) может быть не только эффективнее, но и безопаснее, чем большая модель, и как это влияет на архитектуру системы в корпоративной среде?

Какие риски и компромиссы связаны с использованием RAG для хранения внутренних данных, если не обеспечить фильтрацию персональной информации на уровне эмбеддинга?

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

MCP‑сервер 2ГИС: как мы учили LLM не выдумывать адреса

Открыть оригинал ↗ Перевод заголовка: MCP-сервер 2ГИС: как мы учили LLM не выдумывать адреса

МCP-сервер 2ГИС предоставляет ИИ-агентам прямой доступ к геоинструментам, таким как поиск мест, геокодирование и построение маршрутов, но ключевая проблема — модель может выдумывать адреса и координаты, когда данные отсутствуют. Решение заключается не в простом предоставлении доступа к данным, а в строгой валидации через контракт, где параметры и допустимые значения четко определены. В архитектуре используется слойная структура: от клиента до интеграции с API, что позволяет легко добавлять новые инструменты без дублирования кода. Ошибки классифицируются по типу: бизнес-ошибки (например, неверный регион) возвращаются как результат инструмента, а сетевые сбои — как протокольные ошибки, чтобы модель не повторяла вызовы. Важную роль играет введение «якорей» — явных ориентиров (например, названия городов или точек), которые должны быть заданы в запросе или преобразованы через геокодирование, чтобы избежать выдумывания координат. Также реализованы закрытые списки допустимых значений (например, типы транспорта или радиусов), что предотвращает невалидные запросы на входе.

Когда пригодится

Материал полезен для разработчиков, создающих системы с интеграцией ИИ-агентов и внешними API, особенно в гео-доменах. Он показывает, как избежать "выдумывания" данных при работе с LLM, обеспечивая надёжность и предсказуемость поведения моделей в реальных сценариях.

Вопросы для размышления

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

В каких условиях может быть допустимо оставить параметр радиуса опциональным, если он используется только в сочетании с координатами, и как это повлияет на оценку качества ответа при запросе "найди кофейню рядом"?

Какова сложность реализации валидации на уровне входа, если валидация должна проверять не только формат, но и смысл запроса (например, что "Москва" в тексте не означает точку в Воркуте), и как это влияет на производительность и масштабируемость MCP-сервера?

Нафиг NVIDIA! Я запустил Qwen на FPGA за $50 — а свой TPU назвал бы «КЕДР». Часть 1

Открыть оригинал ↗ Перевод заголовка: Нафиг NVIDIA! Я запустил Qwen на FPGA за $50 — а свой TPU назвал бы «КЕДР». Часть 1

Автор запустил крупную языковую модель Qwen на физической плате с FPGA (Xilinx Kintex-7) за $50, используя открытый проект openTPU. Результаты показали, что даже небольшая FPGA может выполнять инференс LLM — от 4 токенов в секунду для модели 35B до 86 токенов в секунду для LFM2.5. Это демонстрирует возможность создания специализированного AI-железа без участия крупных компаний, как NVIDIA или Google.

FPGA с 4 ГБ ОЗП может запускать инференс крупных моделей (включая Qwen3.5-35B) при использовании openTPU — это подтверждает практическую применимость открытых архитектур.
Процесс включает сборку прошивки в Vivado, настройку PCIe DMA и драйверов, что делает эксперимент доступным для инженеров без глубокого опыта в аппаратной разработке.
Ключевое отличие — не подбор железа под модель, а создание железа, оптимизированного под конкретные вычисления нейросети, что позволяет брать на себя контроль над архитектурой.
Платформа не конкурирует с H100, но даёт возможность тестировать идеи на физическом уровне, что важно для инициативы по разработке собственных AI-процессоров.
Проект демонстрирует переход от теоретических разработок к реальным экспериментам, где ИИ-агенты участвуют в проектировании, а человек — в испытаниях.

Когда пригодится

Материал полезен для разработчиков, интересующихся созданием собственных AI-ускорителей на низком уровне, особенно тех, кто хочет прототипировать архитектуру без инвестиций в дорогие GPU или ASIC.

Вопросы для размышления

Какова сложность и производительность настройки PCIe DMA и драйверов на Xilinx FPGA для модели Qwen3.5-2B при ограниченной памяти (4 ГБ)?

В каких условиях (например, при увеличении скорости памяти или переходе к более мощной FPGA) может снизиться разрыв между производительностью на FPGA и на TPU?

Какие риски и failure modes могут возникнуть при запуске LLM на FPGA с низким энергопотреблением и ограниченной памятью, особенно при работе с длинными последовательностями?

Быстрее пантеры: как студенческий проект Летней школы AIRI стал самым быстрым решением соревнования FLARE 2026

Открыть оригинал ↗ Перевод заголовка: Быстрее пантеры: как студентский проект Летней школы AIRI стал самым быстрым решением соревнования FLARE 2026

Проект студенческой команды из Летней школы AIRI, посвящённый поиску опухолей на КТ-снимках, стал лидером по скорости в соревновании FLARE 2026. Условия задачи были крайне жёсткими: модель должна была обнаруживать опухоли за 60 секунд на 4 ГБ видеопамяти, при этом половина снимков — от здоровых людей — требовала строгого отсутствия ложных срабатываний. В итоге модель PANTHER не только превзошла всех участников по скорости, но и сохранила высокую точность, несмотря на ограничения по ресурсам и разметке данных.

Ключевые тезисы:

Половина обучающей выборки (с умным составом) привела к +0.060 DSC по сравнению с полным набором — эффект состава данных оказался в разы сильнее, чем архитектурные улучшения.
Ансамбль из пяти фолдов с механизмом «промолчания» (среднее голосование) снизил ложные срабатывания на здоровых снимках с 100% до 8%, без отдельного классификатора и меток опухолей.
Фильтр Махаланобиса по форме маски, обученный на «ошибках» на здоровых снимках, удаляет 70% ложных находок, не снижая точности на реальных опухолях.
Инженерные оптимизации — перенос обработки в один процесс, уменьшение перекрытия окон, отключение TTA и ускорение интерполяции — позволили снизить время обработки до 11 секунд на снимок при пиковой видеопамяти 2.6 ГБ.
Модель PANTHER работает на полном ансамбле из пяти 3D U-Net (по 31 млн параметров), но остаётся в пределах лимитов по памяти и времени, несмотря на масштаб.

Когда пригодится

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

Вопросы для размышления

Как изменится эффективность фильтра по форме маски при переходе от «всё или ничего» к мягкому снижению доверия к маске, и как это повлияет на обнаружение мелких метастазов?

В каких условиях (размер патча, тип опухоли, плотность срезов) ансамбль с «промолчанием» может стать менее эффективным, и как это может быть компенсировано без увеличения вычислительных затрат?

Какова оценка риска потери чувствительности при использовании неразмеченных данных без псевдоразметки, если модель будет обучаться на «пустых» снимках с опухолями, которые она пропустила?

Централизуем использование ИИ при помощи Agentgateway

Открыть оригинал ↗ Перевод заголовка: Централизуем использование ИИ при помощи Agentgateway

Agentgateway — это open-source шлюз для ИИ, разработанный на Rust и входящий в Linux Foundation, который позволяет централизовать доступ к LLM-провайдерам и MCP-серверам, устанавливать лимиты на токены и контролировать безопасность запросов. Он поддерживает управление трафиком, авторизацию, трансформацию запросов и мониторинг, с возможностью настройки политик на разных уровнях — от ворот до бэкендов. Проект предлагает два способа развертывания: standalone и Kubernetes, с поддержкой HTTPS, защиты конфиденциальных заголовков и настройки цен за токены.

AGW обеспечивает централизованный контроль над доступом к LLM и MCP, включая лимиты по токенам и блокировку опасных команд.
Позволяет настраивать политики безопасности на уровне ворот, дорог и бэкендов, включая авторизацию по JWT или API-ключам и маскировку конфиденциальных заголовков.
Поддерживает интеграцию с внешними системами через OIDC и позволяет визуализировать потребление токенов в реальном времени.
Конфигурация хранится в файле config.yaml, который можно сделать неизменяемым для предотвращения несанкционированных изменений.
Шлюз не передаёт исходные конфиденциальные заголовки бэкендам, но сохраняет их для работы в выражениях CEL, что важно для мониторинга и политик.

Когда пригодится

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

Вопросы для размышления

Какие риски могут возникнуть при использовании политики маскировки заголовков, если в выражениях CEL всё же требуется доступ к исходным данным?

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

Какой вклад в производительность и отказоустойчивость может оказать развертывание AGW в Kubernetes по сравнению с standalone, особенно при высокой нагрузке на LLM-серверы?

InfoQ Architecture

Android Bench 2 Adds Support for Long-Horizon Tasks, Agentic Evaluation, and Continuous Scoring

Открыть оригинал ↗ Перевод заголовка: Android Bench 2 добавляет поддержку долгосрочных задач, агентной оценки и непрерывной оценки

Новая версия Android Bench 2.0 расширяет оценку AI-агентов на задачи разработки Android, вводя долгосрочные задачи (LHT), оценку на основе агентов и систему непрерывной оценки. В отличие от предыдущей версии, где задачи оценивались как «прошло» или «не прошло», новая система использует непрерывную шкалу, учитывающую функциональность, визуальную целостность и отсутствие регрессий, а также вводит штрафы за отклонения от инструкций. Результаты показывают, что AI эффективнее справляется с написанием нового кода, чем с рефакторингом, и успешно работает на детерминированных трансформациях, таких как конвертация Java в Kotlin, но сталкивается с трудностями при работе с динамическими проверками, изменениями архитектуры или непубликуемыми библиотеками.

Долгосрочные задачи (LHT) имитируют реальные сценарии разработки, требующие от агента нескольких дней или даже недели для завершения, включая миграцию приложений и добавление новых функций.
Оценка теперь агентно-ориентирована: модели оцениваются на основе их поведения в реальных сценариях, а не только по пассивным тестам.
Внедрена непрерывная оценка, которая учитывает не только успешное выполнение, но и степень соответствия инструкциям, структурным ограничениям и качеству результата.
Показатели качества демонстрируют разрыв между типами задач: AI справляется хорошо с преобразованиями, но не достигает 100% в миграции приложений, что указывает на сложность понимания архитектуры.
Результаты включают сравнение моделей, таких как Gemini 3.8 Flash, GPT-6, Fable 5.1 и др., где Claude Opus 5.5 показал лучший результат (32% LHT pass rate), но все модели остаются на уровне, требующем дальнейшего улучшения.

Когда пригодится

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

Вопросы для размышления

В чём заключается компромисс между объёмом долгосрочной задачи и возможностью её автоматической оценки — как избежать переоценки или упущений в оценке прогресса?

Какие критерии могут быть использованы для определения границ применимости LHT-задач, чтобы избежать ситуаций, когда агент «заблудился» в неопределённых или непроверяемых условиях?

При каких условиях (например, масштабе кода, типе задачи, уровне доступа к зависимостям) вероятность сбоев в оценке LHT может вырасти, и как это может повлиять на надёжность и согласованность результатов?

Latent Space

Why AlphaFold Didn't Solve Protein Folding — Pushmeet Kohli, Google DeepMind & Sal Candido, Biohub

Открыть оригинал ↗ Перевод заголовка: Почему AlphaFold не решил задачу сворачивания белков — Pushmeet Kohli, Google DeepMind & Sal Candido, Biohub

Панельный диалог между экспертами из DeepMind и Biohub раскрывает ключевые ограничения подхода к разработке ИИ на основе масштабирования: просто увеличение вычислительных ресурсов или объёма данных не решает фундаментальных проблем биологии. Успешность моделей зависит не от размера, а от качества данных и научной интуиции, встроенной в архитектуру. Важно понимать, что AlphaFold не решил задачу полного понимания белков — он лишь успешно предсказывает статические структуры, игнорируя динамику, неорганизованные участки и контекстуальные изменения. Для достижения глубокого понимания биологических систем необходимы новые данные (например, крио-ЭМ-снимки) и переход от моделей отдельных белков к целостным виртуальным клеткам.

Ключевая ошибка в подходе к ИИ — это пренебрежение качеством данных: «хорошие» данные, а не просто большие объёмы, определяют эффективность модели.
Научная интуиция (например, знание о взаимодействии аминокислот) должна быть встроена в архитектуру, а не ожидать её от масштабирования.
AlphaFold не решает задачу динамики белков, неорганизованных структур и функционального поведения — эти аспекты остаются открытыми.
Путь к революции в биомедицине требует не небольших улучшений, а 10-кратных прорывов, основанных на фундаментальном понимании биологических систем.
Будущие ИИ-модели должны не просто предсказывать, а «понимать» биологические процессы, включая динамику и нелинейные взаимодействия.

Когда пригодится

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

Вопросы для размышления

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

В каких условиях (по сложности, размеру данных, архитектуре) встраивание научной интуиции в модель может быть более эффективным, чем масштабирование на основе стандартных трансформеров?

Какова граница применимости использования крио-ЭМ-данных для обучения моделей белков, если их интерпретация требует глубокого понимания динамики, а не только статических структур?

Java / Spring

Habr Java

Оптимизация генерации ресурсов в Java, три Ryzen и 225 замеров

Открыть оригинал ↗ Перевод заголовка: Оптимизация генерации ресурсов в Java, три Ryzen и 225 замеров

В статье исследуется, почему в задаче генерации природных ресурсов в игровом движке на Java реализация с ручным разбиением массива на части оказалась быстрее, чем более компактная версия с использованием параллельных потоков и parallel().collect(). Основная задача — выбрать K кандидатов с учётом весов вероятности без повторов, что требует эффективного управления памятью и вычислительной сложностью. Три реализации: последовательная, параллельная с ручным разбиением и оптимизированная с parallel().collect() — сравниваются по скорости на трёх компьютерах с процессорами AMD Ryzen.

Ручное разбиение массива на части позволяет точно контролировать количество параллельных задач, что снижает накладные расходы на создание и объединение локальных очередей.
Вариант с parallel().collect() требует больше выделения памяти из-за создания множества локальных PriorityQueue, что увеличивает нагрузку на сборщик мусора.
Объединение результатов в parallel().collect() может быть менее эффективным при неравномерной нагрузке, так как Stream API не гарантирует оптимальное распределение задач.
Неравномерная сложность обработки клеток (от нулевого веса до многоуровневых проверок) делает ручное разбиение более предсказуемым и эффективным в реальных условиях.

Когда пригодится

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

Вопросы для размышления

В каких условиях ручное разбиение массива может быть быстрее, чем parallel().collect(), если количество потоков и размер данных изменяются?

Какова сложность по времени и памяти объединения локальных Top-K очередей при разных количествах потоков и размерах частей массива?

При каких параметрах профиля генерации (например, веса клеток, количество уровней залегания) ручное разбиение становится неэффективным по сравнению с parallel().collect()?

Habr Spring

[Перевод] Kotlin получил почти настоящие статики

Открыть оригинал ↗ Перевод заголовка: Kotlin получил почти настоящие статики

Kotlin внедряет экспериментальные блоки-компаньоны и расширения-компаньоны, которые позволяют объявлять статические члены классов без использования объектов-компаньонов. Эти механизмы компилируются как статические элементы на JVM, что делает их совместимыми с Java и открывает возможности для Kotlin Multiplatform, включая ожидаемые члены в разных платформах. Блоки-компаньоны и расширения-компаньоны могут применяться к любому типу, независимо от доступа к исходному коду, и позволяют избежать ограничений объектов-компаньонов.

Блоки-компаньоны можно использовать для определения статических констант и функций в классах, что упрощает структурирование кода и делает его более прозрачным.
Расширения-компаньоны позволяют добавлять члены к типу без доступа к его исходному коду, что особенно полезно при работе с библиотеками на Java или Kotlin.
Для использования этих возможностей требуется включить флаги -Xcompanion-blocks или -Xcompanion-blocks-and-extensions, при этом бинарные файлы помечаются как предварительные версии.
Существующие объекты-компаньоны остаются поддерживаемыми, но в новых проектах рекомендуется использовать блоки-компаньоны, особенно если требуется совместимость с Java.
При миграции необходимо перекомпилировать весь проект и его зависимости, а некоторые инструменты могут не поддерживать новые синтаксисы.

Когда пригодится

Материал полезен при разработке библиотек или компонентов, где требуется объявлять статические функции или константы для типов без доступа к исходному коду, а также при построении мультиплатформенных приложений с использованием Kotlin Multiplatform.

Вопросы для размышления

В каких сценариях объекты-компаньоны остаются незаменимыми, несмотря на наличие блоков-компаньонов?

Какие риски связаны с использованием расширений-компаньонов в production-проектах, если они не поддерживаемы инструментами экосистемы?

При каких условиях блоки-компаньоны могут привести к увеличению размера бинарного файла или снижению производительности компиляции?

HowToDoInJava

Best Machine Learning Libraries for Java in 2026

Открыть оригинал ↗ Перевод заголовка: Лучшие библиотеки для машинного обучения на Java в 2026 году

В 2026 году для классического машинного обучения на структурированных данных в Java лучшими остаются Smile и Tribuo, а для запуска моделей, обученных в Python, — DJL и ONNX Runtime. Weka подходит для обучения и экспериментов, Spark MLlib — для больших объёмов данных, не помещающихся в память одной машины. Выбор библиотеки зависит от того, где происходит обучение: в Java или в Python, и от лицензионных требований продукта.

Smile — мощная библиотека с широким набором алгоритмов, но требует лицензии для закрытого ПО, включая SaaS и внутренние приложения.
Tribuo предлагает типизированный API и полный трек модели (provenance), что важно для аудита, но обновления редки и отстают по скорости.
Weka — идеален для обучения и визуализации, но устарел по API и имеет GPL-лицензию.
DJL и ONNX Runtime — лучшие решения для инференса моделей, обученных в Python, с поддержкой PyTorch, TensorFlow и ONNX.
Spark MLlib — необходима для распределённого обучения на больших данных, но неэффективна при небольших объёмах.

Когда пригодится

Материал полезен при выборе библиотеки для Java-проекта, где важны лицензия, производительность, архитектура инференса или необходимость аудита моделей. Особенно актуален для команд, работающих с моделями, обученными в Python, и для тех, кто хочет интегрировать ML в закрытые приложения с соблюдением правовых требований.

Вопросы для размышления

В каких сценариях Tribuo может быть неоптимальным, несмотря на наличие трека модели и Apache-лицензии?

Какой компромисс между производительностью и функциональностью в Smile и Tribuo при использовании в production-системах с ограниченными ресурсами?

При каких условиях ONNX Runtime становится предпочтительнее DJL, несмотря на меньшую гибкость в выборе движка?

Best Java IDEs for AI Coding, Testing and CI/CD (2026)

Открыть оригинал ↗ Перевод заголовка: Лучшие IDE на Java для разработки с AI, тестирования и CI/CD (2026)

В 2026 году IntelliJ IDEA остаётся лучшим выбором для команд, уже оплативших его лицензию, особенно при работе с Spring Boot и Maven/Gradle. VS Code с GitHub Copilot — оптимальный бесплатный вариант, особенно если код уже хранится на GitHub. Cursor и Devin Desktop предлагают агенты, работающие автономно и параллельно, что делает их идеальными для сложных, динамичных задач. Eclipse остаётся актуальным только в случае существующей инфраструктуры, основанной на этом IDE. Все рассматриваемые IDE поддерживают несколько моделей ИИ, и ни одна модель не доминирует во всех задачах — поэтому в рекомендациях указаны поставщики, а не конкретные модели. Каждая IDE предоставляет данные о ценах, поддержке тестирования и CI/CD, а также о наличии официальных плагинов от ведущих ИИ-компаний.

Когда пригодится

Материал полезен при выборе IDE для команды, работающей с Java и стремящейся интегрировать ИИ-ассистенты в процесс разработки, включая автоматическое писание тестов, исправление ошибок в CI и работу с большими проектами. Особенно актуален для тех, кто хочет минимизировать затраты, использовать локальные модели или реализовать агентную архитектуру с параллельной работой ИИ-агентов.

Вопросы для размышления

В чём заключается компромисс между использованием локальных моделей (например, через Ollama) и производительностью при больших рефакторингах в IntelliJ IDEA?

Какова сложность и надёжность агентной системы в Cursor и Devin Desktop при работе с несколькими файлами и параллельными задачами?

При каких условиях использование Copilot Cloud Agent в VS Code или Eclipse становится более эффективным, чем работа с локальными агентами в IntelliJ IDEA?

LLM Token Costs: Estimate and Reduce Them in Java Apps

Открыть оригинал ↗ Перевод заголовка: Оценка и снижение затрат на токены в Java-приложениях с использованием LLM

Затраты на вызов LLM рассчитываются как сумма входных токенов, умноженных на цену входных токенов, плюс выходные токены, умноженные на цену выходных токенов. В Java-приложениях, где каждый запрос включает системную подсказку, историю диалога и документы из RAG, большая часть затрат приходится на повторяющиеся части входных данных. Оптимизация достигается за счёт сокращения количества токенов или выбора более дешёвых моделей. В статье представлены практические методы оценки затрат, включая расчёт с учётом кэширования токенов, подсчёт токенов в Java и интеграцию с Spring AI для получения реальных метрик.

Использование кэширования входных токенов (например, системной подсказки) позволяет сократить затраты на 48–60% за счёт использования дешёвых "кэшированных" токенов.
Выбор меньшего модели (например, Claude Haiku или Gemini Lite) может снизить стоимость до 5–28% от цены среднего размера, при этом сохраняя достаточную точность ответов.
Ограничение длины ответа и усечение истории диалога снижают затраты на выходные токены — наиболее дорогую часть расходов.
В RAG-системах можно сократить объём передаваемых документов, выбирая только наиболее релевантные фрагменты, при этом проверяя, не теряется ли важная информация.
Spring AI предоставляет доступ к реальным метрикам использования токенов через интерфейс Usage, позволяя в реальном времени отслеживать расходы и выявлять "горячие" участки.

Когда пригодится

Материал полезен для разработчиков, внедряющих LLM в Java-приложения, где важна экономичность расходов, особенно в условиях высокой нагрузки или регулярных запросов с длинными контекстами.

Вопросы для размышления

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

При каких условиях кэширование токенов становится неэффективным — например, при низкой частоте запросов или при динамичных запросах, где контекст меняется быстро?

Какова сложность и надёжность реализации маршрутизации по сложности запросов (например, на основе длины или темы), если она должна быть простой и не зависеть от внешних API?

LLM Terms Every Developer Should Know (Glossary)

Открыть оригинал ↗ Перевод заголовка: Термины LLM, которые каждый разработчик должен знать (словарь)

LLM — это модель, которая посимвольно анализирует текст и предсказывает следующий элемент, пока не сформирует полный ответ. Большинство терминов описывают один из этапов этого процесса: от разбиения текста на токены до ограничений по длине контекста и стоимости запроса. Разработчики в Java сталкиваются с этими терминами в настройках Spring AI и LangChain4j, в документации по поставщикам и на страницах цен. Понимание этих терминов помогает объяснить, почему запросы завершаются ошибкой из-за превышения контекста, почему один и тот же промпт даёт разные ответы и почему стоимость растёт при длительных диалогах.

Практические тезисы:
— Токен — не слово, а фрагмент текста, который может быть частью слова или символом; в английском языке 100 слов ≈ 130 токенов.
— Контекстная длина ограничивает общий объём входных и выходных токенов в одном запросе, и превышение приводит к ошибке.
— Параметры, такие как температура и top-p, влияют на случайность ответа: низкие значения делают ответы предсказуемыми, высокие — более неожиданными.
— RAG позволяет включать в промпт актуальные документы в реальном времени, в отличие от тонкой настройки модели.
— Стоимость запроса зависит от количества входных и выходных токенов, причём выходные токены дороже входных.

Когда пригодится

Материал полезен при проектировании интеграции LLM в приложение на Java, особенно при работе с Spring AI или LangChain4j, где важно понимать, как токенизация, контекст и стоимость влияют на производительность и бюджет.

Вопросы для размышления

Какой компромисс между точностью и стоимостью может возникнуть при выборе значения температуры и top-p в RAG-системе, если ответ должен быть как можно более предсказуемым, но при этом не терять смысл?

В каких условиях использование RAG может привести к увеличению времени ответа, и как это может повлиять на производительность при высокой нагрузке на сервер?

Почему при работе с открытыми моделями (open-weight) и локальными запусками (например, через Ollama) важно учитывать разницу в токенизации между моделями, и как это может повлиять на корректность обработки кода?

Model Context Protocol (MCP) Explained for Java Developers

Открыть оригинал ↗ Перевод заголовка: Модельный контекстный протокол (MCP) объясняется для разработчиков Java

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

Ключевые практические тезисы:

MCP стандартизирует доступ к инструментам, позволяя одному серверу работать с любым клиентом, поддерживающим протокол, без необходимости переписывать интеграции.
Серверы не знают о моделях AI и выполняют только определённые инструменты по запросу клиента, что обеспечивает изоляцию логики и безопасность.
Протокол использует JSON-RPC, что делает его прозрачным и легко отладываемым без специальных клиентов.
Важны правила безопасности: каждая функция должна иметь минимальные права, а входные данные должны проверяться, чтобы предотвратить утечку данных или атаки типа «tool poisoning».
Для работы с новыми версиями протокола (например, 2026-07-28) требуется обновлённый SDK, так как старые версии не поддерживают новые функции.

Когда пригодится

Материал полезен, когда разработчик хочет интегрировать внешние системы (например, базу данных, систему заказов) в AI-приложение без переписывания кода для каждого инструмента, особенно в средах, где используются IDE-ассистенты, Spring AI или LangChain4j.

Вопросы для размышления

Какой компромисс между безопасностью и удобством возникает при использовании инструментов с минимальными правами, если они должны работать в разных средах (например, в IDE и в production-приложении)?

В каких условиях (по сложности, нагрузке, типу запросов) может начаться failure mode в MCP-сервере, если не проверять аргументы инструмента или не ограничивать частоту вызовов?

Какой альтернативный подход к интеграции может быть эффективнее, если система не может быть вынесена в отдельный MCP-сервер, но всё же нужна безопасная передача данных в AI-модель?

JUnit 5 vs JUnit 6: What’s New and Migration Guide

Открыть оригинал ↗ Перевод заголовка: JUnit 5 против JUnit 6: что нового и руководство по миграции

JUnit 6 — это эволюция JUnit 5, а не полная перестройка, и большинство тестов из JUnit 5 продолжают компилироваться и работать в JUnit 6 после простой замены версии. Основное изменение — повышение минимальной версии Java до 17, удаление устаревших API и унификация версий платформы, Jupiter и Vintage. Миграция требует обновления BOM и проверки устаревших зависимостей, особенно в тестах, использующих @RunWith или параметризованные тесты с нестандартными CSV-данными. Важные изменения касаются отображения параметров тестов, строгого парсинга CSV и порядка выполнения тестов в вложенных классах.

Устаревшие API (например, MethodOrderer.Alphanumeric, @EnabledForJreRange) убраны, требуют замены на новые аналоги (например, MethodName).
Параметризованные тесты теперь отображают аргументы в кавычках (например, "apple" вместо fruit=apple), что может привести к несоответствию в отчётах CI.
Парсинг CSV стал строже: валидные строки в JUnit 5 могут быть отклонены в JUnit 6 при наличии ошибок в кавычках.
Порядок выполнения тестов в вложенных классах (@Nested) теперь строгий и неалфавитный, что требует пересмотра зависимостей между тестами.
В JUnit 6 появляются встроенные расширения для настройки локали, временной зоны и системных свойств, что упрощает тестирование в разных средах.

Когда пригодится

Материал полезен для команд, которые уже используют Java 17+, работают с CI-инструментами и планируют миграцию с JUnit 5 на JUnit 6, особенно если в проекте есть параметризованные тесты, вложенные классы или зависимость от локали/временной зоны.

Вопросы для размышления

Какой компромисс между строгим парсингом CSV в JUnit 6 и необходимостью поддерживать совместимость с существующими тестовыми данными в формате CSV?

В каких условиях вложенные тесты в @Nested могут быть особенно уязвимы к изменению порядка выполнения, и как это может повлиять на стабильность тестов в CI?

Какова сложность и границы применимости встроенных расширений по настройке локали и системных свойств в реальных проектах с разными настройками сред выполнения?

What Is Data Analytics and How Can You Get Started?

Открыть оригинал ↗ Перевод заголовка: Что такое аналитика данных и как начать?

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

Ключевые практические тезисы:

Аналитика начинается с чёткого вопроса (например, «какой продукт приносит больше дохода»), а не с данных.
Очистка данных (удаление дубликатов, заполнение пропусков) занимает больше времени, чем анализ, и является критически важной для точности.
SQL — основной инструмент для извлечения данных из баз, Python — для обработки больших файлов и визуализации.
Процесс аналитики включает 6 шагов: постановка вопроса, сбор, очистка, анализ, презентация и принятие решения.
Новичкам рекомендуется начинать с таблиц, затем SQL, затем Python, и завершать на реальном проекте с публикацией в портфолио.

Когда пригодится

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

Вопросы для размышления

В чём заключается компромисс между скоростью анализа (например, в Excel) и точностью (например, при очистке дубликатов), и как это влияет на принятие решений в условиях ограниченного времени?

Какие риски связаны с использованием AI-инструментов для генерации SQL-запросов, если аналитик не проверяет корректность и не понимает логики запроса?

При каких масштабах (например, 1000 vs 100 000 строк) становится оправданным переход от SQL к Python с pandas, и как это влияет на производительность и надёжность анализа?

System Design

Cloudflare Blog

Introducing on-demand CPU and memory profiling with flamegraphs for Workers and Durable Objects

Открыть оригинал ↗ Перевод заголовка: Введение в на-demand профилирование CPU и памяти с flamegraphs для Workers и Durable Objects

Новое профилирование в реальном времени позволяет выявлять, где в коде происходит избыточное использование CPU или памяти, что невозможно сделать с помощью логов или агрегированных метрик. Теперь разработчики могут запрашивать на-demand профили CPU или памяти для активных Workers и Durable Objects, получать их в виде интерактивных flamegraph и анализировать вручную или с помощью внешних инструментов. Профилирование в производственной среде даёт наиболее точную картину поведения приложения, особенно при оптимизации производительности и устранении ошибок OOM.

Профилирование в реальном времени позволяет идентифицировать функции с высоким потреблением ресурсов — например, рекурсивные вызовы или дублированные операции, как в случае с genericR2JsonReplacer.
При анализе памяти профилирование выявляет неактивные, но включённые кодовые пути (например, Prometheus), которые не отключены полностью и тратят память, несмотря на отсутствие использования данных.
Для Durable Objects доступно профилирование конкретного объекта по имени, что позволяет точно отследить состояние и поведение конкретного экземпляра в любой точке мира.
Профилирование не блокирует выполнение кода — изолированная среда освобождается после запуска, позволяя приложению продолжать работать.
Ограничения включают необходимость ручного запуска и отсутствие данных о памяти при старте, что делает профилирование неэффективным для отслеживания ранних этапов запуска.

Когда пригодится

Материал полезен при диагностике производительности в реальном времени, особенно при поиске узких мест в CPU или памяти, при устранении ошибок OOM, и при анализе поведения конкретного экземпляра Durable Object в условиях нагрузки.

Вопросы для размышления

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

Какова сложность и границы применимости профилирования памяти в моменты старта приложения, если профиль не включает начальные аллокации?

При каких условиях Durable Object может быть профилирован с высокой точностью, и как это влияет на масштабируемость и надёжность профилирования в распределённой архитектуре?

DEV System Design

The First Cut: How Module Boundaries Get Drawn and Why They Drift

Открыть оригинал ↗ Перевод заголовка: Первый резец: как формируются границы модулей и почему они смещаются

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

Границы модулей должны быть локально предсказуемыми: любой опытный разработчик должен без просмотра кода понимать, где находится логика по определённой бизнес-функции.
В языках с компиляторной защитой (Go, Rust) или в конфигурациях с явными правилами (TypeScript, Java) границы могут быть зафиксированы на уровне языка — например, через internal/ или pub(crate).
Миграции в базе данных должны быть неизменными и проверяемыми криптографически, чтобы избежать рисков при изменении схемы.
Работа с зависимостями должна строиться по принципу "зависеть от стабильных, не зависеть от нестабильных" — с помощью метрик афферентного и ефферентного куплинга.
Важно включать автоматические проверки в CI/CD (например, через ArchUnit или Packwerk), чтобы нарушения границ не проходили в релизы.

Когда пригодится

Материал особенно полезен при проектировании крупных монолитных систем, где требуется поддерживать стабильность и избежать роста технического долга под давлением сроков, особенно в условиях активного использования ИИ для генерации кода.

Вопросы для размышления

Как изменится поведение системы при введении AI-генерации кода, если в репозитории отсутствуют жёсткие границы и проверки в CI, и какие риски это создаёт в долгосрочной перспективе?

В каких условиях и на каких этапах вводить метрики куплинга (например, Instability Metric) в процесс ревью PR, чтобы они не стали формальностью и действительно повлияли на принятие решений?

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

System Design for Physical AI: Building Beyond Cloud APIs and Webhooks

Открыть оригинал ↗ Перевод заголовка: Архитектура для физического ИИ: создание за пределами облачных API и веб-хуков

Традиционные подходы к проектированию систем, ориентированные на веб-приложения, не подходят для физических систем с ИИ — таких как производственные линии или автономные машины. В таких системах критичны ограничения на краю, включая задержки, потери пакетов, шум сенсоров и необходимость нулевой остановки оборудования. Архитектура предложена как «четырёхдвигательная» модель: идентификация, сбор данных, принятие решений и выполнение действий, где каждый модуль работает независимо и с минимальной задержкой. Важно, что локальные инференс-модели (например, ONNX, TensorRT) запускаются на устройствах вроде NVIDIA Jetson или Coral, а действия (например, включение реле или PLC) выполняются без привлечения облачных ресурсов. Система обеспечивает синхронизацию с облаком только при наличии соединения, что позволяет избежать задержек и обеспечить надёжность в реальном времени.

Идентификация физического актива (с помощью RFID, BLE, UWB) позволяет корректно связать сенсорные данные с конкретным объектом.
Сбор данных в высокой частоте (MQTT, CoAP, Modbus) с предварительной нормализацией и фильтрацией снижает нагрузку на систему и улучшает качество входных данных.
Локальный инференс на краю (ONNX/TensorRT) позволяет быстро принимать решения без зависимости от облака, что критично для реального времени.
Действия (реле, PLC) выполняются непосредственно на уровне оборудования, обеспечивая быструю реакцию и отказоустойчивость.

Когда пригодится

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

Вопросы для размышления

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

В каких сценариях локальный инференс (ONNX/TensorRT) может быть менее надёж, чем облако, и как это влияет на выбор архитектуры?

Какова сложность и масштабируемость четырёхдвигательной архитектуры при расширении на десятки или сотни физических активов?

System Design Fundamentals: The 5 Dimensions of Scalability — Data, Complexity & Geographic Growth

Открыть оригинал ↗ Перевод заголовка: Основы проектирования систем: пять измерений масштабируемости — данные, сложность и географическое расширение

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

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

Когда пригодится

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

Вопросы для размышления

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

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

Какие failure modes могут возникнуть при неправильной оценке того, что именно растёт, и как это может привести к ухудшению производительности или росту затрат?

MySQL Transaction Isolation Levels: Dirty Reads, Non-Repeatable Reads, and Phantom Reads

Открыть оригинал ↗ Перевод заголовка: Уровни изоляции транзакций в MySQL: чистые чтения, неповторяемые чтения и фантомные чтения

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

Уровень Read Uncommitted позволяет читать неочищенные данные (dirty reads), что снижает задержки, но ведёт к несогласованности данных — опасно в production.
Уровень Read Committed исключает dirty reads, но может приводить к неповторяемым чтениям (non-repeatable reads) из-за изменений в данных между двумя запросами.
Уровень Repeatable Read (по умолчанию в InnoDB) предотвращает неповторяемые чтения и фантомные чтения за счёт next-key locking, но может вызывать блокировки и снижать производительность при высокой нагрузке.
Уровень Serializable обеспечивает полную изоляцию, но вводит значительные задержки и может привести к deadlock-ошибкам в высоконагруженных системах.

Когда пригодится

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

Вопросы для размышления

В каких сценариях можно безопасно использовать Read Uncommitted без риска для целостности данных, и как это может быть оценено в production?

Какие компромиссы между производительностью и изоляцией возникают при использовании Repeatable Read в системах с высокой нагрузкой и частыми транзакциями?

При каких условиях фантомные чтения могут привести к необратимым сбоям, и как можно предотвратить их без использования Serializable?

How Databases Scale to Millions of Reads and Writes per Second

Открыть оригинал ↗ Перевод заголовка: Как базы данных масштабируются до миллионов операций чтения и записи в секунду

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

Репликация (primary-replica): данные копируются в реплики, чтение распределяется между ними, но с возможной задержкой — в случае, если пользователь видит старые данные после публикации.
Кэширование: вводится слой в-памяти (Redis/Memcached), который сокращает нагрузку на базу до 1–5% запросов при 90–99% попадания.
Предотвращение «стампед»: при истечении срока действия кэша тысячи запросов могут одновременно попасть в базу — решается с помощью синхронизации запросов и вероятностного раннего обновления.
Индексы и денормализация: индексы ускоряют поиск, а денормализация заменяет дорогостоящие JOIN-запросы на прямые поиски в копиях данных.
Шардинг: данные распределяются по узлам по ключу, при этом важно избегать «горячих ключей» и выбирать высококардинальные ключи (например, хэш-ключи).
LSM-деревья и очереди: для записи используются LSM-структуры (RocksDB, Cassandra), обеспечивающие высокую производительность при записи, но с ростом задержки при чтении и потребностью в фоновом слиянии файлов.

Когда пригодится

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

Вопросы для размышления

В каких сценариях допустимо потерять данные при использовании write-behind кэширования, и как это влияет на надёжность в production-среде?

Какой из вариантов шардинга (по диапазону или по хэшу) лучше подходит для системы с ростом нагрузки по ID-пользователей, и как это влияет на сложность запросов по диапазону?

При каких условиях LSM-деревья могут привести к росту задержки при чтении, и как это может повлиять на производительность при запросах с высокой частотой и низкой задержкой?

Inventory reservation in MySQL: Shopify's row-lock design

Открыть оригинал ↗ Перевод заголовка: Резервирование запасов в MySQL: архитектура Shopify с использованием блокировок строк

Shopify перенёс резервирование запасов из Redis в MySQL, сохранив при этом целостность данных и обеспечивая корректную работу при параллельных запросах. Вместо единого счёта запасов используется ограниченный набор строк — один ряд на один доступный единицу товара, что позволяет избежать конфликтов блокировок и обеспечивает эффективную работу при одновременных заказах. Ключевыми элементами являются короткие транзакции, использование опции SKIP LOCKED для выбора доступных строк и четкое разделение этапов резервирования и подтверждения заказа.

Вместо единого счёта запасов используется ограниченный пул строк (до 1000 единиц на товар/локацию), что позволяет избежать конфликтов блокировок и обеспечивает эффективную работу при параллельных запросах.
Опция SKIP LOCKED в MySQL позволяет запросу пропускать заблокированные строки и выбирать другие доступные, что делает процесс резервирования более гибким и устойчивым к задержкам.
Резервирование и подтверждение заказа разделяются по времени: резервирование создаёт временный запас, а подтверждение — фиксирует изменения в логе запасов, что обеспечивает надёжность при сбоях.
Каждый запрос работает с отдельными строками, а не с общим счётчиком, что снижает вероятность конфликтов и улучшает масштабируемость.
Несмотря на эффективность, система требует тщательной настройки: отсутствует гарантия FIFO, возможны ошибки при интерпретации пустого результата, и требуется явная политика по устранению неиспользованных резерваций.

Когда пригодится

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

Вопросы для размышления

Как определить, является ли пустой результат SKIP LOCKED признаком полного продажи товара, если пулинг может быть заполнен в будущем?

В каких условиях может возникнуть сбой при резервации, если резервация не удаляется из пула при отмене заказа, и как это повлияет на общую надёжность системы?

Какова сложность и масштабируемость архитектуры при увеличении количества товаров и локаций, если каждый товар имеет свой ограниченный пул в 1000 строк?

DesignGurus

Push vs Pull: The Trade-offs You Should Explain in a System Design Interview

Открыть оригинал ↗ Перевод заголовка: Пуш vs Пул: Варианты, которые нужно объяснить в интервью по проектированию систем

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

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

Когда пригодится

Материал полезен при проектировании систем, где критична задержка доставки уведомлений (например, доставка заказов), и когда важно минимизировать нагрузку на сервер или обеспечить отказоустойчивость при нестабильности клиентов.

Вопросы для размышления

Как изменится производительность пул-системы при увеличении числа клиентов в 10 раз, если интервалы запросов не меняются, и какие риски возникают при этом?

В каких сценариях пуш-модель может привести к утечке ресурсов на сервере, и как это может повлиять на масштабируемость при росте числа пользователей?

Какой из подходов (пуш или пул) лучше подходит для системы, где потребители могут быть нестабильными (например, мобильные приложения), и почему?

InfoQ Architecture

Presentation: Ontology‐Driven Observability: Building the E2E Knowledge Graph at Netflix Scale

Открыть оригинал ↗ Перевод заголовка: Ортогональная наблюдаемость: построение конечного знаний-графа на масштабе Netflix

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

Вместо изолированных систем мониторинга Netflix объединяет данные из логов, метрик, событий и трейсов в единый MELT-слой, который становится основой для знаний-графа.
Онтология, построенная на стандартах RDF и OWL, формализует типы, свойства и связи между компонентами инфраструктуры, позволяя системе понимать не только что, но и как элементы взаимодействуют.
Через «harvest pipeline» из Slack и других источников автоматически извлекаются сущности и отношения, а LLM-модели расширяют их, выявляя скрытые паттерны и связи.
Граф-база данных QuipuDB хранит все данные в формате Turtle, но при этом для высокой скорости обработки используется только метаданные и «отпечатки» событий, не сохраняя полных данных.
Система включает в себя механизм формальной логики и «человеческого в цикле» для проверки корректности выводов, что позволяет избежать фальшивых корреляций и обеспечить надежность.

Когда пригодится

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

Вопросы для размышления

Какие конкретные критерии или фильтры используются для предотвращения фальшивых корреляций в онтологии, если LLM может генерировать «халлюцинации»?

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

Какова сложность (по времени и ресурсам) выявления и обработки одного инцидента в онтологии, если он включает в себя десятки сообщений и сотни ссылок на метрики?

Javarevisited Newsletter

System Design Interview: How to Design a Payment Processing System? Part 1

Открыть оригинал ↗ Перевод заголовка: Как проектировать систему обработки платежей? Часть 1

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

Важно включить механизм идемпотентности (idempotency key), чтобы предотвратить повторные платежи при сбоях в сети или повторных запросах.
Необходимо четко отделить поток ввода (pay-in) и вывода (pay-out) денег, чтобы понять, что платежи — это не просто передача средств, а процесс с участием банковских счетов и посредников.
Система должна быть спроектирована с учётом распределённых транзакций и возможных несогласованных состояний, включая использование кэширования, таймаутов и механизмов подтверждения.
Критически важно обеспечить согласованность данных между различными валютами и учётными системами без потери производительности.

Когда пригодится

Материал особенно полезен при подготовке к системному интервью в компаниях, работающих с финансовыми сервисами, где важны надёжность, безопасность и соответствие нормам.

Вопросы для размышления

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

В каких условиях идемпотентность может не сработать, и как это может повлиять на финансовые риски в реальных сценариях?

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

Coding / Algorithms

DEV Data Structures

Part 3: Bloom Filters - the Practice

Открыть оригинал ↗ Перевод заголовка: Часть 3: Фильтры Блума — практика

В этой статье реализуется фильтр Блума на JavaScript с полным кодом, где описаны основные операции: добавление и поиск значений. Структура фильтра включает параметры b (размер битового массива) и h (количество хеш-функций), а также массив битов, инициализированный нулями. Для добавления значений используется хеширование на основе SHA-256 с разными сидами, чтобы получить уникальные индексы в битовом массиве, после чего биты устанавливаются в 1. Поиск выполняется путём проверки всех хеш-индексов — если все биты равны 1, значение считается присутствующим. Удаление значений невозможно без риска ложных отрицаний, так как устанавливание нуля в каком-то бите может повлиять на результат поиска других элементов.

Когда пригодится

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

Вопросы для размышления

Какой компромисс между производительностью и точностью возникает при использовании фильтров Блума в условиях высокой плотности данных?

В каких сценариях можно безопасно использовать удаление элементов в фильтре Блума, и как это может быть реализовано без ложных отрицаний?

Как изменится сложность и эффективность хеширования при увеличении размера массива b и при использовании нестандартных распределений ошибок?

LeetCode.ca Solutions

4033 - Valid K-Unique Subarrays I

Открыть оригинал ↗ Перевод заголовка: 4033 - Валидные подмассивы с k уникальными элементами I

Данная задача требует проверки каждого запроса на подмассив, чтобы он содержал ровно k различных чисел и частота каждого из них была чётной. Для эффективного решения при больших размерах массива и количестве запросов используется комбинация хэш-сумм и структур подсчёта уникальных элементов, позволяющая отвечать на запросы за логарифмическое или почти постоянное время. Ключевая идея — использовать префиксные хэш-суммы для проверки чётности частоты элементов за O(1), а отдельную структуру (например, префиксный массив счётчиков) для подсчёта количества уникальных значений в диапазоне.

Для проверки чётности частоты элемента в подмассиве можно использовать префиксную хэш-сумму (например, XOR-хэш), где каждый элемент вносит вклад по модулю 2 — это позволяет определить, чётна ли частота элемента в диапазоне за O(1).
Чтобы убедиться, что в подмассиве ровно k различных элементов, необходимо отслеживать количество уникальных значений в каждом диапазоне, что требует предварительного построения структуры (например, префикс-счётчиков или отдельного массива счётчиков).
Объединение двух проверок (чётность частот и количество уникальных элементов) позволяет ответить на каждый запрос за O(1) или O(log n), что критично при большом количестве запросов (до 10⁵).
Решение не требует полного пересчёта подмассива при каждом запросе — это делает его применимым к задачам с большими входными данными.
Ограничения на диапазон и значения элементов (до 10⁵) не нарушают эффективность, так как хэш-суммы и счётчики могут быть реализованы с использованием массивов фиксированного размера.

Когда пригодится

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

Вопросы для размышления

Как изменится сложность и эффективность решения, если k будет больше, чем половина длины подмассива, и при этом частоты должны быть чётными?

В каких случаях может возникнуть ложный позитив при использовании XOR-хэша для проверки чётности частот, и как это может быть исправлено?

Какова граница между применимостью данного подхода и необходимостью пересчёта подмассива вручную при изменении структуры запросов?