Инженерный дайджест — 2026-10-12

Risk Management

Financial Stability Board

Global stablecoin arrangements: Cross-border vulnerabilities and financial stability monitoring

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

Глобальные стабильные криптовалюты функционируют на межгосударственном уровне и могут стать системно значимыми в нескольких юрисдикциях, что затрудняет оценку рисков одной страной. Их операции охватывают разные юридические структуры и подпадают под контроль нескольких национальных регуляторов, что усложняет мониторинг и регулирование. В отчёте Финансового совета по стабильности (FSB) представлены ключевые аспекты мониторинга: структура таких криптовалют, пути распространения уязвимостей и показатели для оценки стабильности. Также анализируются доступные данные, включая их источники, достоинства и ограничения.

Глобальные стабильные криптовалюты могут создавать системные риски за счёт межгосударственной природы своих операций и распределения ответственности между регуляторами.
Уязвимости в одной юрисдикции могут быстро распространяться через глобальные сети, что требует координации между регуляторами и единого подхода к мониторингу.
Показатели, такие как объём транзакций, динамика резервов и прозрачность цепочек поставок, могут быть использованы для раннего выявления рисков.
Данные о стабильных криптовалютах часто недостаточны или неструктурированы, что снижает надёжность мониторинга и требует улучшения стандартов сбора информации.
Несмотря на наличие глобальной рамочной политики (FSB Crypto Framework), существуют разрывы в её внедрении между странами, что угрожает эффективности мониторинга.

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

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

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

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

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

Какие альтернативные источники данных могут быть использованы для компенсации существующих пробелов в прозрачности стабильных криптовалют?

arXiv Quantitative Finance - Pricing

FOMO: FLEX Options and Market Outcomes

Открыть оригинал ↗ Перевод заголовка: FOMO: Флекс-опционы и их влияние на рынок

Статья исследует, оставляют ли сделки с флекс-опциями (FLEX options) заметные следы в стандартных рынках опционах и акциях. Авторы анализируют данные за 250 торговых дней по 41 акции и 53 событиям, выявляя три ключевых эффекта: рост открытия опционов после событий, сильная связь между активностью FLEX и средними значениями волатильности, а также предсказание возвратов на коротких сроках по разнице между волатильностью и реальными волатильностями. В целом, FLEX-активность выступает как индикатор спроса институциональных участников на волатильность, а не как предиктор направления возвратов акций.

FLEX-активность приводит к значительному росту открытия стандартных опционов (показатель β = 0.3061), что свидетельствует о прямом влиянии на рынок, несмотря на отсутствие прямой связи с возвратами акций.
Активность сосредоточена в средних ценовых зонах и в условиях высокой волатильности, что указывает на выбор институциональных игроков в определённых рыночных условиях.
Разница между имплицитной и реальной волатильностью предсказывает возвраты на коротких сроках, особенно при выполнении коротких страдлов, что может быть использовано для оценки рыночного напряжения.

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

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

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

В каких условиях FLEX-активность может быть интерпретирована как сигнал о потенциальном росте волатильности, а не как просто отражение текущего спроса?

Какова граница применимости эффекта волатильности-разницы (IV–RV) для предсказания возвратов, если волатильность нестабильна или не поддаётся моделированию?

В каких сценариях FLEX-опционы могут привести к артефактам в открытии стандартных опционов, и как это может повлиять на оценку рыночной структуры?

arXiv Quantitative Finance - Risk Management

A Distributional Framework for Behavioral Characterization and Risk Management of Large Language Models

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

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

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

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

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

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

Какова сложность вычислительной нагрузки при симуляции распределений ответов для моделей с большим объёмом текста и высокой вариативностью ответов?

В каких условиях распределение ответов может стать нестабильным, и как это может повлиять на оценку рисков в реальных сценариях?

Какие ограничения могут возникнуть при применении этого подхода к моделям с низкой диверсификацией ответов или с высокой зависимостью от контекста?

Enhancing credit risk scorecards with transactional-based behavioural features

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

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

Разработка регулярного выражения для автоматической классификации описаний транзакций позволяет извлекать поведенческие признаки (например, «закупка сырья», «оплата аренды») без необходимости вручную разметке данных.
Полученные признаки, такие как частота, сегментация расходов и временные паттерны, вносят значимый вклад в прогнозирование вероятности дефолта, превосходя традиционные агрегированные метрики.
Методология обеспечивает прозрачность и объяснимость моделей, что критично для регуляторных требований и внутреннего принятия решений в финансовых учреждениях.
Применение работает на реальных данных крупной финансовой институции в Южной Африке, что подтверждает его практическую применимость в условиях реального бизнеса.
Предложенная архитектура может быть адаптирована к другим секторам (например, потребительские кредиты) и к другим типам данных (например, чеки, SMS-платежи).

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

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

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

