AI

Habr AI

Сколько «агентских сил» под капотом? Почему AI-агентов всё ещё трудно сравнивать

Открыть оригинал ↗ Перевод заголовка: Сколько «агентских сил» под капотом? Почему AI-агентов всё ещё трудно сравнивать

Статья раскрывает, что оценка «мощности» AI-агента не сводится к простым цифрам — даже китайский регулятор, определяющий границы экспорта, использует пороги по масштабу и качеству, но не устраняет фундаментальных проблем измерения. В документе приведены три ключевых критерия: 20 подзадач, 60 одновременно работающих агентов и 200 инструментов, но каждый из них сопровождается условиями точности, успешности и соответствия эталону. Основная сложность — в том, что эти метрики зависят от выбора задач, среды, бюджета и способа проверки результата, что делает их неприменимыми вне лабораторных условий.

  1. Масштаб не означает качество: пороги по количеству подзадач, агентов или инструментов требуют дополнительных метрик (точность, успешность, соответствие) и не могут быть интерпретированы как универсальные показатели.
  2. Качество оценки зависит от контекста: 90% успешности — это не абстрактная цифра, а результат, полученный на определённых задачах, в конкретной среде и с определённым бюджетом.
  3. Результаты бенчмарков не переносятся на реальную эксплуатацию: в лаборатории агент может успешно выполнить задачу, но в реальной системе сбои, изменения состояния или downstream-эффекты могут привести к неожиданным последствиям.
  4. Автономность и надёжность не измеряются только через количество попыток: важно понимать, кто проверяет результат, как обрабатываются ошибки и как система восстанавливается.
  5. Сравнение агентов — это не сравнение моделей, а сравнение целых систем: включая память, планировщик, инструменты, повторные попытки и взаимодействие с другими агентами.

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

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

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

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

[Перевод] ИИ доказал квазигипотезу Римана. Что дальше?

Открыть оригинал ↗ Перевод заголовка: ИИ доказал квазигипотезу Римана. Что дальше?

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

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

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

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

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

Java / Spring

Alexander Obregon

Weekly Recap – October 25th, 2026

Открыть оригинал ↗ Перевод заголовка: Еженедельный обзор – 25 октября 2026 года

В прошлую неделю автор опубликовал две статьи: одну о настройке профилей в Spring Boot 4 для разных сред разработки — от разработки до производства — и другую — о преобразовании данных в SQL Server, где столбцы превращаются в строки (операция «unpivot»). Эти темы актуальны для разработчиков, работающих с конфигурацией приложений и обработкой структурированных данных.

— В Spring Boot 4 можно эффективно управлять профилями, используя разные конфигурации для каждой среды (dev, test, prod), что позволяет избежать перекрытия настроек и упрощает деплои.
— Операция «unpivot» в SQL Server позволяет трансформировать широкую таблицу (с множеством столбцов) в длинную, что полезно при работе с динамическими или нестандартными данными.
— Обе темы демонстрируют практическую реализацию стандартных паттернов: модульность конфигурации и гибкость работы с данными.
— Профили в Spring Boot могут быть настроены с помощью YAML-файлов и аннотаций, что даёт гибкость при развертывании.
— Unpivot требует понимания структуры данных и может быть неэффективным при больших объёмах, поэтому важно оценивать производительность.

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

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

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

  1. Какие риски связаны с использованием профилей в Spring Boot 4 при развертывании в production, если настройки не проверяются автоматически?
  2. В каких сценариях unpivot может привести к потере данных или неправильной интерпретации, и как это можно предотвратить без изменения структуры исходных таблиц?
  3. Какова оценка производительности unpivot в SQL Server при работе с миллионами строк и большими таблицами — и как это влияет на выбор альтернативных подходов к обработке данных?

Engineering With Java

Top Spring Data JPA Interview Questions ( Real World Use Case Based )

Открыть оригинал ↗ Перевод заголовка: Вопросы на собеседованиях по Spring Data JPA (на основе реальных случаев использования)

Статья представляет серию практических вопросов на собеседованиях по Spring Data JPA, основанных на реальных сценариях ошибок и проблем в приложениях. Каждый вопрос описывает конкретную ситуацию, в которой поведение JPA или его интеграции приводит к неожиданным результатам — от дублирования данных до сбоев в транзакциях и проблем с подключением к базе. Вопросы охватывают ключевые аспекты: ленивую загрузку, управление транзакциями, генерацию идентификаторов, а также поведение приложений в production-среде.

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

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

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

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

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

