Risk Management

arXiv Quantitative Finance - Pricing

Uncertainty and Explainability in Deep Rough Volatility: A Neural Information-Theoretic Posterior Approach

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

Статья предлагает новый подход к калибровке сложных моделей волатильности, основанный на постериорной оценке параметров через нейронные сети. Вместо простой точечной калибровки, метод учитывает неопределённость параметров модели, используя симуляцию и нейронные оценки соотношений. Результаты позволяют получить распределения цен с учётом неопределённости как в параметрах модели, так и в суррогатных оценках цен на сложные опционы. Внедрение метода Hellinger-SHAP обеспечивает объяснимость: он показывает, в каких зонах (по сроку и монетности) наблюдается наибольшее увеличение информации о параметрах модели после калибровки.

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

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

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

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

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

Multiple Stopping and Exercise Boundaries for American Put Options

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

Статья рассматривает американский опцион на покупку с возможностью исполнения до m раз в течение ограниченного времени, при условии, что между последовательными исполнениями должен пройти заданный интервал времени δ > 0, а неиспользованные права могут истечь. Авторы доказывают, что оптимальная стратегия исполнения определяется единственной границей и что эти границы упорядочены по количеству оставшихся прав. В работе также приводятся теоретические инструменты: уравнения вида квази-вариационного неравенства, формулировка свободной границы, представление премии раннего исполнения и рекурсивные интегральные уравнения, а также теорема верификации. Работа расширяет модель на случай независимого случайного завершения контракта.

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

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

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

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

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

arXiv Quantitative Finance - Risk Management

A General Framework for Importance Sampling with Markov Random Walks

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

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

  1. Фреймворк использует функцию связи, выбираемую из локально асимптотически нормальной семьи, что позволяет достичь минимума дисперсии оценки без прямого вычисления собственных значений — это критически важно для моделей с высокой нелинейностью.
  2. Метод работает вне рамок классических подходов на основе экспоненциального наклона, что делает его применимым к задачам с нелинейными зависимостями, например, в финансовых моделях с динамическими системными рисками.
  3. Доказано, что оценка обладает логарифмической эффективностью, что означает, что она достигает предельной точности при росте объема данных, что критично для рискового анализа.
  4. Применение к CoVaR и моделям пандемий показывает, что метод может решать задачи, ранее не поддающиеся традиционным методам важности выборки.

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

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

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

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

AI

Habr AI

Длинный контекст в open‑source моделях 2026 и обвязка под него

Открыть оригинал ↗ Перевод заголовка: Длинный контекст в open‑source моделях 2026 и обвязка под него

В статье раскрывается реальная картина того, как современные open‑source модели с «1 млн контекста» на практике читают историю — выборочно, а не полностью. Модели не воспринимают весь контекст как единое целое: большинство из них используют разрежённое внимание, сжатие кеша или скользящие окна, и качество их восприятия плавно снижается с ростом длины сессии. Важно понимать, что «1 млн токенов» — это лишь размер входа, а не гарантия полного внимания к каждому токену. Для агентов это означает, что правила, инструкции и запреты могут потерять вес к середине сессии, особенно если они не фиксируются в хвосте или не переносятся в структурированные сущности вне окна.

  1. Контекст читается выборочно: модели не смотрят на всё, а отбирают релевантные части через top-k или сжатие, и старые элементы часто теряются в сжатии или в середине истории.
  2. Хвост контекста (последние сотни токенов) всегда доступен, но для середины истории требуется активное вмешательство обвязки — например, через хуки или файлы прогресса.
  3. Компактизация может быть эффективнее полного окна: в некоторых случаях (Kimi K3, GLM-5.1) она улучшает результаты, потому что уменьшает шум и двойники.
  4. Правила и инструкции должны быть в хвосте, а не в начале или в выводах инструментов — иначе они теряют вес и не срабатывают на поздних шагах.
  5. Обвязка должна фокусироваться не на содержимом, а на том, куда и как положить текст — например, через поисковые запросы, чистку старых выводов или субагенты, которые возвращают адреса, а не пересказы.

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

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

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

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

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

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