Какова оценка устойчивости и масштабируемости регулярного выражения при работе с разнообразными языками и стилями описаний транзакций в разных регионах?

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

Какова сложность вычислительной реализации и время обработки признаков в реальном времени при работе с большими объёмами данных?

Systemic risk in interbank networks: disentangling balance sheets and network effects

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

Статья исследует, насколько фактический системный риск в сетях банков отличается от риска, который можно оценить исключительно по балансам отдельных банков, игнорируя структуру их взаимных обязательств. Авторы применяют различные модели распространения риска и сравнивают наблюдаемый риск на реальных данных сети e-MID с риском, полученным в «нулевой» модели — симуляции, где балансовые данные сохраняются, а конфигурация взаимных обязательств случайно распределяется. Основной вывод — при нормальных условиях балансовые данные дают достоверную оценку общего риска, но в периоды кризиса (после краха Lehman и внедрения VLTRO) разрыв между наблюдаемым и ожидаемым риском растёт. Важно, что отдельные банки могут быть значительно более или менее уязвимыми, чем их баланс показывает, из-за их позиции в сети.

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

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

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

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

В каких условиях максимальная энтропия может привести к искажению оценки риска, если не учитывать динамику потоков капитала между банками?

Какова граница применимости модели при оценке риска в сетях, где банки имеют несимметричные или нестабильные обязательства?

В каких сценариях балансовая информация может быть надёжной, а в каких — несущественной для оценки системного риска?

Realized Tail-Risk Conditional Autoregressive Expectile Models: Accurate and Stable Forecasting Performance

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

Авторы предложили новую модель RTCARE для одновременного прогнозирования значения риска (VaR) и ожидаемого отклонения (ES). Модель использует реализованные хвостовые меры — такие как реализованный квантиль и реализованный ES — построенные на основе высокочастотных вкладов, чтобы включить информацию о риске в нижнем хвосте в динамические и измерительные уравнения. Прогнозы оцениваются на основе численных примеров и эмпирического анализа данных по волатильности американских акций, где модель показывает конкурентоспособные и часто превосходящие результаты по сравнению с существующими методами, при этом результаты остаются стабильными при многократных повторениях и скользящих прогнозах.

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

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

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

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

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

Какова сложность вычислений при использовании Маркова цепи Монте-Карло для оценки параметров модели в реальном времени на больших объемах данных?

В каких сценариях модель может потерять стабильность при переходе от краткосрочных к долгосрочным горизонтам прогнозирования?

AI

Foojay

Your agents don't need an LLM to negotiate

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

В традиционных агентах переговоры часто происходят внутри языкового моделирования: ситуация описывается в промпте, модель отвечает, и результат парсится. Это работает, но стоит дорого — каждое решение требует сети и траты. Вместо этого существует устаревший, но эффективный протокол — Contract Net, который Agenor реализует в Java. Он позволяет агенту объявить задачу, получить предложения от других агентов, выбрать лучшее и передать выполнение без использования LLM. В примере агенты оценивают задачу по формуле, включающей эффективность и шум, а выбор делается на основе цены. Все взаимодействие строится на стандартных сообщениях (CFP, PROPOSE, REFUSE, AGREE, INFORM, FAILURE), и состояние переговоров управляется как конечный автомат. Каждый агент хранит только свои собственные диалоги, без централизованного реестра, что делает систему гибкой, но неустойчивой к перезапуску. При перезапуске утрачивается история переговоров, и нет уведомлений о потерях.

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

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

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

Какой компромисс между надёжностью и производительностью возникает при использовании Contract Net без централизованного хранения состояния диалогов?

В каких случаях может привести к сбоям отсутствие проверки последовательности сообщений (например, PROPOSE после AGREED), и как это влияет на масштабируемость при работе с децентрализованными агентами?

Как изменится поведение системы при введении валидации содержимого (contentAs) через сериализацию, если агенты работают через транспорт с несовместимой сериализацией?

Habr AI

Еще несколько утилит на Rust: DirMerge, ProcessTree и даже Notepad

Открыть оригинал ↗ Перевод заголовка: Ещё несколько утилит на Rust: DirMerge, ProcessTree и даже Notepad

Автор проводит эксперимент по созданию простых, кроссплатформенных утилит на Rust с помощью LLM, чтобы проверить, способны ли нейросети генерировать рабочий, полезный софт для повседневного использования. Программы — ProcessTree, Notepad и DirMerge — разработаны как легкие, автономные инструменты для macOS (и Windows), работающие без установки, в виде HTML-файлов или PWA, что обеспечивает доступность и безопасность. Все проекты построены на принципе «один файл — работает везде», что делает их особенно удобными для пользователей, которым важны простота и отсутствие зависимостей.

