AI

AWS Architecture Blog

How MHK built a HIPAA-eligible agentic AI solution on Amazon Bedrock

Открыть оригинал ↗ Перевод заголовка: Как MHK создал HIPAA-допустимое агентное ИИ-решение на Amazon Bedrock

MHK, компания Hearst Health, столкнулась с задачей автоматизации обработки медицинских документов (клинических записей, претензий, апелляций и др.) при соблюдении строгих требований HIPAA. Традиционные подходы требовали отдельных инфраструктур и проверок для каждого ИИ-модуля, что делало масштабирование невозможным. В ответ MHK разработал агентный оркестратор SmartProminence, который сократил ручную работу на 90%, сократил время развертывания ИИ-функций с 3–6 месяцев до 2 недель и обеспечил единый уровень соответствия HIPAA без пересоздания инфраструктуры для каждого модуля.

  1. Использование Amazon Bedrock для инференса фундаментальных моделей позволяет избежать пересоздания инфраструктуры, при этом MHK сохраняет контроль над логикой и валидацией, включая HIPAA-специфические проверки.
  2. Архитектура на основе контроллера-агента с событийным потоком через Amazon SQS обеспечивает масштабируемость, отказоустойчивость и независимое развертывание компонентов без перезапуска всей системы.
  3. Валидация на уровне приложения (проверка на халлюцинации, соответствие политикам, пороги уверенности) и защита данных через двойное шифрование (S3 + KMS) и разграничение доступа по токенам обеспечивают аудит и безопасность.
  4. Динамическая регистрация агентов через конфигурацию позволяет быстро внедрять новые функции без пересоздания инфраструктуры и сертификации.
  5. Сохранение контекста между выполнениями через S3 и связывание с ID-кейсами позволяет избежать повторной обработки больших документов и ускорить последующие проверки.

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

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

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

  1. Как изменится сложность и надежность архитектуры при увеличении количества одновременных запросов на уровне параллельных агентов, если не использовать Java virtual threads?
  2. В каких сценариях может нарушаться принцип данных-минимизации, если агенты получают больше контекста, чем строго необходимо для выполнения шага?
  3. Какова вероятность возникновения фейлов в системе при сбое валидации на уровне агента, если не предусмотрена резервная проверка на уровне контроллера?

Cloudflare Blog

Cut your AI spend with AI Gateway's Auto Router

Открыть оригинал ↗ Перевод заголовка: Сократите расходы на ИИ с Auto Router от AI Gateway

Cloudflare наблюдает, что компании проходят этапы: сначала экспериментируют с разными инструментами и API, затем фокусируются на ключевых решениях. При этом даже при наличии бюджетов и правил расходов пользователи всё ещё выбирают модели вручную, что приводит к перерасходу — например, использование моделей с высокой стоимостью для простых задач. Auto Router автоматически определяет подходящую модель на основе задачи, не требуя вмешательства пользователя, и снижает расходы на 30% по сравнению с использованием передовых моделей, таких как Sol от OpenAI или Opus от Anthropic.

  1. Auto Router анализирует задачу по категориям (например, кодирование, планирование) и оценивает сложность, неопределённость, риски и зависимость от контекста, чтобы выбрать модель с оптимальным соотношением качества и цены.
  2. Вместо простого сравнения цен на токены, система учитывает прогнозируемую стоимость, включая расходы на чтение и запись кэша, особенно в длинных сессиях.
  3. При переходе между моделями система применяет штраф за перезапись контекста и учитывает, что большинство моделей не могут читать предыдущие "мышления" — это увеличивает стоимость переключения.
  4. Решение строится на двухэтапной архитектуре: сначала классификация, затем сопоставление с данными о производительности моделей, что делает логику выбора прозрачной и легко настраиваемой.
  5. В будущем планируется расширение функционала — включая поддержку новых моделей, нулевое хранение данных и автоматическое выравнивание по нагрузке.

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

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

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

  1. Какой компромисс между качеством и стоимостью может быть критичным при использовании Auto Router в средах с высокой вариабельностью задач — например, при смешанной работе между разработчиками и аналитиками?
  2. В каких условиях (по длине сессии, типу задачи, объёму контекста) переключение модели становится экономически оправданным, и как это может измениться при увеличении масштаба использования?
  3. Какие риски связаны с тем, что новая модель может не читать предыдущие "мышления", и как это может повлиять на надёжность и согласованность результатов в агентных сессиях?

Monetization Gateway beta: charge AI agents for consumption with HTTP 402

Открыть оригинал ↗ Перевод заголовка: Бета-версия ворот монетизации: платить AI-агентам за использование через HTTP 402

Cloudflare запустил бета-версию Monetization Gateway, позволяющую владельцам доменов в режиме реального времени включать плату за доступ к своим ресурсам — сайтам, API, инструментам или данным — прямо в HTTP-запросе. Система использует стандарт HTTP 402 «Payment Required» для прямого встраивания платежа в запрос, без перенаправления на чек-ин или отдельного API, что делает процесс максимально прозрачным и быстрым. Платежи идут через блокчейн с использованием USDC, а система автоматически обрабатывает валидацию, ошибки, аналитику и согласование с протоколом x402. Важно, что платёжная модель подстраивается под потребности агентов: цена может быть фиксированной или переменной, в зависимости от ресурса, и определяться по URL, заголовкам или параметрам запроса.

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

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

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

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

Identify AI model overuse with User Insights

Открыть оригинал ↗ Перевод заголовка: Определение перерасхода AI-моделей с помощью User Insights