Top Core Java Interview Questions ( Real World Use Case Based )

Открыть оригинал ↗ Перевод заголовка: Вопросы по основам Java (на основе реальных случаев использования)

Статья представляет собой сборник практических и сложных вопросов по Java, ориентированных на реальные сценарии разработки, а не на теоретические тесты. Вопросы охватывают ключевые темы: поведение коллекций (HashSet vs TreeSet), применение final-классов, работа с потоками (streams), отражение (reflection), ошибки в коде и сложные сценарии, такие как объединение приоритетных очередей или баги в enum. Материал подчёркивает важность понимания не только синтаксиса, но и потенциальных ошибок, которые могут возникнуть в production-среде.

  1. HashSet хранит элементы в неупорядоченном виде и обеспечивает O(1) поиска, в то время как TreeSet обеспечивает упорядоченность и O(log n) поиска, но требует больше памяти и времени на операции вставки/удаления.
  2. Использование final-классов предотвращает наследование и позволяет избежать неожиданных изменений состояния, но может ограничивать гибкость при проектировании.
  3. Статические инициализаторы могут привести к неожиданным последствиям при запуске приложения, особенно если они зависят от внешних ресурсов.
  4. Коллекции не наследуют Cloneable и Serializable, чтобы избежать нежелательных побочных эффектов при копировании или сериализации, что требует от разработчика явного управления этими операциями.
  5. Потоки (streams) могут иметь побочные эффекты, особенно при использовании методов, изменяющих состояние, что может привести к неопределённому поведению в сложных сценариях.

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

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

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

  1. В каких случаях использование TreeSet может привести к производительности ниже ожидаемой, и как это влияет на выбор между HashSet и TreeSet в условиях высокой нагрузки?
  2. Какой компромисс между гибкостью и надёжностью в проектировании final-классов, если они должны быть использованы в гибридной архитектуре с динамическими модулями?
  3. Какие hidden side effects могут возникнуть при использовании Java streams в цепочке обработки данных, если не учитывать порядок выполнения и изменение состояния?

Foojay

Pi4J Drivers V1.2.0: ePaper, DAC/ADC, Motors, and LoRa

Открыть оригинал ↗ Перевод заголовка: Драйверы Pi4J V1.2.0: ePaper, DAC/ADC, моторы и LoRa

Новая версия драйверов Pi4J (V1.2.0) расширяет поддержку популярных компонентов, позволяя работать с ними через высокий уровень Java-интерфейсов без необходимости изучения технических спецификаций. Включены драйверы для ePaper-дисплеев, аналоговых вводов/выводов, моторных драйверов и LoRa-модулей, что значительно упрощает разработку проектов в области IoT и робототехники.

  1. Добавлен универсальный драйвер SSD1680 для ePaper-дисплеев с поддержкой частичных обновлений, что снижает всплески и улучшает плавность отображения.
  2. Введена новая структура для работы с аналоговыми сигналами: интерфейс DigitalAnalogConverter и обновлённые драйверы для MCP49xx, MCP4725, MCP4728 (DAC) и TI ADS111x, NAU7802 (ADC), с разделением поддержки по разрядности.
  3. Поддержка новых моторных решений — LN298, ULN2003 и PiBorg UltraBorg — позволяет строить роботы и системы с движением.
  4. Добавлен драйвер для LoRa-модуля Semtech LR11xx, что открывает возможности для беспроводных, низкоэнергетических проектов.
  5. Улучшена работа с текстом и графикой: введён GraphicsTextAnimator, поддержка зеркалирования экрана и управление курсором в CharacterDisplay.

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

Материал полезен при разработке проектов на Raspberry Pi, где требуется интеграция датчиков, дисплеев, моторов или беспроводной связи через чистый Java-код без написания низкоуровневого кода.

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

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

Habr Java

Тестовые данные отдельно, код отдельно: 5 способов изолировать данные в автотестах на Java