ProcessTree — инструмент для анализа и завершения зависших процессов на macOS, особенно полезен, когда стандартные методы не срабатывают, и требует прав администратора для выполнения.
Notepad — простой текстовый редактор для macOS, заменяющий CotEditor в работе с большими файлами, реализован как HTML-файл с возможностью офлайн-использования.
DirMerge — аналог WinMerge для сравнения папок, реализован в двух версиях: статический HTML-файл и PWA, оба работают офлайн и на всех платформах.
Все утилиты собираются через GitHub Actions, что снижает риски и позволяет использовать их без вмешательства разработчика.
Ключевое преимущество — работа в браузере как в песочнице, что минимизирует риски утечек данных и повреждений системы.

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

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

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

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

Какова вероятность того, что ProcessTree не сработает на системах с нестандартными настройками безопасности или виртуализацией, и как это может повлиять на его надёжность в production-среде?

При каких условиях HTML-версия Notepad может начать замедляться или терять отзывчивость при работе с файлами размером более 10 МБ?

AI за день изменил всю математику, а также чумной вопрос в России: главное за неделю

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

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

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

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

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

В каких условиях ИИ-решение может быть признано достоверным, если оно не подтверждено формализацией в языке доказательств (например, Lean), и как это влияет на доверие к результатам в научных сообществах?

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

Какова сложность и масштабы критической инфраструктуры, которую может нарушить ИИ-агент, и как это может повлиять на политическую и регуляторную реакцию в ближайшие годы?

Можно ли научить маленькую LLM учиться без роста весов? Продолжение: почему повторное обучение упёрлось в потолок

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

Автор проводит эксперимент с небольшой моделью, проверяя, может ли она накапливать знания при повторном обучении без роста размеров. Оказалось, что первый раунд подучивания даёт заметный прирост в правильных ответах, но последующие раунды не приводят к улучшению — рост останавливается на уровне около 59%. Это не доказывает, что модель действительно усвоила содержание, так как эффект может быть лишь адаптацией к формату задач. Важно понимать, что проверка на «пустышке» (неправильных парах) не раскрывает ситуацию с разными типами задач, и дыра в методике остаётся открытым вопросом.

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

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

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

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

Достаточно ли такой пустышки с равными затратами, чтобы честно назвать прирост первого раунда настоящим обучением? Что мы упускаем в списке «держим одинаковым»?

Как закрыть дыру «внутри одного типа задач», не удваивая работу видеокарты?

Встречал ли кто-нибудь такую же картину — «рывок на первом раунде, дальше потолок» — когда одну и ту же небольшую модель подучивают много раз на одном наборе? Это у вас тоже так, или это особенность нашего протокола?

Как экономить токены AI‑агентов при работе с кодовой базой: 5 универсальных паттернов

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

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

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

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

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

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

Как изменится сложность и эффективность паттерна "Progressive Context" при масштабировании проекта с 10 до 100 сервисов?

В каких условиях "golden examples" могут привести к ошибкам, если агент не проверяет их актуальность и не учитывает контекст изменений в архитектуре?

Какой минимальный порог релевантности (по количеству токенов или времени) делает исследование "эксплорационным" и требует его кэширования?

InfoQ Architecture

Context Language Models: Self-Managing Context to Improve Performance and Reduce Compute Costs

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

Нововведение — Context Language Models (CLMs) — позволяет языковым моделям самостоятельно управлять своим контекстом, включая редактирование, сжатие и сохранение информации, что делает их более эффективными и вычислительно экономичными. В отличие от традиционных методов (например, суммирование или выгрузку в внешнюю память), CLMs могут динамически изменять историю диалога, сохраняя важные данные и удаляя ненужное, обучаясь на основе опыта и в рамках текущего диалога.

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

Нулевой запуск — CLM работает без предварительной тренировки, что позволяет быстро внедрить его в задачи, но с ограниченной точностью.
Обучение в контексте — модель учится через естественный язык, адаптируя стратегии по итерациям, что даёт улучшенные результаты при меньших вычислительных затратах.
Обучение с помощью реверс-обучения — модель оптимизирует контекст на основе успешности задачи и эффективности вычислений, достигая значительного роста точности (до 47,6%) при снижении FLOPs на 12%.

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

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

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

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

Какова сложность и масштабируемость подхода CLM при использовании в распределённых агентах, где каждый узел может изменять контекст независимо?

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

Java / Spring

Alexander Obregon

Weekly Recap – October 11th, 2026

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

В прошлой неделе были опубликованы две статьи: одна — о настройке документации API и интерфейса тестирования в Spring Boot с использованием OpenAPI и Swagger UI, другая — о выявлении и удалении дублирующихся записей в SQL с применением функций окон. В первой статье описывается процесс интеграции инструментов для автоматического генерирования документации и валидации запросов, что упрощает разработку и тестирование API. Во второй — подробно разбирается логика работы с дубликатами с помощью оконных функций, позволяя сохранять нужные записи и удалять избыточные, не нарушая целостности данных.