Cloudflare представил обновлённую функцию User Insights, которая помогает командам понять, как пользователи и агенты используют AI-модели, и выявить несоответствия между выбранным моделью и реальными задачами. Теперь система не просто показывает количество запросов и модели, а анализирует тип задачи — например, кодирование, исследование или синтез — и оценивает, насколько модель превышает требования задачи. Это позволяет выявить случаи перерасхода ресурсов, где, например, простые задачи обрабатываются мощными моделями с высокой стоимостью и задержкой.

  1. User Insights распознаёт типы задач (кодирование, анализ, резюмирование) и присваивает им категории с уверенностью, что помогает понять контекст использования модели.
  2. Система выявляет «перерасход» — случаи, когда модель значительно превосходит требования задачи, и показывает, какие пользователи или агенты ведут такие запросы.
  3. Появляется визуализация затрат по количеству токенов, количеству ходов диалога и времени, что позволяет оценить эффективность и стоимость выполнения задач.
  4. На основе анализа формируется автоматическая маршрутизация (Auto Router), которая выбирает модель в зависимости от типа задачи, не просто минимизируя стоимость.
  5. Важно понимать, что классификация работает асинхронно и с задержкой в сутки, поэтому данные не отражают реальное время, а показывают тенденции за период.

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

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

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

  1. В каких условиях использование «быстрой» модели может быть неоправданным, даже если задача проста, и как это может повлиять на качество вывода?
  2. Какой компромисс между стоимостью и точностью может быть в случае, когда агенты используют одну и ту же модель на всех этапах, несмотря на разный уровень сложности задач?
  3. При каких масштабах и типах нагрузки Auto Router может начать показывать нестабильные или неадекватные решения по маршрутизации?

The Internet has a second audience

Открыть оригинал ↗ Перевод заголовка: У Интернета появился второй аудиторий

Исторически Интернет обслуживал одну аудиторию — людей, которые читали, покупали и платили за контент. Однако к концу 2024 года доля автоматизированных запросов, инициированных AI-агентами, выросла более чем на 1700%, и к 2026 году более половины трафика на Интернете уже не идёт от людей. Эти агенты — программные инструменты, действующие на стороне людей — не отвечают на рекламу, но выполняют реальные задачи, и их поведение напоминает ритмичные действия людей. Вместо того чтобы блокировать весь трафик, Cloudflare предлагает гибкие настройки: отдельные фильтры для поисковых, агентных и тренировочных ботов, а также инструменты для идентификации и монетизации запросов.

  1. Важно различать типы трафика: агенты не просто копируют контент, они возвращаются при каждом запросе, что делает их поведение привязанным к реальным задачам пользователей.
  2. Монетизация через Pay Per Use и Monetization Gateway позволяет сайтам получать доход от каждого реального использования контента, а не от просмотров или копирования.
  3. Инструменты вроде WebMCP и Markdown for Agents снижают нагрузку на серверы, позволяя агентам эффективно взаимодействовать с сайтами без лишних стилей или сложных интерфейсов.
  4. Идентификация агентов через Web Bot Auth и поддержка x402-протокола обеспечивают доверие и прозрачность, позволяя сайтам отличать настоящих агентов от фальшивых.
  5. Система позволяет настраивать политику по каждому типу трафика (поиск, агенты, обучение), что даёт гибкость в балансе между защитой и доходом.

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

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

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

  1. В каких сценариях использование контента агентом может быть менее ценным, чем для человека, и как это влияет на модель монетизации?
  2. Какова сложность и масштабируемость системы Pay Per Use при работе с тысячами независимых сайтов, если каждый запрос требует отдельной проверки и отчета?
  3. В каких условиях агенты могут привести к ухудшению качества контента (например, из-за чрезмерного запроса на определённые темы), и как это может быть предотвращено без снижения доступности?

Detect and send production issues straight to your agent

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

Cloudflare вводит в бета-версии функцию Issues для Cloudflare Workers, которая автоматически собирает и группирует ошибки, включая повторяющиеся исключения, 5xx-ответы и логи, и отправляет их в настроенный агент для дальнейшей обработки. Система не требует установки SDK или дополнительных инструментов — она встроена в сам runtime Workers, и работает без дополнительной инструментации. При обнаружении проблемы Issues автоматически собирает стек-трейс, логи, трейсы, версию Worker и контекст, включая идентификаторы пользователей и сессий, добавленные через OpenTelemetry API. После этого агент может запускать автоматизированные рабочие процессы — от диагностики до создания pull-запроса с предложенным исправлением.

  1. Какие ограничения есть в том, что Issues не фиксирует ошибки, связанные с пользовательским вводом или внешними API-запросами?
  2. В каких сценариях может сработать "неправильная" автоматизация — например, при слишком частом срабатывании или при отсутствии контекста в логах?
  3. Какова сложность и масштабируемость архитектуры Issues при работе с миллионами запросов и тысячами Workers?

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

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

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

  1. Какие ограничения есть в том, что Issues не фиксирует ошибки, связанные с пользовательским вводом или внешними API-запросами?
  2. В каких сценариях может сработать "неправильная" автоматизация — например, при слишком частом срабатывании или при отсутствии контекста в логах?
  3. Какова сложность и масштабируемость архитектуры Issues при работе с миллионами запросов и тысячами Workers?

Habr AI

Каждый LLM-фреймворк описывает инструмент по-своему

Открыть оригинал ↗ Перевод заголовка: Каждый LLM-фреймворк описывает инструмент по-своему

