Risk Management

arXiv Quantitative Finance - Pricing

When defaults cannot be hedged: xVA calculations via local risk-minimization

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

Статья рассматривает ситуацию, при которой кредитный риск контрагентов и финансирование невозможно хеджировать из-за отсутствия рынков котировок корпоративных облигаций или CDS, а также из-за технических ограничений для банка при покупке/продаже защиты на свой собственный дефолт. Авторы предлагают использовать метод локальной минимизации риска для определения оптимальной стратегии и вычисления ценовых коррекций (xVA), что позволяет учитывать несбалансированные и непропорциональные риски в условиях отсутствия хеджей.

  1. Метод локальной минимизации риска позволяет вычислить xVA без предположения о возможности хеджирования дефолтов, что делает его применимым в реальных условиях, где такие инструменты, как CDS, отсутствуют.
  2. Расчёты проводятся через стохастическое дифференциальное уравнение (BSDE), что обеспечивает математическую строгость и возможность численной реализации в финансовых моделях.
  3. Подход не требует предварительного выбора структуры хеджирования, что делает его более гибким и адаптивным к разнообразным рыночным условиям.
  4. Работа показывает, что даже при полной неспособности хеджировать дефолты, можно получить рациональную оценку рисков и коррекций, что критически важно для надёжности финансовых моделей.

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

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

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

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

arXiv Quantitative Finance - Risk Management

Landscape-Dependent Performance of Photonic Quantum Solvers in QUBO Feature Selection for Financial Risk Detection

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

Статья сравнивает три подхода к выбору признаков в задачах обнаружения рисков в финансовых данных: классический оптимизатор Gurobi, фотонный решатель QCI Dirac-3 и имитационный фотонный бозонный сэмплинг Piquasso. Оценка проводится на двух датасетах — ULB (30 признаков) и AmEx (159 признаков) — с использованием 13 методов выбора признаков. Результаты показывают, что эффективность решателей сильно зависит от структуры признакового пространства: на ULB признаки более концентрированы, что приводит к большей вариабельности метрик между методами, в то время как на AmEx производительность растёт с ростом числа признаков и все подходы приближаются к F1 = 0.80 при полном наборе признаков. Особенно заметна разница между Gurobi и Dirac-3 при использовании метрики distance correlation на AmEx при k=25 — разрыв в F1 достигает 0.3, что указывает на плохую обобщаемость оптимального решения.

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

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

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

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

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

The Physical Crash Frontier: What Finite Option Quotes Can and Cannot Reveal

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

Представленный анализ показывает, что вероятности физических катастроф, восстанавливаемые из опционных котировок, зависят от функции ценности и распределения рисков, которые не могут быть однозначно определены на основе конечного числа спотовых и оффер-котировок. Для инвестора с функцией полезности вида степенной, работа построена на определении диапазона возможных значений вероятности катастрофы и ожидаемого ущерба при её наступлении — граница этого диапазона именуется физической границей катастрофы. При определённых условиях эта граница является выпуклой и может быть вычислена точно с помощью задач второго порядка конуса при фиксированной степени рисковой предпочтительности. Анализ исторических данных по индексу S&P 500 показывает, что котировки наиболее глубоких опционов (на падение до 10%) сокращают допустимый диапазон вероятностей катастрофы примерно на 80%, но верхняя граница остаётся в 2–3 раза выше нижней. При строгом условии «малой разницы» между котировками и условии внутренней массы, отсутствие ограничения на хвост распределения приводит к тому, что нижние границы вероятности катастрофы и неусловные потери стремятся к нулю при рисковой предпочтительности выше единицы.

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

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

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

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

AI

Habr AI

[Перевод] Interpretable Context Methodology (Методология интерпретируемого контекста): структура директорий как архитектура агента

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