OpenAPI и Swagger UI в Spring Boot позволяют автоматически генерировать документацию API, что упрощает поддержку и интеграцию с клиентами.
Оконные функции в SQL (например, ROW_NUMBER(), RANK()) позволяют идентифицировать дубликаты по критериям и выбрать одну из записей для сохранения.
Важно правильно настроить фильтры и условия в оконных функциях, чтобы избежать удаления нужных данных.
Валидация API через Swagger UI требует тестирования всех маршрутов и параметров для обеспечения надёжности.
При работе с дубликатами в больших объёмах данных необходимо учитывать производительность и риски потери информации.

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

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

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

Какие риски связаны с использованием оконных функций для удаления дубликатов в больших таблицах, если не заданы корректные условия сортировки и фильтрации?

В каких сценариях использование OpenAPI и Swagger UI может привести к ложным ожиданиям разработчиков по поведению API?

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

Engineering With Java

Engineering With Java: Digest #107

Открыть оригинал ↗ Перевод заголовка: Инженерия на Java: Дигест №107

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

В Java класс-лоадеры работают по модели делегации, где родительский лоадер ищет класс сначала в родительской цепочке, что позволяет избежать конфликтов между версиями библиотек и упрощает управление зависимостями.
Интеграция InfluxDB с Java через Eclipse JNoSQL и Jakarta Data позволяет эффективно хранить и запросить временные ряды, сохраняя при этом привычный синтаксис Java-приложений.
Springdoc OpenAPI с аннотациями @Operation и @ApiResponse автоматически генерирует документацию API, что упрощает разработку и тестирование без ручного вмешательства.
Для тестирования Jakarta EE приложений подходы варьируются от быстрых unit-тестов (WeldInitiator) до проверки поведения в реальных условиях (Testcontainers), что позволяет выявлять разные уровни ошибок.
В системах обнаружения мошенничества Kafka Streams обеспечивает быстрые реакции на транзакции, а векторные поисковые методы расширяют возможности выявления аномалий за счёт AI-анализа поведения пользователей.

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

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

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

В каких сценариях использование класс-лоадеров может привести к неожиданным ошибкам, и как можно предотвратить такие ситуации в production-приложениях?

Какой компромисс между производительностью и гибкостью в выборе между OOP и data-oriented подходами проявляется в реальных проектах, особенно при работе с внешними библиотеками?

При каких условиях 50% правил для настройки памяти OpenSearch может быть неэффективным, и как можно адаптировать его под реальные нагрузки с учётом swap-использования?

HowToDoInJava

Dropwizard Health Check: Configuration and Examples

Открыть оригинал ↗ Перевод заголовка: Dropwizard Health Check: Настройка и примеры

Dropwizard Health Check — это класс, наследующий HealthCheck из библиотеки com.codahale.metrics.health, который проверяет работоспособность зависимости приложения, например, базы данных или внешнего API. При каждом вызове эндпоинта /healthcheck на порту администратора запускаются все зарегистрированные проверки, а в конфигурации config.yml через блок health настраивается периодический запуск проверок и их поведение в случае сбоя. Важно, что при сбое любой критической проверки сервис возвращает статус 503, что позволяет системам балансировки нагрузки и Kubernetes удалять неисправные экземпляры из пула. Проверки возвращают либо Result.healthy(), либо Result.unhealthy() с коротким сообщением, не включая исключения или детали, чтобы избежать утечки информации. Для работы с зависимостями используется валидация через простые запросы (например, GET), с настройкой таймаутов, чтобы избежать зависаний.

Проверки работают в двух режимах: на каждом запросе через /healthcheck (админ-порт) и периодически через /health-check (приложение-порт).
Каждая проверка должна возвращать короткое сообщение об ошибке, а не исключение, чтобы не угрожать безопасности и не перегружать мониторинг.
В конфигурации healthChecks можно задать тип (ready/alive), критичность, интервалы проверок и порог сбоев — это позволяет гибко настраивать поведение при сбое.
В Kubernetes важно правильно настроить livenessProbe и readinessProbe: первый должен использовать /health-check?type=alive, второй — /health-check, чтобы избежать циклических перезапусков.
При сбое критической зависимости (например, базы данных) сервис возвращает 503, а при сбое некритической — остаётся в пуле, что позволяет сохранять доступность для независимых запросов.

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

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

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

Какой компромисс между чувствительностью к сбоям и стабильностью сервиса возникает при использовании некритических проверок в Kubernetes, если они не влияют на состояние readiness?

При каких условиях health-check может вести себя нестабильно, если проверка не настроена с правильными таймаутами и failureAttempts?

Как изменится поведение при сбое, если в config.yml отсутствует блок healthChecks, но есть проверка в коде — будет ли она влиять на /health-check?

Dropwizard Client: JerseyClientBuilder and HttpClient Examples

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