При запросах на английском языке о российских брендах нейросети почти не используют русскоязычные источники, в то время как на русском языке — русские сайты в ответах доминируют. В Google AI Overviews и Perplexity русские домены (ru, рф, su) в ответах на английские вопросы отсутствуют или крайне редки, несмотря на настройки региона в российской зоне. Алиса AI является исключением: она сохраняет ссылки на русские сайты даже при английских запросах, что делает её более прозрачной для российских брендов. Анализ показал, что русские сайты в ответах на английские вопросы не просто "не видны", а систематически заменяются англоязычными площадками (Reddit, YouTube, Wikipedia). Различие в поведении моделей подчёркивает, что видимость в нейросетях зависит не только от языка сайта, но и от языка запроса, а также от архитектуры поискового пула.

  1. При английских запросах нейросети (Google AI Overviews, Perplexity) почти не используют русскоязычные источники, даже при наличии российского региона в настройках.
  2. Алиса AI сохраняет русские ссылки в ответах на английские вопросы, что делает её более подходящей для брендов с русскоязычным контентом.
  3. Видимость русских сайтов в англоязычных ответах зависит не от языка сайта, а от языка запроса и тематики, что требует отдельного продвижения на англоязычных площадках.
  4. Сравнение ответов на русском и английском языках показывает, что общие источники между языками редки, что указывает на отсутствие синхронизации в поисковых пулах.
  5. Оценка видимости в нейросетях должна включать проверку языка запроса и доменов источников, иначе может быть искажён вывод о реальной доступности контента.

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

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

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

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

Код-ревью в эпоху ИИ: как агенты меняют проверку кода

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

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

  1. Агенты значительно увеличивают объём PR, что вынуждает ревьюеров пересматривать приоритеты и фокусироваться на ключевых архитектурных и доменных изменениях.
  2. Безопасность генерированного кода остаётся слабой — в среднем 56% сценариев проходят проверку на уязвимости, что требует дополнительных ручных проверок.
  3. Машинный первый круг не заменяет функции ревью как канала передачи знаний: агенты почти не обсуждают контекст и не передают опыт, в то время как люди делают это в 5–6 раз чаще.
  4. Поведение ревьюеров меняется: они реже оставляют комментарии и одобряют PR быстрее, что может свидетельствовать о привыкании, а не о повышении качества.
  5. Нет доказательств, что ревью после мерджа ухудшается, но отсутствуют данные о долгосрочной передаче знаний и влиянии на рост junior-инженеров.

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

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

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

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

Как мы научили ИИ‑агента не выдумывать цифры в отчётах

Открыть оригинал ↗ Перевод заголовка: Как мы научили ИИ-агента не выдумывать цифры в отчётах

В корпоративном ИИ-агенте KW-7 AI была разработана система, которая предотвращает выдумывание цифровых данных в отчётах, перенося ответственность за достоверность с модели на систему. Вместо того чтобы модели памятью запоминать и пересказывать прочитанные данные, система вводит «журнал фактов» — отдельный ресурс, где каждая цифра сопровождается дословной цитатой из источника и проверяется в момент записи. Это позволяет избежать ошибок, связанных с потерей контекста или перепутанными источниками, и делает отчёт прозрачным и проверяемым.

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

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

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

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

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

Hugging Face Blog

Turning Database Grading into RL Rewards: Post-Training Agents with ThinkingBox

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

Авторы разработали ThinkingBox как инструмент для проверки работы агентов посредством сравнения конечного состояния базы данных с ожидаемым результатом. Используя этот же исполняемый сигнал как вознаграждение, они применили его к задачам вне рамок ThinkingBox-Bench, что привело к росту среднего успеха с 51,70% до 60,78% и увеличению числа задач, решённых на всех 20 попытках, с 38 до 107. Ключевым инновационным подходом стало использование офлайн-политики-связанной сложности, при котором задачи отбираются на основе вероятности успеха при базовой политике, что позволяет избежать обучения на уже решённых или бесполезных задачах.

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

  • Оценка сложности задач проводится офлайн с помощью базовой модели, чтобы избежать динамического пересмотра сложности во время обучения.
  • Задачи с низкой вероятностью успеха (в диапазоне 0.08–0.40) и средней (0.40–0.60) включаются в обучение, так как они обеспечивают контраст в результатах.
  • Результаты обучения показывают рост повторяемости (pass@20 с 38 до 107), что критично для производственной надёжности, хотя при этом уменьшается покрытие задач (pass@20 уменьшилось в некоторых доменах).
  • Важно проверять единообразие интерпретации выводов модели между обучением и оценкой, иначе возникает диссонанс между обучением и реальными результатами.
  • Используемый сигнал — не текстовая оценка, а исполняемый контроль за конечным состоянием базы данных, что делает его более объективным и технически надёжным.

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

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

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

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