Методология интерпретируемого контекста предлагает заменить сложные оркестрационные фреймворки (например, CrewAI или LangChain) на простую структуру файловой системы, где каждый этап пайплайна определяется через Markdown-файлы. Агент использует эту структуру как инструкцию, чтобы понимать, что делать на каждом шаге, при этом каждый этап работает с минимальным и релевантным контекстом, что снижает нагрузку на модель и упрощает отладку. Подход основывается на принципах Unix-пайплайна и разделения зависимостей, позволяя модулям отвечать за одну задачу и избегать пересечения ответственности.

  1. Каждый этап пайплайна работает с отдельной директорией, где результаты сохраняются в /output, а предыдущие этапы — как входные данные — автоматически передаются следующему.
  2. Агент загружает только контекст, необходимый для текущего этапа, что исключает деградацию точности при длинных контекстах и устраняет необходимость в компрессии.
  3. Структура директорий позволяет легко переиспользовать этапы (DRY), копируя директории, и вносить изменения в один файл — они автоматически распространяются на все пайплайны.
  4. Markdown-файлы одновременно служат как инструкции для агента, так и документацией, что делает систему понятной для новичков без запуска.
  5. Пайплайн остаётся моделенезависимым, так как все взаимодействия основаны на текстовых файлах, а не на API-интерфейсах.

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

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

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

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

Java / Spring

Engineering With Java

Engineering With Java: Digest #106

Открыть оригинал ↗ Перевод заголовка: Инженерия на Java: Аналитика #106

В этом выпуске рассматриваются практические аспекты разработки на Java и Spring Boot — от параллельных процессов и наблюдаемости до интеграции искусственного интеллекта и оптимизации производительности. Особое внимание уделено миграции Spring Boot 4, улучшениям в JDK 27, внедрению AI-инструментов и архитектуре JVM-экосистемы. Также представлены практические примеры: тестирование восстановления Kafka-потребителей, работа с нативными Java-приложениями, интеграция WebAssembly в базы данных и тестирование CDI без сервера.

  1. JDK 27 включает в себя улучшения по производительности, такие как включение компактных заголовков объектов по умолчанию и переход G1-коллектора как стандартного везде, что снижает потребление памяти и задержки.
  2. Новая архитектура Lathe позволяет запускать Java-серверы прямо из Maven-проекта без настройки IDE, обеспечивая синхронизацию с реальным класспэтом и повышая доступность инструментов разработки.
  3. Возможность использовать один и тот же Java-модель в мобильных приложениях, бэкенде и базе данных упрощает синхронизацию логики и валидации, а также позволяет генерировать DAO и API-код автоматически.
  4. Встраивание WebAssembly-модулей (например, анализатора на Rust) в Neo4j через wasmtime-java обеспечивает изоляцию и портабельность, но сопряжено с увеличением задержек, что делает его подходящим только для низкочастотных задач.
  5. Тестирование CDI-компонентов без запуска приложения сервера с помощью Weld SE и WeldInitiator позволяет проводить быстрые, близкие к реальному коду тесты, что улучшает скорость разработки и надёжность.

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

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

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

  1. В каких сценариях использование компактных заголовков объектов в JDK 27 может привести к ухудшению производительности, несмотря на снижение памяти?
  2. Какой компромисс между производительностью и масштабируемостью в случае встраивания WebAssembly-модулей в Java-приложение через wasmtime-java?
  3. При каких условиях тестирование CDI-компонентов без сервера может привести к ложным результатам или упущенным ошибкам в реальном приложении?

Java67

I Tried 20+ Java Certification Courses - Here Are My Top 5 Recommendations for 2026

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