Dropwizard предоставляет два варианта HTTP-клиентов — на базе Jersey и Apache HttpClient — которые настраиваются из файла config.yml и интегрируются в жизненный цикл приложения. Клиенты автоматически управляют таймаутами, пулями соединений, повторными попытками и метриками, что позволяет избежать утечек ресурсов и устойчиво реагировать на сбои зависимостей. Важно использовать отдельные имена для каждого клиента, чтобы метрики были разделяемы. Jersey-клиент предпочтителен для REST-запросов с JSON, так как использует один и тот же ObjectMapper и поддерживает автоматическое преобразование JSON в объекты. Apache-клиент нужен при работе с потоками, нестандартными протоколами или глубоким контролем HTTP-запросов. Оба клиента требуют корректной настройки таймаутов и размеров пулов, чтобы избежать блокировок и перегрузки соединений. Важно закрывать ответы от запросов, иначе соединения не возвращаются в пул, что приводит к утечке ресурсов.

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

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

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

В каких сценариях использование Apache HttpClient будет предпочтительнее, чем JerseyClientBuilder, если сервис должен обрабатывать потоковые данные или передавать большие файлы без разбиения на части?

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

При каких условиях повторные попытки (retries) могут привести к непредсказуемым результатам, например, к двойному резервированию товара, и как это можно предотвратить на уровне конфигурации или кода?

Dropwizard Could Not Resolve Type Id ‘http’ Error: Fix

Открыть оригинал ↗ Перевод заголовка: Ошибка Dropwizard: не удалось разрешить идентификатор типа ‘http’ — как её исправить

Ошибка «Failed to parse configuration … Could not resolve type id ‘http’ as a subtype of ConnectorFactory» возникает при запуске fat JAR, когда Jackson не находит в конфигурации типов подключений, что почти всегда связано с отсутствием в пакетированном JAR файла с сервисами (META-INF/services). Причина — стандартный Maven Shade не объединяет все сервис-файлы, если не добавить трансформер ServicesResourceTransformer. Важно, что ошибка появляется только при запуске JAR, а не в IDE или тестах, поскольку в этих средах все зависимости загружаются отдельно.

Добавить в pom.xml трансформер ServicesResourceTransformer рядом с ManifestResourceTransformer для корректного объединения сервис-файлов в fat JAR.
Проверить содержимое файла META-INF/services/io.dropwizard.jackson.Discoverable в распакованном JAR — он должен включать все доступные типы подключений, включая io.dropwizard.jetty.ConnectorFactory.
При наличии непустого списка known type ids проверить корректность значения в config.yml (например, опечатку в htttp вместо http) и наличие необходимого модуля (например, dropwizard-http2).
Для CI/CD использовать команду java -jar target/app.jar check config.yml для быстрой проверки конфигурации без запуска приложения.
Ошибка может возникать не только для HTTP-подключений, но и для логов, метрик и других типов, так как все используют один и тот же механизм обнаружения типов.

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

Материал полезен при разработке и сборке fat JAR-приложений на Dropwizard, особенно когда приложение работает корректно в IDE, но падает при запуске в production или в CI-пайплайне.

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

Какой минимальный набор модулей должен быть в проекте, чтобы в known type ids появился http, и как это влияет на выбор версии Dropwizard?

При каких условиях может возникнуть ошибка, если known type ids не пустой, но тип в конфигурации всё равно невалиден, и как это отличить от отсутствия модуля?

Какой из вариантов — Maven Shade или Gradle Shadow — обеспечивает лучшую совместимость с Dropwizard при использовании нескольких модулей, и почему?

Dropwizard Tutorial: Hello World REST API Example (Java 25)

Открыть оригинал ↗ Перевод заголовка: Учебник Dropwizard: Пример REST-API "Hello World" на Java 25

Dropwizard — это легковесная библиотека для создания REST-сервисов на Java, которая объединяет в себе проверенные и стабильные библиотеки (Jetty, Jersey, Jackson, Hibernate Validator, Metrics) в единую рабочую папку JAR. В примере демонстрируется структура приложения: конфигурация, основной класс и ресурсы JAX-RS, при этом Dropwizard запускает встроенный сервер Jetty с портами для API и администрирования. Сервис возвращает JSON-ответы при запросах, например, curl на /hello?name=Lokesh возвращает приветствие с подстановкой имени.

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

Dropwizard требует Java 17+, использует Jakarta-названия (а не javax), что важно при настройке проекта.
Конфигурация в YAML с валидацией через аннотации (например, @NotBlank) позволяет быстро обнаруживать ошибки на этапе запуска.
При запуске сервиса через fat JAR необходимо использовать Maven Shade Plugin для объединения сервисных файлов, иначе возникает ошибка при поиске типа коннектора.
Валидация запросов (например, пустое поле в JSON) возвращается как HTTP-ошибка 422, что обеспечивает прозрачную реакцию на некорректные данные.
Админ-порт (8081 по умолчанию) предоставляет доступ к проверкам здоровья и метрикам, что критично для мониторинга в production.

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

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

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

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