InfoQ Architecture

Presentation: Actors for Agents: Patterns for Production AI

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

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

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

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

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

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

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

Study Finds AI-generated Code Fails to Boost Productivity Due to Downstream Bottlenecks

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

Новое исследование из Гарварда, охватывающее 718 компаний, выявило, что хотя ИИ-ассистенты и агенты увеличивают объём кода, это не приводит к росту выполненных задач — особенно в процессе код-ревью. Хотя агенты значительно повышают количество коммитов и запросов на слияние (PR), их эффективность в решении задач (Jira-исполнений) остаётся низкой, что указывает на то, что рост в коде не сопровождается ростом качества или скорости доставки. Основной проблемой выступают этапы после написания кода: ревью, тестирование и деплой, где рост нагрузки на разработчиков превышает выигрыш в написании кода. Увеличение количества комментариев в PR на 53% и рост времени ревью на 49% свидетельствует о том, что ИИ-генерированный код создаёт дополнительные трудности в поддержке и понимании.

  • ИИ-ассистенты увеличивают объём кода на 12%, а агенты — на 30%, но не повышают количество решённых задач.
  • Время и усилия на ревью кода выросли в 1,5–2 раза, что делает процесс более тяжёлым для разработчиков.
  • Увеличение количества комментариев и изменений в PR не объясняется ростом размера PR, что указывает на низкое качество генерируемого кода.
  • Риск «халлюцинаций» ИИ, особенно у агентов, может привести к ошибкам, которые трудно обнаружить и исправить.
  • При росте объёма кода без роста понимания и контроля риски сбоев и сложности восстановления увеличиваются.

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

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

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

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

Article: AI Changes the Data Interface, Not the Query Engine

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

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

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

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

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

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

Developer Behind the AI-Built Adobe Clones Says They Are “Not Anywhere Close to Ready

Открыть оригинал ↗ Перевод заголовка: Развившийся AI-проект по созданию открытых аналогов Adobe говорит, что продукты не готовы к использованию.

Разработчик Брандон Томас, создавший на основе ИИ семи открытых аналогов приложений Adobe, подчеркнул, что продукты на стадии бета-тестирования и далеки от готовности к реальным задачам. В проекте PhotoCraft, реализованном на Rust и с использованием WebAssembly, достигнуты 76% по охвату функций, но лишь 45% — по готовности к практическому использованию. Оценка сложности реализации указывает на потребность в 1,100–1,800 часов работы для бета-версии и 2,300–4,100 часов для полной совместимости. Критика в сообществе подчёркивает нестабильность интерфейса, отсутствие поддержки RAW-файлов и проблемы с обработкой изображений, в то время как некоторые компоненты, как PDFCraft, работают без ошибок.

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

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

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

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

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

Latent Space

Why AI Compute Comes in Rectangles — Erik Bernhardsson, Modal CEO

Открыть оригинал ↗ Перевод заголовка: Почему вычисления для ИИ приходят в прямоугольники — Эрик Бернхардссон, CEO Modal

Традиционные контракты на вычислительные ресурсы описывают потребность в виде прямоугольника — фиксированное количество GPU на фиксированный период. Однако реальные нагрузки в ИИ динамичны: они растут, пикуют и падают, что делает прямоугольные контракты неэффективными. Modal предлагает альтернативу — преобразование временного спектра запросов: объединяя спрос тысяч пользователей, компания создаёт гладкую, стабильную нагрузку, позволяя каждому клиенту использовать ресурсы в нужный момент. Это решает проблему несоответствия между жесткими контрактами и гибкими реальными рабочими процессами.

  1. Прямоугольные контракты (фиксированные объёмы на фиксированный срок) не отражают реальную динамику нагрузки — ИИ-задачи пикуют и падают, что делает такие контракты избыточными или рискованными.
  2. Modal решает проблему через «преобразование длительности»: объединяет спрос множества пользователей, создаёт стабильную нагрузку и позволяет каждому использовать ресурсы по мере необходимости.
  3. Ключевым инфраструктурным элементом является быстрый запуск среды — через буфер доступных GPU, кэширование состояния и снимки памяти, что снижает задержку при запуске и восстановлении агентов.
  4. Рост спроса на «сандбоксы» (временные среды для запуска моделей) превысил ожидания — они теперь составляют около трети выручки, что подтверждает важность гибкого, агент-ориентированного подхода к инфраструктуре.
  5. Компания оценивает риски, связанные с падением цен на GPU: если цена упадёт, поставщик может быть «закреплён» за дорогим запасом, что требует стратегического планирования.

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

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

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

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

