AI

Habr AI

Jev: как устроен его API решений и что на нём уже строят

Открыть оригинал ↗ Перевод заголовка: Jev: как устроен его API решений и что на нём уже строят

Jev — это не просто LLM, который генерирует текст, а специализированный API, который принимает состояние приложения и типизированные вопросы, возвращая не текст, а структурированные ответы с вероятностями. Вместо генерации последовательности токенов, Jev работает по контракту state + questions → answers + probabilities, где каждый вопрос имеет строго определённый тип (Noul, Choice, Score) и не зависит от других, что позволяет использовать параллельное выполнение запросов (speculative fan-out) и сокращать задержку. Ключевое преимущество — отсутствие галлюцинаций: модель не может вернуть несуществующий ответ, но не гарантирует правильность решения, особенно при низких значениях confidence. Важно понимать, что Jev не заменяет код, а лишь выбирает из заранее определённого набора действий, оставляя проверку и исполнение в руках приложения.

  1. Jev использует типизированные вопросы (Noul, Choice, Score), что позволяет валидировать ответы на уровне синтаксиса и избегать галлюцинаций, но не обеспечивает правильность содержания.
  2. Система поддерживает параллельное выполнение запросов (speculative fan-out), что позволяет сократить задержку, но требует в коде логики выбора ветвей и фильтрации неиспользуемых ответов.
  3. Важно понимать, что Jev не решает задачи в целом — он выбирает из предопределённого списка действий, а проверка и исполнение остаются в коде, что делает его применимым только в узких, структурированных сценариях.
  4. Контракт Jev требует точного описания допустимых ответов и действий, и при отсутствии их в списке модель может вернуть валидный, но неверный ответ.
  5. Практическая ценность Jev максимальна в задачах с предопределёнными ответами (например, классификация, выбор действия), где ошибки можно быстро обнаружить и исправить.

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

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

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

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

AI-Disrupt PDLC на практике: где ИИ реально ускоряет, а где создаёт иллюзию продуктивности (опыт на личных проектах)

Открыть оригинал ↗ Перевод заголовка: AI-Disrupt PDLC на практике: где ИИ реально ускоряет, а где создаёт иллюзию продуктивности (опыт на личных проектах)

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

  1. ИИ эффективен в подготовке спецификаций, декомпозиции и рисков, но требует ручного ревью для выявления противоречий и пропущенных сценариев.
  2. На типовых задачах (CRUD, интеграции) ускорение достигает 2,5–4 раз, но на архитектурных решениях — лишь 1,3–1,8 раз, а иногда даже замедляет работу.
  3. Код от ИИ часто содержит ошибки: несуществующие методы, уязвимости, hard-coded секреты и пропущенные проверки, особенно в безопасностных критических участках.
  4. Безопасность остаётся главным bottleneck — даже в pet-проектах агенты предлагают небезопасные решения, требуя введения отдельного security-ревью и проверки на этапе спецификации.
  5. Ключевой навык — не получение кода, а точная постановка задачи и строгая проверка результата, что делает разработчика оркестратором агентов и владельцем качества.

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

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

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

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

Completion не доказывает качество результата AI-агента

Открыть оригинал ↗ Перевод заголовка: Completion не доказывает качество результата AI-агента

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

  1. Важно ввести отдельный «completion gate» перед проверкой содержания — он должен подтвердить наличие и целостность артефактов, а не оценивать их качество.
  2. Проверки должны идти последовательно: от завершения запроса до проверки ссылок на реальные, непустые файлы и отсутствия заглушек.
  3. Тесты должны быть привязаны к исходному источнику и сценарию, чтобы избежать проверки устаревших или неправильных версий.
  4. Наличие текстового пересказа не заменяет проверку исходного артефакта — необходимо наблюдать за реальным состоянием интерфейса или видео.
  5. Окончательное принятие результата должно быть ответственностью человека, а не автоматической системой, чтобы избежать ошибок в оценке рисков и согласованности.

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

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

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

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

InfoQ Architecture

Presentation: Context Engineering at LinkedIn: How We Built an Organizational Context Layer for AI Agents with MCP

Открыть оригинал ↗ Перевод заголовка: Контекстная инженерия в LinkedIn: как мы создали слой организационного контекста для ИИ-агентов с помощью MCP