LLM-фреймворки реализуют инструменты (функции, доступные моделям) через разные обёртки: от tool() в AI SDK до registerTool в MCP и defineTool в Genkit. Эти обёртки не просто упаковывают функции — они привязаны к конкретному фреймворку, что делает перенос инструмента между системами сложным и требующим переписывания кода. Однако сам инструмент может быть описан как объект с фиксированной структурой: имя, описание, схемы входа и выхода, и функцией выполнения — без зависимости от фреймворка. Такой объект можно использовать вне фреймворка, вызывать в скриптах, документировать или экспортировать в библиотеку.

  1. Инструмент как объект с явно определённой структурой (StandardToolV0) позволяет использовать его вне фреймворка — в тестах, документации или CLI, не требуя установки дополнительных пакетов.
  2. Стандартные схемы (Standard Schema и Standard JSON Schema) обеспечивают универсальность валидации и форматирования, работая с Zod, Valibot, ArkType и другими библиотеками без адаптеров.
  3. Разные фреймворки ведут себя по-разному: валидация, поля и порядок аргументов отличаются, что делает объекты не взаимозаменяемыми, даже если они по сути одинаковы.
  4. Для интеграции с моделями (OpenAI, Anthropic, Gemini, MCP) нужно лишь адаптировать поля и диалект JSON Schema — адаптер пишется один раз и работает для всех провайдеров.
  5. Несмотря на то что стандарты не включают рантайм-код и имеют низкую вовлечённость в экосистему, они демонстрируют потенциал для унификации инструментов в LLM-экосистеме.

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

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

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

  1. Какой компромисс между универсальностью и производительностью в стандартных схемах, если они не включают рантайм-код, но требуют валидации на уровне модели?
  2. При каких условиях стандартный объект инструмента может быть действительно взаимозаменяемым между фреймворками, если даже в V0 он не поддерживается всеми?
  3. Какова сложность реализации execute с валидацией входных данных в условиях, когда модель может передавать нестандартные аргументы, но инструмент должен проверять их по схеме?

Как мы 3+ года пытались подружить AI с разработкой: от провалов к Spec-Driven

Открыть оригинал ↗ Перевод заголовка: Как мы 3+ года пытались подружить AI с разработкой: от провалов к Spec-Driven

В течение трёх лет компания Синимекс экспериментировала с применением LLM в разработке — от генерации кода до поддержки продаж. Первые попытки, такие как анализ технических заданий и генерация тестов, показали хорошие метрики, но не принесли практической ценности для пользователей, поскольку ошибки требовали полной ручной проверки. Позже было понято, что успех не измеряется только качеством ответа модели, а стоимостью её проверки человеком. В 2024–2025 годах появился сдвиг: ценность AI перестала зависеть от генерации кода и стала определяться точностью постановки задачи, наличием контекста и архитектурных рамок. В 2026 году формализовались принципы Spec-Driven подхода — спецификация становится единым контекстом, в котором агент работает внутри структурированных артефактов, а код — последним шагом, а не отправной точкой.

  • Хорошие метрики модели не гарантируют ценность для бизнеса — ключевым критерием становится стоимость ручной проверки результатов.
  • Успешный пилот не означает масштабируемость: внедрение в другие подразделения требует глубокого понимания бизнес-процессов и контекста.
  • Качество взаимодействия с AI определяется не самой моделью, а точностью промптов, описанием ролей, правил и форматов оценки.
  • В Spec-Driven подходе спецификация (включая цели, ограничения, NFR, интерфейсы) становится артефактом проекта, а не одноразовым промптом.
  • Генерация кода перестаёт быть первым шагом — она становится последним этапом после формализации требований и архитектуры.

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

Материал полезен для команд, которые внедряют AI в разработку, особенно при построении систем с высокой степенью риска и сложности, где важна согласованность между разработчиками, аналитиками и агентами. Особенно актуален в средах с нестандартными технологиями (например, 1С), где контекст и ограничения критичны, и при работе с коммерческими данными, где безопасность и прозрачность становятся приоритетами.

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

  1. Какие конкретные бизнес-риски могут быть скрыты в неформализованных требованиях, и как их можно выявить на ранних этапах проекта при использовании AI?
  2. В каких условиях (по масштабу, сложности, типу проекта) Spec-Driven подход может стать неэффективным, и как это можно предотвратить на практике?
  3. Какова сложность и время реализации процесса формализации спецификации, если она должна быть включена в каждый проект, а не только в кейсы с высокой ценностью?

Зачем нейросети «обвязка»: как превратить LLM в рабочий AI-сервис

Открыть оригинал ↗ Перевод заголовка: Зачем нейросети «обвязка»: как превратить LLM в рабочий AI-сервис

Несмотря на то, что крупные языковые модели (LLM) могут генерировать тексты на входе и выходе, они не являются готовыми к использованию в бизнесе. Для превращения LLM в надёжный, безопасный и управляемый сервис необходима «обвязка» — комплекс из интерфейсов, интеграций, контроля доступа, валидации и логирования. Эта обвязка решает вопросы, которые модель не может сама: кто может пользоваться сервисом, как передавать корпоративные данные, как проверять действия, как избежать ошибок и несанкционированных вмешательств. Модель — лишь ядро, а обвязка делает сервис пригодным к реальному применению.

  1. Обвязка включает в себя API-интерфейс, который позволяет пользователям взаимодействовать с моделью через веб-интерфейс, мессенджеры или другие приложения.
  2. Для работы с внутренними данными используется RAG (Retrieval-Augmented Generation), который находит и встраивает актуальные документы в контекст запроса.
  3. Сервис должен выполнять действия через инструменты (tool calling), где LLM формирует запрос, а код — его исполняет, обеспечивая безопасность и надёжность.
  4. Важны лимиты по токенам, распределение нагрузки между моделями и отказоустойчивость — чтобы избежать переплаты и зацикливания.
  5. Критически важно валидировать результаты перед выполнением действий и строго фильтровать входные данные, чтобы предотвратить промпт-инъекции и ошибки в логике.

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

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

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

  1. Какой компромисс между скоростью и безопасностью возникает при использовании RAG с неструктурированными корпоративными документами, и как это влияет на качество ответов?
  2. В каких сценариях может привести к сбоям или ошибкам распределение запросов между моделями (например, простые — дешёвая, сложные — мощная), и как это может быть настроено без потери точности?
  3. Какие риски связаны с тем, что LLM получает входные данные из внешних систем (например, тикетов или API), и как это может быть предотвращено без потери функциональности?