Сертификация Java SE 11 (1Z0-819) и последующих версий — одна из самых сложных на уровне разработчика, особенно из-за глубины вопросов и отсутствия прямого разделения на «начальный» и «профессиональный» уровень. Ключевыми сложностями являются модульная система Java, в которой большинство кандидатов не имеют практического опыта, а также повышенная сложность вопросов, которые требуют знания нескольких концепций одновременно. Официальное название «OCAJP» было упразднено, и теперь существует единая сертификация по версиям Java, начиная с 11. Для подготовки к экзаменам 1Z0-819, 1Z0-829 и 1Z0-830 рекомендуются книги и курсы, охватывающие модульность, новые конструкции (records, sealed classes, switch expressions), а также глубокое понимание фундаментальных принципов Java. Особенно важна практика с тестами, так как экзамены требуют высокой скорости и точности, особенно в условиях ограниченного времени (2 часа на 50 вопросов).

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

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

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

  1. В чём заключается компромисс между глубиной изучения модульной системы и общей эффективностью подготовки к экзамену, если у ученика нет опыта работы с модулями в реальных проектах?
  2. Какие риски связаны с использованием только одного учебника (например, «Java SE 11 Study Guide») без дополнительных практик, если экзамен включает вопросы с множественными вариантами ответа и сложной логикой?
  3. В каких условиях (по времени, объёму, сложности) может быть оправдано использование курса по Java 21 вместо специализированных курсов по Java 11 и 17, если цель — сдать сертификацию на уровне OCPJP 21?

System Design

DEV System Design

The 5 System Design Tradeoffs Every Backend Engineer Must Navigate

Открыть оригинал ↗ Перевод заголовка: 5 основных системных компромиссов, которые должен освоить каждый инженер-бэкенд

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

  1. Соответствие vs. Доступность (CAP-теорема): При сбое сети (P) система выбирает либо сохранение целостности данных (CP), либо доступность (AP). В финансовых системах — CP, в социальных платформах — AP.
  2. Задержка vs. Производительность: Оптимизация через батч-обработку повышает общую производительность, но увеличивает задержку отдельного запроса.
    3.- Нормализация vs. Денормализация: Нормализация обеспечивает целостность, но требует сложных JOIN-запросов; денормализация ускоряет чтение, но вводит риски устаревания данных при обновлении.
  3. Пулл vs. Пуш: Пулл — простой, но с задержкой; пуш (вебсокеты, вебхуки) обеспечивает реальность, но требует управления состоянием и нагрузкой.
  4. Сильная vs. Постепенная согласованность: Сильная согласованность требует глобальной синхронизации (до 100 мс), а постепенная позволяет отвечать мгновенно на локальных узлах, платя за это фоновую синхронизацию.

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

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

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

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

Designing Ticketmaster's Seat Hold: Why the Obvious Lock Breaks at 50K Requests per Second

Открыть оригинал ↗ Перевод заголовка: Проектирование системы "Seat Hold" Ticketmaster: почему очевидная блокировка ломается при 50 тысячах запросов в секунду

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

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

  1. Простая проверка-обновление (check-then-update) имеет риски гонки — два пользователя могут одновременно увидеть сиденье как свободное и забрать его.
  2. Атомарное обновление в базе данных с условием (например, WHERE status = 'AVAILABLE') устраняет гонку, но не решает проблему перегрузки при запросах к одному сегменту сидений.
  3. Redis с командой SET NX EX обеспечивает быструю, самовызывающуюся блокировку, но не является источником истины — в случае сбоя репликации может возникнуть дублирование.
  4. Окончательная продажа должна подтверждаться в базе данных, чтобы избежать дублирования и обеспечить согласованность.
  5. Виртуальный ожидательный зал (waiting room) регулирует поток пользователей, предотвращает "лотерею", снижает нагрузку и защищает от ботов.

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

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

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

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

The New System Design Question in 2026 Interviews: Design an LLM Chat Service

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

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

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

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

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

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

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

System design(Load Balancer)

Открыть оригинал ↗ Перевод заголовка: Системное проектирование (Балансировщик нагрузки)

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

Балансировщик нагрузки стоит между клиентами и серверами и не просто делит трафик поровну — он выбирает, куда направить запрос, учитывая здоровье серверов, их загруженность и текущую производительность. В реальных системах используются алгоритмы, такие как Round Robin, Weighted Round Robin, Least Connections и IP Hash, чтобы оптимизировать распределение.

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

  1. Балансировщик должен постоянно проверять здоровье серверов и автоматически перенаправлять трафик на работающие экземпляры.
  2. Алгоритм распределения трафика должен учитывать не только равномерность, но и реальную нагрузку на серверы.
  3. Важно понимать, что балансировщик не решает все проблемы — он работает в комплексе с авто-масштабированием, кэшированием и мониторингом.
  4. Для приложений с высокой волатильностью трафика (например, магазины, статусы, AI-сервисы) балансировщик становится критически важным.
  5. Правильная настройка балансировщика позволяет избежать сбоев при росте нагрузки и обеспечивает отказоустойчивость.

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

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

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

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