LinkedIn столкнулся с проблемой неспособности ИИ-агентов эффективно работать в крупных, сложных кодовых базах из-за отсутствия глубокого понимания внутреннего контекста системы. Для решения этой задачи была разработана система «Контекстуальных агент-буклетов» (playbooks), построенных на протоколе Model Context Protocol (MCP), которая обеспечивает агентам доступ к инструментам и процедурным знаниям, необходимым для выполнения задач. В результате удалось достичь роста производительности на 20% без потери надёжности системы. Ключевые элементы включают в себя встроенные в агенты инструменты поиска кода, документации и конфигураций, а также механизмы управления контекстом, предотвращающие перегрузку и потерю информации. Важно, что агенты могут использовать «процедурную память» — структурированные инструкции (playbooks), которые позволяют им запоминать последовательность действий и избегать повторного изучения базовых знаний при выполнении аналогичных задач.

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

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

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

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

Java / Spring

Alexander Obregon

How to Run Async Methods in Spring Boot

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

Spring Boot позволяет выполнять медленные операции вне основного потока HTTP-запроса с помощью аннотаций @Async и @EnableAsync. При этом вызов метода остаётся синхронным для клиента, а асинхронная часть передаётся в отдельный поток через механизм прокси-перехвата, не нарушая логику основного потока приложения. Ключевые элементы — включение асинхронности через @EnableAsync, указание метода на асинхронность с помощью @Async, и выбор исполнителя (executor) для выполнения задачи. Важно понимать, что асинхронность работает только при вызове через управляемый Spring-байнд, а внутренние вызовы внутри одного объекта не проходят через прокси и не обрабатываются как асинхронные. Также требуется учитывать, что состояние, связанное с текущим потоком (например, транзакция), не передаётся в асинхронный поток, и при работе с базой данных нужно обеспечить корректное время начала транзакции.

  1. Асинхронный вызов работает только при обращении к методу через Spring-управляемый бин, иначе (например, через new или внутренний вызов) он не проходит через прокси и не становится асинхронным.
  2. При использовании @Async метод должен быть в сервисе с аннотацией @Service, и вызов должен происходить из другого сервиса, чтобы прокси смог перехватить вызов.
  3. Для методов, возвращающих результат, нужно использовать CompletableFuture, чтобы клиент мог получить результат позже, а не ждать его в блокирующем режиме.
  4. При возникновении ошибки в асинхронном методе с возвратом void исключение передаётся в AsyncUncaughtExceptionHandler, и приложение может настроить собственную обработку.
  5. Асинхронные задачи не сохраняют состояние при перезапуске приложения — для надёжности требуется использование внешнего брокера сообщений или дурм-хранилища.

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

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

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

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

Habr Spring

ИИ заставил Java и Spring патчиться чаще

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

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

  1. ИИ-инструменты, такие как Dependabot, автоматически обнаруживают устаревшие зависимости и создают PR с обновлением, что требует от команды регулярно проверять и утверждать изменения.
  2. Для проектов на Spring Boot необходимо обновлять не только библиотеки, но и JDK, Docker-образы и инфраструктуру сборки — всё это влияет на стабильность и безопасность.
  3. Современный стабильный проект — это не тот, который не меняется, а тот, который может быстро обновляться и проверяться без длительных ночей "дейлика".

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

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

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

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

System Design

DEV System Design

How Eventual Consistency Breaks System Logic (And How to Handle It in Distributed Systems)

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

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

Три ключевых подхода к решению:

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

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

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

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

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

Day 166: Encryption at Rest - AI System Design in Seconds

Открыть оригинал ↗ Перевод заголовка: День 166: Шифрование в состоянии покоя — проектирование AI-системы за секунды

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

  1. В базе данных используется прозрачный прокси-сервис, который шифрует чувствительные поля при выполнении запросов, позволяя базе работать как обычно.
  2. В файловой системе применяется полное шифрование диска или шифрование на уровне файлов — оба варианта прозрачны для приложений.
  3. Объектное хранилище (например, S3 или GCS) защищается серверным шифрованием с ключами, управляемыми клиентом, что исключает доступ к чистому тексту со стороны провайдера.
  4. Централизованная служба управления ключами хранит мастер-ключи (обычно в HSM или облачном хранилище) и автоматически управляет их ротацией, обеспечивая аудит и соответствие стандартам безопасности.
  5. При запросах данные шифруются и дешифруются на уровне прокси-слоя, что делает поведение приложения неизменным — безопасность становится частью инфраструктуры.

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

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

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

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