Сервис SOFROS AI/ML на практике: реальные кейсы и экономический эффект от нормализации данных

Открыть оригинал ↗ Перевод заголовка: Сервис SOFROS AI/ML на практике: реальные кейсы и экономический эффект от нормализации данных

Сервис SOFROS AI/ML помогает компаниям решать критические проблемы с «грязными» справочниками — дублированием, неполными характеристиками и разнородными описаниями, что приводит к финансовым потерям. В статье представлены реальные кейсы, где внедрение AI сократило дубли до 2%, сократило время классификации с минут до секунд и снизило ошибки в закупках в 6 раз, что позволило оценить экономический эффект в миллионах рублей в год.

  1. Автоматизация нормализации данных (классификация, дедупликация, извлечение атрибутов) сокращает время на обработку новой позиции с 5–10 минут до 2–3 секунд — ускорение в 100+ раз.
  2. Устранение дублей и ошибок в спецификациях позволяет сократить бюджет закупок на 15% и избежать потерь на браке, особенно в отраслях с высокой точностью требований (машиностроение, нефтегаз).
  3. Внедрение единых шаблонов описания и семантического поиска обеспечивает согласованность справочников между филиалами и позволяет проводить аналитику по всей сети.
  4. Экономический эффект оценивается по прямым потерям — повторные закупки, простои, ручной труд и избыточные склады — с учётом средних цен и затрат на экспертизу.
  5. Внедрение занимает от 2 до 8 недель, при этом успех зависит от качества исходных данных и сопротивления пользователей — требуется постепенный подход и обучение.

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

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

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

  1. Какова граница применимости модели SOFROS AI/ML для номенклатуры с высокой степенью вариативности (например, в машиностроении), где даже небольшие изменения в описании (одна буква) могут означать разные изделия?
  2. В каких условиях (по масштабу, качеству данных, отрасли) модель может показать ROI в течение 3 месяцев, а не более, и как это влияет на выбор между внедрением AI и ручной нормализацией?
  3. Какие риски связаны с использованием локальных LLM и PII-маскировки в условиях строгих требований к безопасности (например, 152-ФЗ), и как это может повлиять на точность распознавания?

Java / Spring

Foojay

Lathe: A Java Language Server That Works Straight From Your Maven Build

Открыть оригинал ↗ Перевод заголовка: Lathe: Java-сервер языка, работающий напрямую из вашего Maven-постройки

Проблема многих IDE и языковых серверов в Java — не в интеллекте кода, а в неправильной интерпретации структуры проекта. При сложных настройках модулей и обработки аннотаций (JPMS, annotation processors) IDE часто не воссоздают поведение компиляции, что приводит к разрыву между работой в билде и в редакторе. Lathe решает эту проблему, захватывая реальную конфигурацию проекта прямо из Maven-билда, а не гадая на основе файлов. В результате в редакторе отображается точная структура, как в самом билде, и все функции — от автозаполнения до отладки — работают без дополнительных сборок.

  1. Lathe захватывает класспат, модульный путь, настройки аннотационной обработки и тестов прямо из Maven-билда, что делает его точным отражением реальной среды выполнения.
  2. После запуска билда сервер обновляет конфигурацию и повторяет выполнение кода (запуск, тесты, отладка) без повторной сборки — всё воссоздаётся из ранее захваченных данных.
  3. Поддержка ведётся в редакторах, таких как Neovim (через встроенный клиент) и Emacs (через Eglot), с планируемым подключением к VS Code.
  4. Все функции — от автодополнения до диагностики и рефакторинга — отражают поведение компилятора, включая Javadoc, типы, реализации и ошибки.
  5. Настройка требует только одного запуска билда с флагом --capture.only, после чего всё автоматически синхронизируется с изменениями в проекте.

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

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

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

  1. Какова сложность и масштабируемость решения Lathe при переходе на крупные проекты с сотнями модулей и динамическими зависимостями?
  2. В каких сценариях может сломаться синхронизация между билдом и редактором, если в проекте внедрены изменения в структуре модулей или в аннотационных обработчиках без пересборки?
  3. Какие риски связаны с использовани и необновлённой версии Lathe, если в проекте включены новые версии JDK или Maven, не поддерживаемые текущей версией расширения?

Habr Java

@CacheEvict уходит раньше коммита, и кэш врёт до перезапуска

Открыть оригинал ↗ Перевод заголовка: @CacheEvict уходит раньше коммита, и кэш врёт до перезапуска