Designing a Production RAG Retrieval System for 500 Million Vectors

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

Для компании Atlas, начавшей с простой системы поиска на 10 миллионов векторов, рост объёма документов и увеличение трафика привели к необходимости масштабирования. Система должна поддерживать 500 миллионов векторов, обеспечивать быструю доступность новых документов, изолировать данные по тенантам и учитывать права доступа. Важно, чтобы качество поиска не падало, а latency не рос из-за снижения recall. В статье описывается эволюция архитектуры от простого хранилища до распределённой системы с разделёнными паттернами ввода и вывода.

  1. Введение шардинга решает проблему хранения: корпора разделяется на части, каждый из которых хранит свой индекс, что позволяет масштабировать систему горизонтально, а не вертикально.
  2. Вводимуемая «мутабельная» структура позволяет новым данным быстро стать доступными без ожидания полной оптимизации индекса, что избегает конфликта между письмом и поиском.
  3. Запросы фильтруются по тенанту и правам доступа на ранних этапах, что исключает ненужные поиски в несуществующих или запрещённых данных.
  4. Вводится агрегатор результатов, который объединяет локальные кандидаты из разных шардов, обеспечивая глобальную сортировку и качество ответа.
  5. Внедрение WAL (Write-Ahead Log), реплик и контроля за индексацией предотвращает перегрузку и обеспечивает отказоустойчивость при сбоях.

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

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

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

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

Hibernate vs MyBatis: How Much ORM Magic Do You Actually Want?

Открыть оригинал ↗ Перевод заголовка: Хибернейт против МайБэйтс: сколько волшебства ORM тебе действительно нужно?

Причина сбоя в производственной среде — не сложный алгоритм, а простое обращение к связанному объекту в цикле. Hibernate автоматически запускает запросы при доступе к связанным объектам, что приводит к проблеме N+1, даже если код выглядит простым. Разница между Hibernate и MyBatis не в том, какой из них лучше, а в степени контроля над SQL: Hibernate скрывает сложность, обеспечивая продуктивность при работе с объектами; MyBatis требует написания SQL вручную, но даёт прозрачность и точный контроль над запросами. Несмотря на разные подходы, оба инструмента не решают проблему базы данных — эффективность зависит от индексов, структуры запросов и оптимизации на уровне СУБД.

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

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

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

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

final quality gate

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

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

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

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

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

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

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

Step 4 — Project Architecture Aggregation

Открыть оригинал ↗ Перевод заголовка: Шаг 4 — агрегация проектной архитектуры

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

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

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

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

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

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

DesignGurus

AI Agents Are Distributed Systems: 8 Patterns Every Engineer Should Know

Открыть оригинал ↗ Перевод заголовка: AI-агенты — это распределённые системы: 8 паттернов, которые должен знать каждый инженер

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

  1. Повторные попытки с экспоненциальным ожиданием и джиттером предотвращают перегрузку API при временных сбоях, но требуют точного выбора ошибок для повтора (например, 429, 5xx, но не 400).
  2. Идемпотентные вызовы инструментов с ключами, построенных из идентификатора запуска и шага, избегают повторных действий, но требуют, чтобы ключи сохранялись дольше, чем длится сам запуск.
  3. Саги с компенсирующими действиями позволяют отменять действия при сбоях, но не работают с необратимыми операциями (например, отправка писем), которые должны быть в конце и с подтверждением.
  4. Очереди и бюджеты токенов предотвращают перегрузку и избыточные расходы, но требуют точного планирования нагрузки и контроля за временем выполнения.
  5. Распределённое отслеживание даёт видимость потока выполнения, но не решает проблему нестабильности в логах или несогласованности между сервисами.

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

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

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

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