Java / Spring

Foojay

OWASP Java Security Libraries: Please Update!

Открыть оригинал ↗ Перевод заголовка: Обновите OWASP Java Security Libraries!

Две популярные библиотеки по безопасности в Java — OWASP Java Encoder и OWASP Java HTML Sanitizer — получили обновления до версий 1.6.0 и 20261011.1 соответственно. В них исправлены критические уязвимости, связанные с обработкой вставок в HTML и парсингом CSS, а также улучшена стабильность при работе с Java 8 и выше. Важно использовать правильный контекст при кодировании (например, HTML-текст vs. атрибуты), избегать двойного обработки и не применять обработку к вводу, который не предназначен для HTML.

  1. При использовании OWASP Java Encoder важно учитывать контекст вывода: для текста внутри элемента HTML использовать forHtmlContent, для атрибутов — forHtmlAttribute, чтобы избежать XSS-атак.
  2. В версии 1.6.0 улучшена обработка JavaScript-кодов, но при этом могут изменяться байтовые выходные данные — тесты с прямым сравнением строк требуют проверки на корректность.
  3. Для JSP-приложений необходимо использовать соответствующий адаптер (для Jakarta или javax), а адаптер encoder-esapi устарел и больше не поддерживается.
  4. OWASP Java HTML Sanitizer позволяет настраивать политики, разрешающие только нужные HTML-элементы (например, <p>, <strong>, <em>), удаляя вредоносные конструкции, включая скрипты и изображения.
  5. При обновлении важно проверять не только безопасность, но и корректность отображения легитимного контента, а также тестировать на реальных вводах и вредоносных примерах, особенно при наличии вложенных CSS-функций.

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

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

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

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

How to Secure a Spring Boot Application with OpenID Connect and pac4j

Открыть оригинал ↗ Перевод заголовка: Как защищать приложение Spring Boot с помощью OpenID Connect и pac4j