Код с аннотациями @Transactional и @CacheEvict может выглядеть корректным, но при этом кэш продолжает возвращать устаревшие значения до коммита транзакции — из-за того, что кэширование и транзакции обрабатываются разными перехватчиками, и между ними нет согласования. Важно понимать, что @CacheEvict с beforeInvocation=true вызывает удаление ключа до начала метода, что делает его чувствительным к откату транзакции, и в этом случае запись в кэш не откладывается, а происходит в момент, когда транзакция ещё не закоммичена. В результате читатель может получить старое значение, даже если оно уже было отменено. Устранить это поведение можно только через вручную управляемые события после коммита, например с помощью @TransactionalEventListener. Для кэшей, не поддерживающих transaction-aware (например, Caffeine), требуется обёртка, а для Redis — просто включение transactionAware() в конфигурацию. Однако даже при включении transaction-aware кэш не откладывает операции evictIfPresent, что делает его неприемлемым для использования в транзакционных сценариях с риском ошибок.

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

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

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

  1. Почему в случае с @CacheEvict(beforeInvocation = true) и откатом транзакции кэш не отображает актуальное значение, и как это влияет на надёжность данных в production-сценариях при высокой нагрузке?
  2. Какой компромисс между безопасностью кэша и производительностью возникает при использовании transaction-aware кэша, и в каких случаях он становится неприемлемым?
  3. В каких условиях @CacheEvict с beforeInvocation=true может быть безопасно применён без риска введения "грязного" кэша, и как это можно проверить на практике без тестирования в production?

Java67

I've Read 20+ Core Java Books - Here Are My BEST 5 Recommendations for Beginners in 2026

Открыть оригинал ↗ Перевод заголовка: У меня есть 20+ книг по языку Java — вот мои 5 лучших рекомендаций для новичков в 2026 году

Автор анализирует 20+ книг по языку Java и выбирает пять наиболее эффективных для начинающих, основываясь на читаемости, примерах и содержании. Рекомендации подходят как для полных новичков, так и для тех, кто имеет 1–2 года опыта, и помогают заполнить пробелы в знаниях по фундаментам языка и его API. Важно сочетать чтение книги с онлайн-курсом для лучшего усвоения материала.

  1. Head First Java 3rd Edition — обновлённый вариант, охватывает Java 17, идеален для понимания структуры и логики программирования, хотя не подходит для глубокого изучения новых фич.
  2. Learn Java the Easy Way — акцент на быстрые результаты, включает современные элементы (lambda, streams), интерактивную среду JShell и практические проекты, подходит для тех, кто хочет быстро начать кодить.
  3. Java How to Program, Early Objects (11th ed.) — всестороннее руководство, включает как базовые, так и продвинутые темы (JDBC, Swing), с подробными примерами и объяснениями ошибок.
  4. Core Java, Volume 1 & 2 (12th ed.) — отличный выбор для перехода с C/C++, содержит сравнения с C++, подробные пояснения и обновлённые фичи Java 8–11.
  5. Java: A Beginner's Guide (13th ed.) — идеален для полных новичков, начинает с нуля, с простыми примерами и теорией, поддерживает актуальность до Java SE 11.

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

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

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

  1. В каких случаях Head First Java 3rd Edition может быть неэффективным по сравнению с другими книгами, даже если она обновлена до Java 17?
  2. Какой из двух подходов — глубокое изучение через книгу Core Java или быстрое освоение через Learn Java the Easy Way — лучше подходит для человека, который планирует работать в среде с высокой скоростью разработки и минимальными требованиями к теории?
  3. Какие риски связаны с использованием Java: A Beginner's Guide в качестве основы, если после этого разработчик не будет изучать современные фичи Java 17+ и не будет работать с современными API (например, Java 21, Record, Sealed Classes)?

Vlad Mihalcea

Thirteen years of blogging

Открыть оригинал ↗ Перевод заголовка: Тринадцать лет блогging

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

  1. Практический тезис: Несмотря на падение трафика, блогging остаётся эффективным способом развития навыков письма и построения личного бренда, особенно в условиях роста ИИ-генерации текста.
  2. Практический тезис: Автор использует блог для систематизации знаний, в том числе в области Spring, Hibernate и производительности, что делает его ценным ресурсом для разработчиков.
  3. Практический тезис: В условиях роста автоматизированных инструментов, аутентичность и человеческий подход к письму становятся редкими и ценными качествами, которые могут быть ключевыми в профессиональной среде.
  4. Практический тезис: Блог помогает автору поддерживать активность в социальных медиа, что позволяет сохранять видимость и вовлечённость даже при снижении веб-трафика.
  5. Практический тезис: Инструменты вроде Hypersistence Optimizer, разработанные автором, показывают, как технические решения могут быть адаптированы к реальным задачам разработки и поддержки.

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

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

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

  1. В каких сценариях ручное письмо может быть более эффективным, чем ИИ-генерация, несмотря на скорость и масштабность автоматизированных инструментов?
  2. Какие скрытые риски или компромиссы могут возникнуть при полной автоматизации письма в технических блогах, особенно при работе с экспертными темами?
  3. Какова сложность и масштабируемость системы, которая может автоматически выявлять производительность в JPA/Hibernate, и как это может измениться при переходе на новые версии Hibernate (например, 7.3)?

System Design

AWS Architecture Blog

Running multi-day AZ evacuation drills with ARC Zonal Shift

Открыть оригинал ↗ Перевод заголовка: Проведение многодневных тренировок по эвакуации зон с использованием ARC Zonal Shift