Открыть оригинал ↗ Перевод заголовка: Тестовые данные отдельно, код отдельно: 5 способов изолировать данные в автотестах на Java

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

  1. Параметры командной строки позволяют быстро переключаться между окружениями, но не подходят для сложных конфигураций из-за отсутствия типизации и читаемости.
  2. Библиотека Owner автоматически парсит файлы конфигураций и обеспечивает типизированные настройки без ручных if-else, с поддержкой приоритетов загрузки.
  3. Data-Driven Testing в TestNG позволяет проверять множество входных данных через CSV-файлы, с встроенной поддержкой параллельности и отчётности.
  4. Динамическая фабрика данных генерирует уникальные сущности на лету и удаляет их после теста, обеспечивая полную изоляцию при параллельных запусках.
  5. Хранение секретов в Vault предотвращает утечку паролей и токенов, но требует настройки инфраструктуры и доступа к системе.

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

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

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

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

Inside Java

JEP targeted to JDK 28: 544: Ahead-of-Time Code Compilation

Открыть оригинал ↗ Перевод заголовка: JEP направлен на JDK 28: 544: Аут-оф-тайм компиляция кода

Предлагаемое изменение в OpenJDK — JEP 544 — включает в себя введение механизма аут-оф-тайм (AOT) компиляции для Java-кода, позволяющего компилировать программы на этапе построения, а не при запуске. Это позволяет ускорить запуск приложений, особенно в средах с высокими требованиями к производительности, таких как облачные сервисы или инфраструктура с жесткими ограничениями на время ответа. Введение AOT-компиляции может значительно сократить время загрузки и уменьшить потребление ресурсов при запуске, особенно в контексте контейнеризации и микросервисов.

  1. AOT-компиляция позволяет компилировать Java-код до запуска приложения, что снижает время инициализации и ускоряет запуск в production-средах.
  2. Механизм поддерживает компиляцию в статическом режиме, что делает его особенно полезным для образов приложений, таких как Docker-образы, где требуется минимальное время запуска.
  3. Введение AOT-компиляции требует изменения архитектуры запуска JVM, включая поддержку новых форм метаданных и валидации кода на этапе сборки.

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

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

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

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

Nicolas Frankel

Security Baked Into the JVM: DirtyChai scales vertically, JGDMS scales horizontally

Открыть оригинал ↗ Перевод заголовка: Безопасность в JVM: DirtyChai масштабируется вертикально, JGDMS — горизонтально

Статья показывает, как система безопасности в JVM может быть реализована без потерь производительности при высокой нагрузке. В то время как стандартный SecurityManager не используется в продакшн из-за нестабильности под нагрузкой, в DirtyChai и JGDMS достигнуты как производительность, так и безопасность за счёт глубокой оптимизации механизмов проверки прав и контекста. В DirtyChai виртуальные потоки получают контекст от родительского потока, а не от платформенного, что обеспечивает изоляцию запросов. В JGDMS масштабирование происходит посредством добавления новых узлов без пересоздания конфигурации, что делает систему устойчивой к отказам. Ключевыми инновациями являются DomainIdentity (для корректной идентификации контекста), ConcurrentPolicyFile (для параллельной проверки политик без блокировок), и использование хэш-адресации для вердиктов, что позволяет избежать DNS-запросов и дублирования. Система поддерживает масштабирование без потери безопасности, даже при отказах узлов.

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

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

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

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

System Design

DEV System Design

I Won’t Walk Into a System Design Interview Without Practicing This Follow-Up

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

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

  1. Перед изменением API необходимо выявить всех потребителей (клиентов, сервисов, импортеров) и определить, какие комбинации версий могут работать вместе.
  2. Внедрение нового поля (например, profile_name) должно происходить постепенно, с сохранением старого поля как источника истины, пока не подтверждено, что все активные писатели используют новую логику.
  3. Обновление данных в истории (backfill) должно быть атомичным и проверяться на наличие изменений, чтобы избежать дивергенции между старыми и новыми значениями.
  4. Плавное включение новых запросов требует контроля за ошибками и отслеживания рисков в ограниченной группе пользователей, прежде чем масштабировать.
  5. План отката должен быть конкретным: возвращение к старой версии не означает возврата к старому бинарному файлу, а требует сохранения состояния и проверки всех активных писателей.

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

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

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

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

Hotel Booking System like Booking.com

Открыть оригинал ↗ Перевод заголовка: Система бронирования отелей как Booking.com