Приложение на Java может быть безопасно защищено с помощью OpenID Connect (OIDC), позволяя пользователям входить через существующие аккаунты в таких провайдерах, как Keycloak, Google или Azure AD. pac4j — это библиотека для аутентификации и авторизации, которая поддерживает OIDC и интегрируется с Spring Boot, обеспечивая простую настройку аутентификации через стандартные протоколы. В статье описано пошаговое создание проекта, настройка OIDC-клиента, регистрация приложения у провайдера и получение профиля пользователя через ID-токен. Также показано, как реализовать выход из системы — как локальный, так и централизованный, при котором пользователь выходит одновременно у провайдера.

  1. Использовать pac4j-модуль OIDC для работы с OpenID Connect, включая поддержку стандартных провайдеров через специализированные клиенты (Keycloak, Google, Azure AD).
  2. Настроить OIDC-клиент через discovery URI, указав клиентский ID и секрет, полученные при регистрации в провайдере.
  3. Включить защиту определённых путей (например, /protected/**) с помощью интерсептора, который перенаправляет неавторизованных пользователей на провайдера.
  4. Получить данные пользователя через ProfileManager, извлекая стандартные поля (email, имя) и токены из ID-токена.
  5. Включить централизованный выход, указав в конфигурации URL для перенаправления после выхода, и проверить, что он разрешён у провайдера.

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

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

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

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

Habr Java

ИИ‑агент захватил штурвал моего пет‑проекта. Возвращаю его с помощью интерактивных объяснений и двух промптов

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

Разработчик в процессе пет-проекта с ИИ-агентом (Claude Code) столкнулся с когнитивным долгом — потерей понимания кода из-за быстрой генерации и отсутствия вовлечённости. Хотя тесты остаются зелёными, система становится непонятной, а агент превращается в «пилота», который не поддаётся контролю. Автор использует два промпта: линейный разбор кода и интерактивную анимацию, чтобы восстановить понимание архитектуры и выявить скрытые ошибки, включая неправильную обработку ошибок и отсутствие тестов на реальные сценарии.

  1. Промпт для линейного разбора требует вставки кода через команды (grep, sed, cat), что делает объяснения проверяемыми и предотвращает фантазии агента.
  2. Анимация визуализирует асинхронный поток выполнения — от запроса до ошибки, таймаута и повтора — с пошаговым режимом и переключателем сценариев.
  3. Разбор выявил, что фейковый клиент проходит тесты, но не работает с настоящим API, а ошибка в поллере обрывает обработку всех видео, оставляя их в статусе «в очереди».
  4. Несмотря на наличие документации, код не реализует сценарий переключения «сироты» в «failed», что приводит к ухудшению пользовательского опыта.
  5. Важно, что текстовый разбор показывает, что сломано, а анимация — как система живёт в реальности, что позволяет удержать в голове полный путь выполнения.

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

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

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

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

Как легко открыть запущенный локально сервис на телефоне и почему меня это выбесило

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

Автор описывает простой способ открыть локальный сервис (например, Spring Boot) на телефоне через сеть: подключение к одному Wi-Fi, определение локального IP через командную строку и ручной перебор адресов. Однако при динамическом IP-адресе, который меняется при каждом подключении, такой подход становится неудобным и повторяющимся. Чтобы решить проблему, автор создал мобильное приложение, которое автоматически сканирует локальную сеть, ищет открытый порт (например, 8080), проверяет наличие HTTP/HTTPS-сервера и отображает найденный адрес. Приложение работает без необходимости вручную искать IP, поддерживает самоподписанные сертификаты и остаётся актуальным до смены IP.

  1. Приложение автоматически определяет сеть и перебирает IP-адреса в диапазоне (например, 192.168.1.1 до 192.168.1.254).
  2. Проверка порта выполняется параллельно с короткими таймаутами, что делает процесс быстрым и не зависящим от последовательного сканирования.
  3. Приложение идентифицирует сервер по HTTP-ответу, даже если используется самоподписанный сертификат.
  4. После нахождения адреса он отображается в приложении и остаётся актуальным до смены IP.
  5. Решение реализовано на Java, использует стандартные сетевые API (например, Socket, HttpURLConnection), и доступно в Google Play без рекламы.

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

Материал полезен для разработчиков, которые часто запускают локальные сервисы (Spring Boot, React и т.п.) и хотят быстро открыть их на мобильных устройствах без ручного поиска IP-адресов, особенно в условиях динамического интернет-подключения.

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

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

System Design

ByteByteGo

Why Distributed Systems Prefer Independence over Coordination

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

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

  1. Координация увеличивает риск сбоев: если один компонент не отвечает, другие могут зависнуть, что приводит к нестабильности.
  2. Независимые компоненты могут работать параллельно и масштабироваться отдельно, что улучшает производительность и отказоустойчивость.
  3. Механизмы, такие как события (events) или асинхронные сообщения, позволяют избежать прямого ожидания и снизить нагрузку на координацию.
  4. Стратегии, включающие повторные попытки, таймауты и логирование, помогают смягчить последствия неудачных координаций.
  5. Использование API, таких как gRPC или HTTP/2, с асинхронными вызовами позволяет минимизировать блокирующие операции.

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

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

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

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

Cloudflare Blog

Localizing compliance at scale: achieving South Korea’s ISMS certification

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

Для получения сертификации по системе управления информационной безопасностью (ISMS) в Южной Корее Cloudflare прошёл 10-дневный аудит, в ходе которого 80 контрольных пунктов были проверены независимыми аудиторами из Корейского агентства по интернету и безопасности (KISA). Сертификация не просто формально подтверждает наличие политик — она требует глубокого понимания корейского законодательства, языка и ожиданий регуляторов, что отражается в поведении продукта.

  1. В процессе регистрации пользователи из Кореи видят разбитую форму согласия с четырьмя пунктами, три из которых обязательны — это "жёсткие двери", которые блокируют создание аккаунта без явного согласия.
  2. Для пользователей, которые регистрируются через Google, Apple или GitHub, согласие не может быть собрано на стороне Cloudflare, поэтому в Корее отключена социальная аутентификация, чтобы все регистрации проходили через форму с обязательными пунктами.
  3. Определение страны происходит по IP-адресу, но пользователь может выбрать страну вручную — именно это делает согласие реальным и не предполагаемым, а не зависящим только от геолокации.
  4. Сертификация ISMS не заменяет ISO-стандарты, а дополняет их, требуя детализированных диаграмм данных и прозрачности в формулировках согласия, что делает аудит более глубоким.
  5. Охват сертификации определяется не списком продуктов, а границами сервиса — если продукт работает на сертифицированной инфраструктуре и управляет теми же командами, он входит в охват, независимо от названия.

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

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

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

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

DEV System Design

System design capstone and final assessment

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

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

  1. При расчёте объёма хранения важно учитывать не только размер данных, но и их частоту и повторность (например, 50 млн пользователей × 2 фото × 3 МБ = 300 ТБ).
  2. Для поддержки согласованности в распределённых системах без транзакций используется паттерн "сага с компенсационными действиями", а не блокировки или бесконечные повторы.
  3. Паттерн "outbox" обеспечивает одновременную запись в БД и публикацию события, что гарантирует согласованность при отказе одного из шагов.
  4. Дублирование сообщений из-за переподключения клиентов устраняется с помощью уникального идентификатора сообщения, а не по времени или таймауту.
  5. Проблемы с кэшированием, перегрузкой партиций и несогласованностью требуют не просто масштабирования, а переопределения ключей или архитектурных границ.

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

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

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

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

System design case study: WhatsApp

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

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

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

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

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

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

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

Staff-Level System Design Interviews: What Changes From Senior, and How I'd Prepare

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

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

  1. Важно не просто назвать инструмент, а объяснить, почему именно он подходит, с анализом затрат и ограничений (например, почему логи вместо Kafka — из-за необходимости перепроигрывания и последовательности).
  2. Нужно уметь оценивать не только масштаб, но и операционные аспекты: как реагировать на пик нагрузки, как выглядит панель наставника, как работает backpressure.
  3. На уровне ставшего специалиста важно не просто отвечать, а вести диалог: сначала сформулировать границы задачи, затем предложить компромиссы, а не ждать, что спросят.

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

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

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

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

System design case study: Stripe and payment systems

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

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

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

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

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

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

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

System design case study: YouTube

Открыть оригинал ↗ Перевод заголовка: Системный дизайн: кейс-стади YouTube

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

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

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

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

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

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

A visible draft is not yet a stored request

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

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

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

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

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

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

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

Here is the question I try to ask before I commit to a design: if I'm still on call for this in

Открыть оригинал ↗ Перевод заголовка: Вот вопрос, который я пытаюсь задать перед тем, как принять какой-либо дизайн: если через три года я всё ещё в режиме «на связи» по этому вопросу и должен объяснить его новому сотруднику в первый день работы — это всё ещё правильный выбор?

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

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

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

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

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

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

Microservices.io

Architecting for uncertainty - part 5: DevOps defines how a fast-flow organization works

Открыть оригинал ↗ Перевод заголовка: Архитектура для неопределённости — часть 5: DevOps определяет, как работает организация с быстрым потоком

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

  1. DevOps — это не просто инструментальная цепочка, а модель взаимодействия между командами разработки и операционных процессов, обеспечивающая непрерывность и прозрачность.
  2. Ключевые практики, такие как CI/CD, observability и экспериментирование, позволяют быстро реагировать на изменения и снижают риски при развертывании.
  3. В условиях неопределённости DevOps создаёт среду, где можно безопасно проводить эксперименты, быстро исправлять сбои и адаптироваться к изменениям.

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

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

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

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

Coding / Algorithms

LeetCode.ca Solutions

4046 - Minimum Cost Path With At Most K Turns

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

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

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

  1. Состояние в динамическом программировании должно включать позицию (i, j), направление входа (вверх, вниз, влево, вправо) и количество уже использованных поворотов.
  2. Используется алгоритм Dijkstra или динамическое программирование с оценкой стоимости, так как все стоимости ячеек неотрицательны.
  3. Минимальная стоимость ответа — это наименьшее значение среди всех возможных путей с 0 до k поворотов, достигающих конечной точки.
  4. Если ни один путь с не более чем k поворотами не достигает конца, возвращается -1.
  5. Ограничение k < min(m, n) означает, что при k = 0 путь может быть невозможен, если сетка не является прямоугольной или слишком узкой.

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

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

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

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