Многодневные тренировки по эвакуации зоны с помощью ARC Zonal Shift позволяют проверить, насколько приложение может выдерживать длительное снижение нагрузки на одну из зон. В отличие от коротких тестов переключения, которые фокусируются на быстром восстановлении, такие тренировки выявляют скрытые проблемы, возникающие при длительной работе на N-1 конфигурации — от настройки авто-расширения до поведения клиентских соединений и операционных процессов.

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

  1. Для успешной работы на N-1 конфигурации необходимо заранее настроить авто-расширение и предварительно увеличить вычислительную мощность, чтобы избежать реактивного масштабирования.
  2. Тренировка должна включать проверку всех слоёв — от веб-слоя до базы данных — с использованием метрик CloudWatch, чтобы получить полную картину нагрузки и стабильности.
  3. Восстановление после эвакуации требует строгого порядка: сначала восстановить внутреннюю топологию (EKS), затем — внешнюю (ALB), и постепенно снизить масштабирование, чтобы избежать перегрузки.

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

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

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

  1. Какие риски могут возникнуть при использовании многодневной эвакуации, если Auto Scaling в здоровых зонах не контролируется и создаёт неравномерную нагрузку на оставшиеся зоны?
  2. В каких сценариях использование Istio с локальными правилами маршрутизации становится обязательным, а не рекомендованным для обеспечения согласованности поведения клиентских соединений?
  3. Какой минимальный порог нагрузки должен быть задан в метриках CloudWatch, чтобы считать эвакуацию успешной с точки зрения устойчивости и отсутствия сбоев?

DEV System Design

The Database Is a Detail. The Data Is Not.

Открыть оригинал ↗ Перевод заголовка: База данных — мелочь. Данные — не мелочь.

В статье подчёркивается, что хотя архитектура (по принципу Clean Architecture) правильно выносит базу данных на периферию, многие команды забывают про то, что данные — это не просто хранение состояния, а ключ к пониманию бизнес-процессов. Вместо этого они оставляют в стороне анализ, где происходят принятие решений, оценка эффективности и регулирование. Основная ошибка — смешивать технические детали (например, выбор СУБД или очередей) с бизнес-требованиями к данным, что приводит к тому, что критически важная информация о событиях (например, причина отмены заказа) появляется поздно и неструктурированно.

  1. Данные, которые необходимы бизнесу (например, причина отмены заказа), должны быть явно определены как бизнес-факты в рамках домена, а не выведены из таблицы по состоянию на момент времени.
  2. Схемы событий должны рассматриваться как публичные интерфейсы с версионированием и соблюдением согласованности, как и любые другие API.
  3. В архитектуре нужно включать в центральные элементы не технологии, а данные-требования — то есть, что именно должно быть зафиксировано и каким образом оно будет использоваться.
  4. Использование портов (например, интерфейса для публикации событий) позволяет отделить бизнес-логику от реализации (например, Kafka или outbox), обеспечивая гибкость без ущерба для целостности данных.
  5. Критически важные вопросы — о том, как проверять эффективность функции, как хранить историю и что делать при ошибке — должны задаваться на этапе проектирования, а не в ответ на появление несоответствий в дашбордах.

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

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

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

  1. Какие критерии можно использовать, чтобы определить, является ли определённое событие (например, "отмена заказа") бизнес-фактом, а не вспомогательным полем для отчётов?
  2. В каких условиях введение версионированных схем событий может привести к увеличению сложности и задержкам в разработке, несмотря на их пользу?
  3. Как можно обеспечить согласованность между доменными событиями и аналитическими моделями, если эти требования могут меняться в зависимости от бизнес-сценариев?

3 Redis Design Failures You Should Avoid Before They Become Production Incidents

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

Простая схема кэширования — «проверить Redis, затем базу» — быстро превращается в сложную системную задачу при реальных нагрузках. Основные риски включают несоответствие данных (стale data), нестабильность при истечении срока действия (TTL), и массовые запросы при исчезновении кэша (cache stampede). Каждый этап улучшения кэширования вводит новые сложности: от согласованности данных до распределения нагрузки и отказоустойчивости.

  1. Кэш может содержать устаревшие данные — при изменении в базе, кэш не обновляется автоматически, что создаёт разрыв между источниками данных.
  2. TTL упрощает обновление, но не решает проблему — слишком длинный срок ведёт к устареванию, слишком короткий — к росту нагрузки на базу.
  3. Прямое уничтожение кэша при изменении в базе требует надёжной синхронизации, и при сбоях может привести к неправильным данным.
  4. При одновременном исчезновении кэша тысячи запросов могут перекинуться на базу — это «cache stampede» (или «thundering herd»).
  5. Решения вроде single-flight, TTL jitter и репликация критичных ключей требуют глубокого понимания нагрузки и отказоустойчивости.

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

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

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

  1. Какие данные могут быть устаревшими без потери функциональности, и как это влияет на выбор TTL и стратегии обновления кэша?
  2. В каких сценариях использование TTL jitter может быть неэффективным, и как это влияет на распределение нагрузки в условиях неравномерного доступа к данным?
  3. При каких условиях репликация кэша не решает проблему горячих ключей, и как это может повлиять на отказоустойчивость системы при сбое одного из узлов?

Designing a Pharmaceutical AIoT Pipeline: MES, Sensors, Edge Computing, and AI

Открыть оригинал ↗ Перевод заголовка: Проектирование трубопровода AIoT в фармацевтической промышленности: MES, датчики, edge-вычисления и ИИ

Фармацевтическое производство — это распределённая система, маскирующаяся под физический процесс. Ключевая задача не в обучении модели, а в создании надёжной цепочки от физического события до принятия операционного решения. Архитектура включает в себя физические устройства → слой edge → обработку событий → интеграцию → системы MES/ERP/LIMS/QMS → аналитику и ИИ → рабочие процессы.

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

  1. Система должна начинаться с определения значимых событий (например, запуск оборудования, изменение температуры), схема которых должна включать идентичность, время и контекст.
  2. Идентификация физических объектов (через RFID, BLE и т.п.) критична — без неё данные теряют связь с процессами и батчами, что приводит к фрагментации аналитики.
  3. Данные должны нормализоваться до единого формата до поступления в ИИ, чтобы избежать ошибок идентификации (например, EQUIP-102 vs 102 vs COMPRESSOR_102).

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

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

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

  1. Какие риски возникают при отсутствии версии сопоставления датчика с батчем в случае задержки передачи событий от edge-гейтве?
  2. В каких условиях нормализация данных может привести к потере важной информации о физическом состоянии оборудования?
  3. Какова сложность реализации механизма верификации (loop) в условиях нестабильной связи между датчиками и центральной системой?