При высокой нагрузке — 9 000 запросов на поиск и 500 бронирований одновременно — традиционная реляционная база данных перегревается, что приводит к задержкам, блокировкам и ошибкам оплаты. Для стабильной работы разработчики разделяют систему на два пути: чтение и запись, где чтение (поиски) обрабатывается быстро с помощью Elasticsearch и Redis, а запись (бронирование) обеспечивается через изолированные транзакции с использованием MySQL и Kafka.

  1. Чтение разделяется на путь с фильтрацией по географии и типам отелей через Elasticsearch, с кэшированием количества свободных номеров в Redis, что позволяет обрабатывать до 9 000 запросов в секунду с задержкой менее 200 мс.
  2. Запись использует изолированные транзакции: бронирование фиксируется в MySQL с блокировкой инвентаря, а таймер отсрочки (10 минут) передаётся в SQS, затем в Kafka для синхронизации с кэшами.
  3. Для предотвращения конфликтов в бронировании используется строгая последовательность дат (например, Dec 20 → Dec 21), а не отдельные номера, что сокращает время блокировки до 5 мс.
  4. Оплата идёт в атомарном режиме: статус брони сразу меняется на PAYMENT_PROCESSING перед вызовом платежной системы, чтобы избежать оплаты за утерянный номер.
  5. Инвентарь и брони хранятся в одной базе данных, чтобы избежать медленных двухфазных коммитов и обеспечить транзакцию в 2 мс.

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

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

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

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

How We Architected a Zero-Drift, Reactive Timezone Engine for Enterprise Applications

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

В статье описывается катастрофический сценарий, когда неправильное использование UTC-строк вводит ошибку в финансовые отчёты — на 48 200 долларов из-за неверного преобразования даты в разных часовых поясах. Автор демонстрирует, как в корпоративных приложениях временные зоны должны обрабатываться как реактивная, динамическая сущность, а не как статичные настройки. Вместо хранения UTC-смещений, система использует IANA-идентификаторы, чтобы корректно отражать переходы в летние и зимние часы. В центре архитектуры — пятислойная система интеграции (Onion Interceptor), обеспечивающая реактивное обновление данных при смене часового пояса, с защитой от перегрузки сети и утечек памяти.

  1. Всегда храните даты в UTC, а не в смещениях.
  2. Используйте двухуровневую кэширование (IndexedDB + память) для предотвращения "стампейдов" при загрузке каталога временных зон.
  3. Реализуйте 4-ступенчатую иерархию разрешения, чтобы сохранять пользовательский выбор при перезагрузке и корректно обрабатывать устаревшие имена поясов (например, Asia/Dacca).
  4. Оптимизируйте реактивность через селективное включение (HttpContextToken) и сегментацию запросов с помощью лимита на количество одновременных перезагрузок (8-местный барьер).
  5. Обеспечьте безопасность и стабильность через отключение реактивности для изменений данных (POST/PUT/PATCH/DELETE) и автоматическое уничтожение устаревших подписок.

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

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

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

  1. Какой компромисс между скоростью реактивности и безопасностью в случае, если пользователь сменяет часовой пояс 10 раз подряд, и каждый раз запускается новая сессия запросов?
  2. В каких сценариях может сработать "зомби-подписка" при смене пояса, если в UI есть несколько динамических фильтров, каждый из которых вызывает отдельный GET-запрос?
  3. Как изменится поведение системы при использовании нестандартных IANA-поясов, если в backend нет их поддержки, но в браузере они возвращаются как часть стандартной настройки?

Building a Priority-Based Task Scheduler with FastAPI, Redis, and C++

Открыть оригинал ↗ Перевод заголовка: Сборка приоритетного планировщика задач с FastAPI, Redis и C++

Система разделяет обработку задач на этапы: клиент отправляет запрос через REST-интерфейс, который валидирует параметры и применяет ограничение на количество запросов, после чего задача помещается в приоритетные очереди Redis. Задачи из очередей извлекаются фоновым процессом, который передаёт их на обработку в C++-сервис, где выполняются операции шифрования, хеширования и сжатия. Результаты и статусы задач сохраняются в PostgreSQL, позволяя клиентам периодически проверять статус выполнения. Ключевыми архитектурными решениями являются разделение ответственности между API и обработчиком, использование Redis для приоритетных очередей и отсутствие встроенной механизмы восстановления при сбоях.

  • Приоритетные очереди (высокий, средний, низкий) позволяют маршрутизировать задачи по важности, но могут привести к проблеме «загиба» (starvation) низкоприоритетных задач при постоянном потоке высокоприоритетных запросов.
  • Обработка в C++ изолирована от API, что упрощает тестирование и масштабирование, но вводит задержки из-за HTTP-обмена и сериализации.
  • Система использует Redis для хранения очередей и контроля скорости запросов, однако при сбое рабочего процесса задачи могут оставаться в состоянии «в процессе» или «ожидание» без восстановления.
  • Статус задач проверяется через polling, что требует повторных запросов от клиента, не обеспечивая реального push-обновления.
  • Несмотря на безопасность шифрования (AES-256-CBC), отсутствует аутентификация данных, что может быть уязвимым для подделки.

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

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

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

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