В каких сценариях использование Dropwizard может привести к проблемам с масштабированием по сравнению с Spring Boot, особенно при интеграции с другими сервисами?

Какова сложность реализации валидации в JAX-RS при использовании @Valid и как это может повлиять на производительность при большом количестве запросов?

Dropwizard Basic Auth Example With @Auth and @RolesAllowed

Открыть оригинал ↗ Перевод заголовка: Пример базовой аутентификации в Dropwizard с аннотациями @Auth и @RolesAllowed

Dropwizard реализует базовую аутентификацию через модуль dropwizard-auth, который извлекает имя и пароль из заголовка HTTP Authorization, проверяет их с помощью аутентификатора и передаёт авторизованного пользователя методам, аннотированным @Auth. Дополнительно, через @RolesAllowed проверяется роль пользователя, что позволяет возвращать 401 при неверных данных и 403 при отсутствии необходимой роли. Пример демонстрирует настройку фильтров в методе run() сервиса для управления инвойсами, включая хранение паролей в виде хэшей BCrypt, использование кэширования для ускорения проверок и тестирование через curl и JUnit 6.

Базовая аутентификация работает только при использовании HTTPS, так как Base64-кодирование не является шифрованием и может быть декодировано любым наблюдателем трафика.
Проверка пароля производится с помощью BCrypt, который настроен на медленную обработку для защиты от угроз «массового» взлома, при этом кэширование успешных сессий снижает нагрузку на CPU.
Роль пользователя определяется через Authorizer, который проверяет наличие роли в конфигурации, и аннотации @RolesAllowed позволяют ограничивать доступ по ролям.
Аутентификация возвращает 401 при отсутствии или неверных данных, а 403 — при наличии учётной записи, но отсутствии необходимой роли, что позволяет четко разделять ошибки аутентификации и авторизации.
В production-среде пользователи должны храниться в базе данных, а не в конфигурационных файлах, и аутентификатор должен читать хэши из источника данных.

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

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

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

Какой компромисс между безопасностью и производительностью возникает при использовании BCrypt без кэширования, и как это влияет на масштабируемость при высокой нагрузке?

В каких сценариях может привести к уязвимости использование кэширования успешных сессий, если атакующий может предсказать или воспроизвести успешные запросы?

Как изменится поведение системы при переходе с @Auth на @RolesAllowed для методов, которые не требуют прямого доступа к пользователю, но должны проверять роль?

Inside Java

Structured Concurrency Looms

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

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

Структурированная конкуренция объединяет группы задач в иерархическую структуру, где каждый подпоток связан с родительским контекстом, что позволяет легко отменять выполнение всей ветви при возникновении ошибки.
Новая API-интерфейс, появляющийся в рамках предварительных версий, предоставляет доступ к более низкоуровневым механизмам, которые могут стать основой будущего расширенного API для структурированной конкуренции.
Функция прошла тестирование в реальных сценариях и на основе обратной связи сообщества, что подтверждает её практическую применимость и стабильность.
Позволяет упростить отслеживание и анализ ошибок, так как все задачи в дереве выполнения могут быть связаны с одним корневым контекстом.
Упрощает разработку и поддержку высокопроизводительных приложений, особенно в случаях, где требуется управление множеством параллельных задач с едиными правилами завершения.

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

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

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

В каких сценариях структурированная конкуренция может привести к ухудшению производительности по сравнению с традиционными потоками, и как это может быть избежано при проектировании?

Какова сложность (в терминах времени и памяти) создания и управления деревом задач в структурированной конкуренции при больших количествах ветвления?

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

System Design

DEV System Design

Architecting a High-Concurrency Railway Booking Platform with Node.js, Apache Kafka, and Redis Distributed Locks

Открыть оригинал ↗ Перевод заголовка: Архитектура высоконагруженной системы бронирования мест на железнодорожном транспорте с использованием Node.js, Apache Kafka и распределённых блокировок в Redis

Для решения проблемы высокой конкуренции при бронировании мест в условиях коротких временных интервалов разработана архитектура на основе микросервисов, где каждый сервис управляет собственной базой данных и взаимодействует через асинхронный брокер событий Apache Kafka. Ключевыми механизмами являются распределённые блокировки в Redis для предотвращения конфликтов при бронировании, Saga-паттерн для обеспечения распределённой согласованности без транзакций, а также инвертированный индекс в Elasticsearch для быстрого поиска маршрутов.