The AI Infrastructure Wall: Why Prompt Engineering Won't Scale Your Workflows

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

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

Практические тезисы:

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

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

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

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

  1. Какие конкретные риски могут возникнуть при использовании нестабильных JSON-схем в агентной системе, если они не проверяются на уровне входа и выхода?
  2. В каких условиях модульная архитектура может стать неэффективной по сравнению с гибким промптом, и как это может повлиять на время разработки и внедрения?
  3. Какова сложность по времени и ресурсам реализации перехода от одноразовых промптов к системе с модульными агентами и JSON-контрактами?

How I Build Software From Scratch: From a Rough Idea to Architecture and Code

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

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

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

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

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

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

  1. В чём заключается компромисс между глубиной анализа взаимодействия с физическими устройствами и скоростью разработки, если в проекте нет времени на детальное моделирование?
  2. Какие риски связаны с использованием ИИ как партнёра в кодировании, если в системе есть критичные бизнес-логики или регуляторные требования, которые не могут быть автоматически оценены?
  3. При каких условиях архитектура на основе слоёв становится неэффективной, если система должна масштабироваться по количеству пользователей и типам устройств?

Hide or Reduce: Why Modularity Abstractions Break Distributed Systems

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

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

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

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

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

  1. В каких сценариях модульная абстракция может быть безопасной, несмотря на риски, связанные с гонками и неопределёнными интерлейвингами?
  2. Как можно оценить сложность и масштабируемость моделирования абстракций в условиях растущего числа сервисов и узлов в распределённой архитектуре?
  3. При каких условиях модульная энкапсуляция может быть предпочтительнее моделирования, особенно в быстрых итерационных средах разработки?

AIoT Architecture: From Physical Signals to Intelligent Actions

Открыть оригинал ↗ Перевод заголовка: Архитектура AIoT: от физических сигналов до умных действий

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

  1. Важно не количество датчиков, а то, какую информацию нужно собирать, чтобы понять реальную ситуацию.
  2. Связь между устройствами должна учитывать задержки, надёжность и среду, а не быть универсальной.
  3. Обработка данных должна быть адаптирована под задачу — на уровне устройства или в облаке — и включать фильтрацию, нормализацию и валидацию.
  4. ИИ не работает в вакууме: его выводы требуют контекста, и без интеграции с приложениями и процессами они не приносят ценности.
  5. Действия после анализа должны быть четко определены и соответствовать бизнес-требованиям, включая возможность вмешательства человека.

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

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

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

  1. Какие критерии качества и надёжности данных должны быть учтены при выборе датчиков, чтобы избежать "шума" и неэффективной обработки?
  2. В каких условиях (по задержке, объёму данных, типу задачи) предпочтительнее обрабатывать данные на уровне устройства, а в каких — в облаке?
  3. Какие риски связаны с полной автоматизацией цепочки "обнаружение → анализ → действие", и как это может повлиять на безопасность или надёжность системы?

DesignGurus

Beyond REST: 20 API Design Patterns for System Design Interviews

Открыть оригинал ↗ Перевод заголовка: За пределами REST: 20 шаблонов проектирования API для системных интервью

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

  1. REST-моделирование обеспечивает предсказуемую структуру через ресурсы и HTTP-методы, но плохо справляется с действиями, требующими нестандартных вводов.
  2. Версионирование позволяет эволюционировать API без разрыва совместимости, но вводит несоответствие REST-принципам и сложности в тестировании и логировании.
  3. Пагинация с использованием курсора обеспечивает стабильность и эффективность при работе с динамическими коллекциями, но не позволяет прыгать к произвольным страницам.
  4. Единый формат ошибок (RFC 7807) делает их понятными и структурированными для клиентов, обеспечивая корреляцию с логами и автоматическую обработку.
  5. Идемпотентность с ключами позволяет безопасно пересылать запросы при сбоях, предотвращая дублирование операций, но требует хранения состояния и корректного управления сроками действия.

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

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

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

  1. В каких сценариях пагинация с курсором становится менее эффективной, чем пагинация с отсчётом, и как это влияет на производительность при высокой скорости вставок?
  2. Какой из вариантов версионирования (URL, заголовок, параметр запроса) наиболее устойчив к изменениям в логах и тестировании в production-среде, и как это влияет на масштабируемость системы?
  3. При каких условиях идемпотентность может привести к непредсказуемым результатам, если не учитывать сроки действия ключей и логику хранения состояния?

InfoQ Architecture

Cursor Uses S3 WAL to Scale Git Storage to More than 300 Pushes per Second

Открыть оригинал ↗ Перевод заголовка: Cursor использует WAL в S3 для масштабирования хранения Git до более чем 300 пушей в секунду