The System Design Newsletter

How Vector Database Search Billions of Vectors in Milliseconds

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

Для поиска по миллионам или миллиардам векторов в реальном времени, не требуется сравнивать каждый элемент — достаточно построить структуру, которая направляет поиск к наиболее схожим результатам. Алгоритм HNSW (Hierarchical Navigable Small World) использует иерархические графы, где на верхних уровнях есть короткие «переходы» к крупным областям, а на нижних — точный локальный поиск. Это позволяет избежать полного перебора, сохраняя при этом высокую точность. Ключевые параметры — M (количество соединений на узле), efConstruction (качество построения графа) и efSearch (глубина поиска) — позволяют настраивать баланс между скоростью, точностью и потреблением памяти. При этом HNSW требует значительного объёма памяти и не подходит для систем с частыми обновлениями или когда требуется точный поиск.

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

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

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

  1. Как изменится производительность HNSW при переходе от efSearch=50 к efSearch=200, если в системе уже есть миллиард векторов и память фиксирована?
  2. В каких сценариях может привести к сбоям использование HNSW при постоянных добавлениях новых векторов, если не учитывать перестройку графа?
  3. Какой компромисс между точностью и скоростью будет наилучшим при поиске векторов в RAG-системе, где требуются высокие значения recall@k, но задержка не должна превышать 10 мс?

Coding / Algorithms

React Java

I Found 5 Best Coding Interview Courses on Udemy and they are Awesome

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

В статье автор представляет список из шести курсов на платформе Udemy, ориентированных на подготовку к техническим собеседованиям. Все курсы посвящены дескриптивным структурам и алгоритмам, с акцентом на практику решения задач в условиях реального интервью, включая типичные вопросы от компаний FAANG. Курсы разработаны экспертами (в том числе из Google), включают в себя не только теорию, но и визуализацию, практические упражнения и анализ сложности решений. Автор подчёркивает, что такие курсы подходят как новичкам, так и опытным разработчикам, которые потеряли связь с базовыми навыками. Особенно выделяется курс Andrei Negaoie, сочетающий всестороннюю структуру, поддержку в негативных условиях и советы по переговорам о зарплате.

  1. Курс Master the Coding Interview: Data Structures + Algorithms — наиболее всесторонний и обширный, включает 19,5 часов занятий, охватывает все ключевые темы DSA и реальные вопросы FAANG.
  2. Java Data Structures & Algorithms + LEETCODE Exercises — идеален для Java-разработчиков, включает 100+ задач и анимации для понимания сложных структур.
  3. The Coding Interview Bootcamp: Algorithms + Data Structures — краткий и эффективный для веб-разработчиков, с фокусом на JavaScript и решении задач.
  4. LEETCODE In Python: Algorithms Coding Interview Questions — подходит для Python-разработчиков, включает 29 часов и популярные паттерны решений.
  5. Data Structures Algorithm DSA | Python + JavaScript LEETCODE — структурированный 25-дневный буст-курс с реальными задачами от Google, Meta и Amazon.
  6. JavaScript Algorithms and Data Structures Masterclass — базовый, но полезный для новичков и опытных разработчиков, включает реализацию 10+ структур с нуля.

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

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

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

  1. В чём заключается компромисс между глубиной охвата DSA и доступностью курса для новичков, если, например, в курсе Data Structures Algorithm DSA | Python + JavaScript LEETCODE используется 25-дневный формат?
  2. Какова вероятность, что курс Java Data Structures & Algorithms + LEETCODE Exercises будет неэффективен для разработчиков, не имеющих базового опыта работы с Java, и как это может повлиять на его применимость в реальных условиях?
  3. При каких условиях (по сложности задач, времени на обучение, уровне опыта разработчика) курс Master the Coding Interview может быть неэффективным по сравнению с другими, особенно для тех, кто уже имеет опыт в решении задач на LeetCode?