Использование Redis для распределённых блокировок позволяет избежать блокировок в базе данных и обеспечивает атомичность при бронировании мест через Lua-скрипты.
Архитектура на основе Kafka обеспечивает декуплирование операций (запись, уведомления, обновление инвентаря), что позволяет избежать блокировок и обеспечивает отказоустойчивость через Dead-Letter Queues.
Система использует denormalized индексы в Elasticsearch для быстрого поиска маршрутов, что снижает нагрузку на SQL-запросы и обеспечивает поддержку запросов в миллисекундах.
Вместо транзакций применяется Saga-паттерн, что требует реализации идемпотентности и обработки компенсирующих действий при сбоях.
Каждый сервис работает с собственной PostgreSQL-базой, что упрощает масштабирование и изоляцию сбоев, но требует сложной инфраструктурной поддержки.

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

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

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

Как изменится производительность и надёжность системы при увеличении количества одновременных бронирований на 100%, если не увеличивать размер кэша в Redis?

В каких сценариях может привести к сбоям использование Saga-паттерна без строгой идемпотентности и проверки состояния в Redis?

Какой вклад в общую задержку вносит обработка сообщений в DLQ, если в среднем 1% запросов приводит к неподходящему десериализации?

How to Prevent Retry Storms in Microservices

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

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

Три ключевых подхода для предотвращения таких сценариев:

Retry budgets — ограничение доли всех входящих запросов, которые могут быть перезапущены (например, не более 10%), после превышения которого сервис немедленно возвращает ошибку клиенту.
Circuit breakers — мониторинг ошибок в течение временного окна (например, 50% ошибок за 10 секунд), после чего все последующие вызовы сразу отклоняются без попыток подключения.
Ограничение повторных вызовов к одной слою — разрешение перезапуска только на первом уровне (например, в API-гейтве или непосредственно перед базой), а не в каждом сервисе в цепочке.

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

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

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

Как изменится поведение retry budget при высокой нагрузке и нестабильной сети, если сервисы начинают получать ошибки не из-за базы данных, а из-за временных проблем в кластере API-гейтвей?

В каких условиях circuit breaker может привести к ложному срабатыванию и как это может повлиять на время восстановления после реального восстановления сервиса?

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

Two-Phase Commit in the Real World: Why It Blocks, How Spanner Fixed It, and What to Do When Things Break

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

В распределённых системах, где данные хранятся на разных машинах, важно обеспечить атомичность транзакций — изменение одного состояния должно происходить вместе с другим или не происходить вовсе. Классический подход — двуфазный коммит (2PC), который координирует согласие между узлами, но имеет критическую слабость: при сбое координатора транзакция может "зависнуть", так как участники остаются в состоянии подготовки и не могут отменить операцию без знания решения. Google Spanner решил эту проблему, заменив одиночный координатор на группу узлов с согласованием (как в Paxos или Raft), где решения фиксируются в реплицированном журнале, и при сбое координатора новый лидер автоматически продолжает выполнение. Это позволяет избежать блокировок, но добавляет задержку из-за необходимости согласования. В реальных условиях могут возникать сбои участников, сетевые разрывы и производительность, особенно при читательской нагрузке, где Spanner использует TrueTime API для обеспечения согласованности без 2PC.

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

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

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

Какой компромисс между задержкой и отказоустойчивостью в 2PC с использованием Paxos, если в системе есть низкая пропускная способность сети и высокая частота сбоев узлов?

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

Какой минимальный размер кворума (N/2 + 1) необходим для обеспечения безопасности в случае сетевого разрыва, если узлы распределены по глобальным регионам?

Engineering a Location-Based Rental Marketplace: Search, Availability, and Booking Workflows

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

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

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

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

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

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

Как изменится сложность и надежность системы, если ввести ограничение на минимальную продолжительность аренды (например, 3 часа), и как это повлияет на пересечение временных интервалов при проверке доступности?

В каких сценариях может привести к ошибкам использование простого флага is_available, и как можно оценить риск возникновения race conditions при высокой нагрузке на бронирование?

Какие архитектурные решения могут обеспечить масштабируемость при работе с разными регионами, где разные страны имеют разные требования к водительскому удостоверению и тарифам?

Architectures I Haven’t Built Yet

Открыть оригинал ↗ Перевод заголовка: Архитектуры, которые я ещё не строил

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

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

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

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

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

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

В каких условиях (по масштабу, нагрузке, времени) архитектура, описанная в посте, может начать демонстрировать нестабильность или неэффективность?

Какой из существующих подходов к архитектурной документации (например, диаграммы, чек-листы, AI-генерация) лучше всего дополняет этот формат и почему?

Designing a Rate Limiter for an SMS API: The Mistakes I Made Along the Way

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

При проектировании лимитера скорости для API SMS автор столкнулся с тремя ключевыми ошибками: неверное определение клиента, неадекватную модель времени, и отсутствие атомарности в реализации. Основная цель — предотвратить перегрузку серверов, блокируя запросы, превышающие установленный лимит, и обеспечивая справедливое распределение ресурсов между типами аккаунтов. Важно понимать, что клиент определяется по API-ключу, а не по IP, и что лимитер должен быть масштабируемым и устойчивым к сбоям. Автор использует модель "token bucket", где каждый клиент имеет резервный бак токенов, заполняемый равномерно, и при отсутствии токена возвращается ошибка 429 с указанием времени ожидания. Критически важно, что лимитер должен быть атомарным (через одно действие в Redis), чтобы избежать конкуренции между серверами. При сбое Redis система должна отказаться от строгого контроля, но при этом не приводить к полному отказу сервиса — вместо этого используется локальный бак, который ослабляет ограничение, но предотвращает катастрофический рост нагрузки.

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

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

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