Cursor внедрил архитектуру Continuity, в которой источник правды — это не синхронизированные копии в локальных репозиториях, а пишущийся в S3 write-ahead log (WAL). Вместо координации реплик, система использует S3 как неизменяемый источник состояния, позволяя локальным NVMe-репозиториям работать как кэши, а не как авторитетные копии. Пуш-операции подтверждаются только после сохранения данных в S3, что обеспечивает устойчивость перед подтверждением, а батч-обработка снижает влияние задержек при записи в S3. Система поддерживает линейное масштабирование чтений при 100 репликах и более 300 пушей в секунду при использовании S3 Express One Zone, при этом компакция Git выполняется только на основном узле, а реплики получают пакеты из S3, что сокращает нагрузку на CPU.

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

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

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

  1. Как изменяется нагрузка на S3 при высоких скоростях пушей, и какова вероятность перегрузки при использовании S3 Express One Zone без оптимизации батч-обработки?
  2. В каких сценариях может привести к потере данных или несогласованности отсутствие синхронизации реплик, если WAL в S3 не защищён от коррупции или потерь?
  3. Какова сложность и масштабируемость архитектуры при переходе от монорепозиториев к децентрализованным системам с тысячами независимых репозиториев?

Coding / Algorithms

DEV Data Structures

Bloom Filters

Открыть оригинал ↗ Перевод заголовка: Bloom Filters

Bloom filters — это семейство вероятностных структур данных, которые позволяют быстро определять, содержится ли элемент в множестве, с нулевыми ложными отрицаниями, ограниченной вероятностью ложных положительных результатов и минимальным использованием памяти — около 14 бит на элемент при уровне ложного положительного результата 0,1%. Они особенно полезны при работе с большими объёмами уникальных данных, где скорость проверки и экономия памяти критичны.

Ключевые преимущества включают низкое потребление памяти (независимо от длины элементов), константное время поиска и отсутствие ложных отрицаний. Вместе с тем, Bloom filters не поддерживают удаление элементов, что делает их неадаптивными к динамическим изменениям данных. Существуют усовершенствованные варианты, такие как counting Bloom filters (с подсчётами) и scalable Bloom filters (масштабируемые), позволяющие решать проблемы удаления и роста объёма данных.

  1. Как влияет выбор начального размера массива на количество слоёв в scalable Bloom filter и общую производительность запросов?
  2. В каких сценариях использование counting Bloom filters может привести к значительному росту ложных положительных результатов, несмотря на наличие подсчётов?
  3. При каких условиях (по размеру входного набора, плотности данных или распределению хешей) вероятность ложного положительного результата в Bloom filter может превысить 1% без пересчёта параметров?

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

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

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

  1. Как влияет выбор начального размера массива на количество слоёв в scalable Bloom filter и общую производительность запросов?
  2. В каких сценариях использование counting Bloom filters может привести к значительному росту ложных положительных результатов, несмотря на наличие подсчётов?
  3. При каких условиях (по размеру входного набора, плотности данных или распределению хешей) вероятность ложного положительного результата в Bloom filter может превысить 1% без пересчёта параметров?

DEV LeetCode

I Collected 2026's Google Interview Reports. Here's What's Actually Getting Asked.

Открыть оригинал ↗ Перевод заголовка: Я собрал отчёты о собеседованиях в Google 2026 года. Вот что на самом деле задают.

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

  1. Графы — главная тема. Задачи на подсчёт островов (как в 200, 695) выступают в роли вступления, но реальный тест — в динамическом развитии графа (например, появляются новые земли). Также важны задачи с зависимостями движения (состояние — не только координаты) и сортировка по парным сравнениям (это топологическая сортировка).

  2. Шаблон DP → бинарный поиск. Задача "распределение краски" (410) показывает, как DP (O(n²k)) может быть оптимизирован до бинарного поиска с проверкой. Это не трюк — это путь, который должен быть освоен как метод.

  3. Трие и хэш-мапы вместе. Задачи, где трие используется с хэш-мапами (например, 208, 212, 421), показывают, что нужно тренироваться именно в комбинации, а не по отдельности.

  4. Унион-файнд — проверяется на глубину. Не просто использование, а понимание путь-сжатия, union-by-rank и аргументации корректности.

  5. Потоки и кучи. Задачи на среднее значение и топ-K в потоках (346, 295, 703, 215) часто встречаются в репортажах.

Самые надёжные задачи (подтверждены в отчётах): 200, 416, 174, 410, 2188, 128, 346, 315.

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

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

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

  1. Почему в задачах с графами динамические изменения (например, появление островов) важнее, чем статические, и как это влияет на выбор алгоритма?
  2. В каких условиях DP → бинарный поиск может не сработать, и как это может повлиять на оценку кандидата?
  3. Какой из трёх подходов — трие + хэш-мапа, хэш-мапа + бинарный поиск, или граф с состоянием — наиболее устойчив к ошибкам в production-сценариях?

LeetCode.ca Solutions

4024 - Nearest Available Drone

Открыть оригинал ↗ Перевод заголовка: 4024 - Ближайший доступный дрон

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

  • Вычисляется Manhattan-расстояние между каждой точкой дрона и целью по формуле |x₁ - x₂| + |y₁ - y₂|.
  • Проверяется, не превышает ли это расстояние дальности дрона (d ≤ range).
  • При достижимости дрона и меньшем расстоянии по сравнению с текущим минимумом обновляются индекс и значение расстояния.
  • При равенстве расстояний индекс не обновляется, что гарантирует выбор минимального индекса.
  • Если ни один дрон не может достичь цели, возвращается -1.

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

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

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

  1. Как изменится ответ, если вместо Manhattan-расстояния использовать Евклидово расстояние, и как это повлияет на сложность алгоритма?
  2. При каких условиях может возникнуть failure mode, при котором дрон с минимальным индексом не будет выбран, несмотря на меньшее расстояние?
  3. Как изменится поведение алгоритма при наличии дронов с одинаковой дальностью, но разным расстоянием до цели — и как это влияет на выбор индекса при равенстве расстояний?