API business software design patterns

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

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

Тезисы:

  1. Для аутентификации используются два вектора: для пользователей — федеративная 2FA через SAML/OpenID Connect, для систем — AppID и AppSecret с OAuth-токенами, что исключает передачу секретов в запросах.
  2. Сессии хранятся в Redis с шифрованием JWT, что обеспечивает масштабируемость и возможность мгновенного отзыва сессий. Доступ контролируется через RBAC и ABAC с проверкой состояния сессии на каждом запросе.
  3. Трафик управляется через гибкое масштабирование, лимиты по количеству запросов и конкуренции, что предотвращает перегрузку и атаки.
  4. Разработчикам предоставляются отдельные ключи для тестирования (Sandbox) и производства, а также SDK на популярных языках, которые упрощают интеграцию.
  5. Архитектура строится на «трёх плюс» слоях: серверные функции (Lambdas), изолированные хранилища данных и S3 для файлов, при этом CRM и Data App разделены для минимизации рисков. Монетизация ведётся по времени обработки, а не по количеству запросов — это делает модель прозрачной и пропорциональной реальным затратам.

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

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

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

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

Rate Limiter Designs

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

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

  1. Алгоритм фиксированного окна — прост и экономичен, но подвержен атаке на границах окна (burst attack), где может быть пропущено до двухкратное увеличение нагрузки.
  2. Слайдинг-окно с логом — точный, не имеет границ, но требует хранения всех временных меток, что делает его несовместимым с масштабными системами.
  3. Гибридное слайдинг-окно — компромисс между точностью и производительностью, использует два счетчика и взвешивает их по времени, что делает его пригодным для реальных систем.
  4. Модель «бочонка» (Token Bucket) — наиболее популярный выбор, обеспечивает плавное ограничение скорости и позволяет короткие всплески, используется в AWS и Stripe.
  5. Модель «вытекающей бочки» (Leaky Bucket) — гарантирует стабильный поток, но добавляет задержку из-за очередей, что делает её менее подходящей для высокоскоростных API.

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

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

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

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

Designing for the Inevitable: The Pragmatic Guide to Distributed Fault Tolerance

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

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

  1. Использование схемы «цепной пробой» (circuit breaker) для быстрого отказа при сбое зависимостей, предотвращающей перегрузку и блокировку.
  2. Разделение ресурсов с помощью паттерна «bulkhead» — изоляция потоков выполнения и соединений, чтобы сбой одного компонента не затрагивал остальные.
  3. Применение экспоненциального отсрочки с дрейфом (jitter) при повторных попытках, чтобы избежать «волнового эффекта» и перегрузки.
  4. Введение строгих таймаутов на каждом уровне вызова и многоуровневого ограничения скорости (rate limiting) для предотвращения истощения ресурсов.
  5. Использование отдельных проверок здоровья (liveness/readiness) и распределённого трейсинга для быстрой диагностики и изоляции сбоев по причине конкретного компонента.

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

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

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

  1. Какой компромисс между скоростью восстановления и надёжностью в паттерне «bulkhead» проявляется при увеличении числа изолированных пулов, и как это влияет на масштабируемость?
  2. В каких условиях экспоненциальный отсчёт с дрейфом может привести к неожиданному увеличению времени ожидания, и как это может быть оценено при нагрузке на 90%?
  3. Какой вклад в отказоустойчивость вносит «lease-based leader election» в системах с высокой частотой сбоев и низкой задержкой восстановления?

Your ranking model can be perfect offline and still fail the interview

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