ML System Design vs GenAI System Design: What's Actually Different

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

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

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

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

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

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

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

Why knowing different uses of AI is important now?

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

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

  1. Понимание реальных сценариев использования ИИ в бизнесе помогает избежать гипербол и строить решения, основанные на фактических потребностях.
  2. Умение соединять бизнес-цели с технической реализацией позволяет продукт-менеджерам и разработчикам работать в тесном взаимодействии, минимизируя разрыв между идеями и продуктом.
  3. ИИ — это не просто инструмент для генерации кода, а универсальная технология, как электричество, которая встраивается в любую отрасль, где есть данные.
  4. Развитие "высокой агентности" — способности переключаться между бизнесом, инженерией и управлением — становится ключевым навыком для всех участников процесса.
  5. Практические кейсы по внедрению ИИ в реальных организациях дают ценную модель для обучения, где отражены не только технические, но и рисковые, градуированные аспекты.

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

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

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

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

How Do Big Backend Applications Scale?

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

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

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

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

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

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

Monolith vs Microservices: Stop Choosing Microservices Too Early

Открыть оригинал ↗ Перевод заголовка: Монолиты против микросервисов: остановитесь, когда слишком рано выбираете микросервисы

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

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

  1. Начинайте с модульного монолита, разделяя код по функциональным блокам (например, users/, products/).
  2. Организуйте команды так, чтобы каждая часть монолита имела четкую ответственность и собственную логику.
  3. При необходимости масштабирования или изоляции — разделяйте сервисы, используя уже сформированные границы модулей.
  4. Не вводите микросервисы из-за тренда или давления со стороны "реальных компаний", а только при наличии реальных требований к масштабу или независимости.
  5. Монолит — не устаревший выбор; он может быть оптимальным решением для большинства проектов, особенно в ранних стадиях.

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

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

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

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

Rails, Not Throttles: The AI Model We Need to Change Isn’t the LLM

Открыть оригинал ↗ Перевод заголовка: РAILS, а не тормоза: модель AI, которую нужно изменить, — это не LLM

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

  1. Важно различать «доверие» и «действие»: агент может предложить решение, но не должен иметь право переинтерпретировать свои полномочия.
  2. Необходимы отдельные «rails» (дорожки) — такие как идентификация, владение, авторизация, мандат, проверка и отмена — для обеспечения границ и прозрачности.
  3. Доверие не может быть основано на внутреннем отчёте агента: оно должно быть независимо проверяемо и фиксировано в структуре, а не в памяти системы.
  4. Важно, что архитектура должна быть масштабируемой, устойчивой к сбоям и не зависеть от конкретного провайдера или модели.
  5. Основа доверия должна быть встроена в инфраструктуру (например, через Web3), а не передаваться через отдельные политики или базы данных.

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

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

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

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

That doesn’t mean you should use Redis for everything!

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

Несмотря на высокую скорость и гибкость, Redis не является универсальным решением для всех сценариев. Его привлекательность часто приводит к чрезмерному внедрению в систему, даже там, где другие, более простые и надёжные решения, такие как PostgreSQL, могут быть вполне достаточны. Каждое новое компонентное решение увеличивает сложность системы: количество сервисов, точки отказа, необходимость мониторинга и проблемы с распределённым состоянием. Важно оценивать контекст: Redis подходит в тех случаях, когда требуется высокая скорость доступа к данным, временные кэширования или синхронизация состояния. Однако в других случаях — например, при работе с стабильными, часто изменяемыми данными — более простые решения могут быть не только эффективнее, но и безопаснее.

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

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

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

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

Building a Rate Limiter Like Neo

Открыть оригинал ↗ Перевод заголовка: Строим лимитер запросов как Нeo