Как изменится поведение лимитера при переходе от token bucket к fixed window, если в системе есть резкое увеличение нагрузки в течение короткого промежутка времени?

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

Какой компромисс между точностью и устойчивостью будет в случае использования token bucket с низкой скоростью пополнения (например, 1 токен в 10 секунд), если клиенты могут использовать буферы для "запуска" запросов в пиковые моменты?

Coding / Algorithms

DEV Data Structures

# Learning Python Data Structures and Algorithms Through Practical Examples

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

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

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

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

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

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

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

Почему в симуляторе используется choice - 1 для индексации списка, и как это может повлиять на надёжность при масштабировании или добавлении новых опций?

Какой из методов валидации (например, startswith(), strip()) наиболее эффективен при обработке неочищенных строк с разными форматами, и как это может изменять архитектуру ввода-вывода?

Two-Pointer Power: Leveling Up Like a Jedi

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

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

Двухуказателевый подход работает только на отсортированных массивах — при отсутствии сортировки необходимо сначала отсортировать, что добавляет O(n log n), но остаётся предпочтительнее O(n²).
При выборе направления движения указателей важно учитывать, что только указатель, соответствующий меньшему значению, может привести к улучшению результата — движение другого указателя не может увеличить результат.
В задачах с ограничениями (например, сумма троек равна нулю) можно использовать внешний цикл для фиксации одного элемента, а затем применять двухуказателевый подход к оставшейся части массива, что снижает сложность с O(n³) до O(n²).

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

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

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

Какой компромисс между сортировкой и двумяуказателевым подходом возникает при работе с большими массивами, где сортировка добавляет O(n log n), но устраняет необходимость в O(n²) переборе?

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

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

Why doubling makes a dynamic array O(1) (and the realloc bug almost everyone writes)

Открыть оригинал ↗ Перевод заголовка: Почему удвоение делает динамический массив O(1) (и ошибка realloc, которую почти каждый пишет)

Динамический массив — это структура, хранящая указатель на данные, количество элементов (size) и доступную ёмкость (capacity). При заполнении массива (size == capacity) требуется расширение — выбор стратегии роста напрямую влияет на производительность. Рост на 1 приводит к кумулятивной сложности O(n²), так как каждый раз копируется весь массив. Удвоение ёмкости делает операции амортизированно O(1): копирование происходит редко, и общее количество копирований растёт линейно, а не квадратично. Ошибка в реализации realloc — когда функция не обрабатывает сбой, возвращая NULL без освобождения старого блока — приводит к утечке памяти и сбою при последующем доступе. Правильная реализация использует временный указатель, чтобы сохранить старую память при неудачной операции. Также важно проверять переполнение при умножении ёмкости.

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

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

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

Какой компромисс между ростом ёмкости и риском переполнения может возникнуть при использовании удвоения для массивов больших размеров, и как это влияет на производительность в реальных условиях?

В каких случаях может быть предпочтительнее рост на фиксированное значение (например, +4) вместо удвоения, и как это сказывается на амортизированной сложности при неравномерной нагрузке?

Какова сложность проверки переполнения при умножении capacity на 2 в условиях, когда capacity может быть очень большим, и как это влияет на безопасность при работе с большими массивами?

Habr Algorithms

Как я решал leetcode задачу

Открыть оригинал ↗ Перевод заголовка: Как я решал задачу на LeetCode

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

Использование позиционной системы счисления позволяет перебрать все возможные комбинации скобок, отсекая неподходящие посредством контроля уровня сбалансированности.
Решение через backtracking с рекурсией более наглядно и эффективно, хотя и требует понимания структуры рекурсивного вызова и состояния стека.
Нерекурсивный подход, основанный на счётной системе, менее эффективен из-за перебора всех комбинаций, включая заведомо невалидные, и не подходит для больших значений n.
Автор отмечает, что рекурсивные алгоритмы часто остаются в академической сфере из-за отсутствия практики, что затрудняет их вспоминание в условиях стресса.
Критика собеседований, где кандидаты вынуждены лайф-кодить без объяснений, подчёркивает разрыв между реальными навыками и формальными ожиданиями.

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

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

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

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

Какова сложность рекурсивного решения по времени и памяти при n = 8, и в каких случаях оно может быть заменено более оптимальным подходом без потери читаемости?

Почему автор считает, что рекурсивные методы остаются "исключительно академическими", и как это может повлиять на их применение в реальных проектах?