Интервью не проверяет точность вашей модели — оно проверяет вашу способность оценивать её. Важно понимать структуру системы: сначала генерация кандидатов, затем ранжирование. Начинать с ранжирования — значит уже потерять на этапе масштабируемости. Ранжирование делится на два этапа: лёгкая модель для первичного ранжирования (сотни вариантов), тяжёлая — для финального реранжирования (десятки). Выбор модели определяется не точностью, а заданным временем отклика (например, 100 мс p99), который может быть критичен для производственной системы. Фичи делятся на три категории: пользователь, товар, контекст, с одной ключевой — взаимодействие между пользователем и товаром. При этом список из 30 фич — это неэффективно, лучше защитить 5 ключевых. Метрики могут показывать успех в оффлайне (AUC/NDCG), но в реальном мире — без роста дохода, что указывает на смещение в данных (выборка), позиционный эффект кликов или задержку обратной связи. Важно не просто сказать "проверим через A/B", а дать диагноз и решение. Основная архитектура остаётся неизменной: ретриев → лёгкий ранжер → тяжёлый ранжер → калибровка. Ключевое — не точность, а выбор компромисса между скоростью, масштой и качеством.

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

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

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

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

InfoQ Architecture

PingCAP Breach Exposes Customer Records and Source Code

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

PingCAP подтвердил несанкционированный доступ к внутренним системам и утечку исходного кода и персональных данных клиентов. Атакующая группа FulcrumSec утверждает, что скопировала 10,6 ТБ данных, включая контрольные записи TiDB Cloud, SQL-запросы клиентов, API-ключи, логи подключений и внутренние документы, а также 413 репозиториев с исходным кодом. Хотя данные не независимо подтверждены, утечка охватывает критически чувствительную информацию — имена, email-адреса, структуру схем, API-ключи и конфигурации клиентов, что создаёт высокий риск фишинга и атак на инженеров.

  1. Утечка включает в себя не только данные клиентов, но и внутренние процессы — например, пастинг производственных ключей в Jira, что делает инженеров уязвимыми для фишинга.
  2. Несмотря на отсутствие доказательств нарушения данных в TiDB, утечка метаданных и логов может быть использована для построения точных атак, включая подделку запросов и фишинг.
  3. Поведение атакующей стороны — длительное присутствие без обнаружения — подрывает доверие к системам мониторинга и контролю доступа, особенно в облачных средах.

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

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

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

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

React Java

I Joined 20+ Software Architecture Courses on Udemy - Here Are My Top 5 Recommendations for Experienced Developers

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

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

  1. Курс «Software Architecture & Design of Modern Large Scale Systems» Майкла Погребинского — идеален для понимания масштабных систем и их архитектурных паттернов.
  2. Курс Анурага Ядова — наиболее объёмный по содержанию, включает современные технологии и развертывание на Docker и Kubernetes.
  3. Курс Меми Лави по микросервисам — отличный ввод с простым объяснением сложных концепций и высокой оценкой от студентов.
  4. Курс Мунавара Али «Master Software Architecture & System Design» — ведёт к практическим навыкам и включает лаборатории на AWS.
  5. Курс «The Complete Cloud Computing Software Architecture Patterns» — показывает, как облачные технологии влияют на архитектуру систем.

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

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

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

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

Coding / Algorithms

DEV Data Structures

Trace Path: Why Net Displacement Is the Wrong Check

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

В задаче по отслеживанию пути в сетке многие сразу идут по пути подсчёта итогового смещения — например, разница между количеством левых и правых шагов. Однако это проверяет только конечную позицию, а не каждый шаг. Чтобы оставаться внутри сетки на каждом шагу, нужно проверять диапазон позиций (разность между максимальным и минимальным смещением) на каждом из двух осей. Вместо этого можно разбить задачу на две независимые одномерные задачи: одна для строк, другая для столбцов. Для каждой оси отслеживается минимальное и максимальное смещение от начальной позиции. Если диапазон смещений на оси меньше длины этой оси, то путь может быть вписан в сетку. Это работает за O(|s|) времени, независимо от размеров сетки, и не требует проверки всех начальных позиций.

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

Материал полезен, когда нужно решать задачи с движением по двумерной сетке, где каждый шаг должен оставаться внутри границ, и при этом важно избежать O(n×m×s) времени симуляции всех начальных позиций.

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

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

DEV LeetCode

First Hackathon Project

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

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

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

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

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

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

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