Автор столкнулся с проблемой масштабирования при работе с внешними API: простой механизм с setTimeout не справлялся с пиками нагрузки, превращаясь в бутылку шеи. Вместо сложных, неудобных решений он выбрал простой и понятный подход — алгоритм «корзины токенов», который позволяет гибко управлять скоростью запросов. Вместо жёстких окон сброса (fixed-window) лимитер на основе токенов обеспечивает плавное ограничение, позволяя коротким всплескам нагрузки без перегрузки системы, при этом сохраняя простоту и прозрачность.

  1. Алгоритм работает на основе токенов: каждый запрос пытается забрать токен, если их нет — запрос отклоняется или ожидает, что обеспечивает гибкое управление скоростью.
  2. Позволяет короткие всплески (burst) — клиент может сделать до capacity запросов сразу, после чего токены постепенно возвращаются по скорости rate_per_sec.
  3. Использует только три переменные (две — вводные, одна — состояние), что делает его легко масштабируемым и применимым в распределённых системах.
  4. Поддерживает дробные значения скорости (например, 2.5 запросов в секунду), избегая сложных округлений.
  5. Легко адаптируется под разные сценарии: увеличение capacity для больших задач, снижение rate для критичных эндпоинтов.

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

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

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

  1. Как изменится поведение лимитера при значительном увеличении capacity (например, в 10 раз), если в реальном мире API может быть подвержен атакам с бурст-запросами — как это влияет на безопасность и надёжность?
  2. При каких условиях токен-бакет может привести к неожиданному перегреву системы, если не учитывать динамику нагрузки и распределение запросов по времени?
  3. Какова сложность алгоритма при работе с большим количеством параллельных запросов и как это влияет на производительность при масштабировании в Redis?

InfoQ Architecture

AWS Lambda Pushes Serverless Toward Long-Running Workloads

Открыть оригинал ↗ Перевод заголовка: AWS Lambda расширяет серверное программирование за счёт поддержки длительных задач

AWS Lambda теперь позволяет функциям, запущенным на инстансах Lambda Managed Instances, работать до 90 минут — в шесть раз дольше предыдущего лимита в 15 минут. Это изменение позволяет использовать Lambda для стабильных, длительных задач, таких как обработка медиа, финансовые расчёты или ETL, где ранее приходилось применять обходные решения. Важно понимать, что даже при увеличении времени выполнения Lambda не гарантирует однократное выполнение операций, и при длительных сессиях риски дублирования и повторного запуска растут. Для предотвращения ошибок рекомендуется внедрять идемпотентность в коде, например с помощью библиотеки Powertools, и обеспечивать корректную обработку повторных вызовов. Также важно учитывать, что такие длительные задачи могут быть экономически нецелесообразными, особенно если они просто ждут внешних событий, и в таких случаях более подходят решения, такие как AWS Batch или ECS.

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

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

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

  1. В каких сценариях 90-минутный таймаут Lambda может привести к увеличению затрат, даже если функция выполняет полезную работу?
  2. Какие риски связаны с дублированием выполнения при длительных задачах, и как это может повлиять на надёжность системы в production?
  3. В чём разница между использованием Lambda Managed Instances и AWS Batch для длительных задач, и в каких условиях первый становится более предпочтительным?

Coding / Algorithms

DEV Data Structures

The Matrix Reloaded: Mastering Kadane's Algorithm from Zero to Hero

Открыть оригинал ↗ Перевод заголовка: Матрица 2: освоение алгоритма Кадана от нуля до мастерства

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

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

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

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

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

How Ring Buffers Work: Low-Latency Circular Queues

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

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

  1. Кольцевой буфер использует модульную арифметику для "обхода" конца массива — следующий индекс вычисляется как (текущий_индекс + 1) % размер, что позволяет бесконечно циркулировать по фиксированному объему памяти без изменений в структуре.
  2. В отличие от динамических массивов, где удаление элемента требует сдвига всех оставшихся элементов (O(N)), кольцевой буфер обеспечивает постоянную производительность без перераспределения памяти.
  3. При переполнении буфера (когда указатель записи догоняет указатель чтения) система может либо перезаписывать старые данные, либо останавливать входящий поток — это критично для синхронизации в медиа-потоках.
  4. В отличие от циклических связных списков, кольцевой буфер использует физически непрерывный блок памяти, что обеспечивает лучшую кэшированность и производительность.
  5. Кольцевые буферы применяются не только в медиа-плеерах, но и в ядрах ОС, сетевых адаптерах, обработке ввода-вывода и протоколах UART.

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

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

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

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