Risk Management

arXiv Quantitative Finance - Pricing

Interior smoothness and zero-variance geometry for finite-maturity Heston American puts

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

Статья исследует поведение границы оценки американских опционов на продажу в модели Хестона без условия Феллера. Авторы показывают, что при положительной дисперсии граница оценки гладка и строго убывает с ростом времени до погашения и дисперсии. В пределе при нулевой дисперсии граница сохраняет локальную липшицеву регулярность, движется с ограниченной скоростью по времени и непрерывно переходит к оси дисперсии. Вблизи оси дисперсии происходит разрыв в производной по дисперсии, что делает невозможным применение условия гладкого соответствия (smooth fit), и в момент погашения вся граница сходится к уровню исполнения.

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

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

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

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

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

arXiv Quantitative Finance - Risk Management

Deep kernel hedging

Открыть оригинал ↗ Перевод заголовка: Глубокое ядро-гейдинг

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

  • Ядро гейдинга строится через нейросетевую эмбеддинг-функцию, что обеспечивает высокую гибкость при описании сложных зависимостей.
  • Метод использует усечённые временные сигнатуры для включения путь-зависимой информации в обучение.
  • Сходимость модели подтверждена теоретически, при этом вычислительная сложность снижена за счёт стабильного приближения Фурье-характеристик.
  • На тестовых данных (синтетических и реальных) метод показывает устойчивую производительность, особенно при ограниченном объёме данных.
  • В отличие от традиционных подходов, глубокое ядро-гейдинг не требует прямого обучения функции гейдинга, а использует структурные свойства ядерного пространства.

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

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

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

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

AI

Habr AI

Сначала пилот, потом стратегия: как крупный бизнес внедряет LLM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Перевод] Я не хочу читать то, чего вы не писали

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

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

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

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

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

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

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

Как писать текст для нейросети, чтобы она сослалась на сайт: в 60 ответах она чаще брала абзацы от 30 слов

Открыть оригинал ↗ Перевод заголовка: Как писать текст для нейросети, чтобы она сослалась на сайт: в 60 ответах она чаще брала абзацы от 30 слов

При анализе 60 ответов Perplexity с поиском в интернете было выявлено, что нейросети чаще цитируют абзацы длиной от 30 до 80 слов. Такие фрагменты лучше справляются с условием «понятны без контекста», что критично для поисковых ИИ, которые режут страницы на куски и выбирают только те, что содержат ключевые факты. Важные признаки — наличие числа, названия предмета внутри текста, отсутствие «стен текста» и длина абзаца — показывают, что короткие или слишком обрывистые фрагменты реже попадают в ответы.

  1. Абзацы длиной от 30 до 80 слов в 1,5 раза чаще попадают в ответы, чем короткие — длина является ключевым фильтром.
  2. Название предмета должно быть указано в самом абзаце, а не только в заголовке, что повышает вероятность цитирования.
  3. Наличие числа в абзаце — полезный, но не решающий признак, так как в длинных текстах цифры встречаются чаще из-за длины.
  4. Начало абзаца со словами вроде «это», «поэтому» не влияет на выбор, так как нейросети не зависят от таких отсылок.
  5. Проверка готовности абзаца к цитированию возможна через скрипт на Python, который оценивает длину, наличие числа, предмета и отсылок.

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

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

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

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

InfoQ Architecture

Google Antigravity SDK Adds Local Model Support for Greater Token Efficiency and Code Privacy

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

Нововведение в SDK Antigravity от Google позволяет разработчикам запускать агентные потоки на локальной машине, сочетая при этом облачные модели для высокого уровня задач. Архитектура основана на паттерне «Архитектор-Исполнитель», где архитектор работает в облаке для планирования, а специализированные агенты выполняют задачи локально, не требуя доступа к исходному коду. Это обеспечивает приватность данных, снижает траты на инференс и уменьшает зависимость от сети. В демонстрации на Python-модулях только 95 токенов использовались в облаке для планирования, остальные 97,2% — локально, без загрузки исходного кода. Поддерживается как Gemma 4 26B через LiteRT, так и OpenAI-совместимые локальные серверы через конфигурацию LocalOpenAIAgentConfig.

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

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

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

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

Meta Extends Confidential Computing to AI Glasses with Private Processing

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

Meta внедряет архитектуру приватной обработки в AI-очки, используя защищённые виртуальные машины (CVMs) для выполнения чувствительных задач и хранения персонального контекста в облаке. Система обеспечивает изоляцию данных с помощью аппаратных TEE, удалённой аттестации, анонимных сертификатов и шифрованного хранения, позволяя выполнять сложные задачи, такие как транскрипция потоков, контекстуальный поиск и долгосрочное запоминание, без передачи данных Meta. Контекст сохраняется внутри защищённой среды, а запросы и операции выполняются в пределах CVM, минимизируя риск утечки информации.

  1. Приватная обработка в AI-очках основана на аппаратной изоляции и аттестации, что позволяет гарантировать, что данные не попадают в руки Meta, даже при наличии постоянного мониторинга.
  2. Система использует защищённые виртуальные машины (CVMs), поддерживаемые TEE, где модели и хранилища работают в зашифрованной среде, а передача данных требует подтверждения аттестации и проверки транспарентного журнала.
  3. Анонимные сертификаты и OHTTP-релей (например, от Fastly или Cloudflare) обеспечивают разрыв между идентичностью пользователя и обработкой запросов, что снижает риски персонализации и отслеживания.
  4. Постоянное состояние и запросы выполняются внутри CVM, что предотвращает утечку паттернов доступа к базам данных и поведения пользователя.
  5. Meta использует агрегированные метрики (CPU, память, задержки) для мониторинга работы системы, так как прямой доступ к данным или моделям невозможен, что ограничивает возможности анализа и отладки.

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

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

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

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

Latent Space

Lab-in-the-Loop at Compute Speed — Ian Quigley, Leash Bio

Открыть оригинал ↗ Перевод заголовка: Лаборатория в цикле — на скорости вычислений

Leash Bio преодолел страхи, связанные с экспериментами по взаимодействию белков и молекул (DELs), внедрив эпистемическую строгость и систему проверки данных, позволяющую выявлять «честные» модели и обнаруживать их фальсификации. Команда использует данные DELs не только для моделирования, но и для создания среды, где ИИ-агенты могут обучаться научным рассуждениям, как химики, что открывает путь к автономным лабораторным системам.

— В DEL-экспериментах каждая молекула маркируется десятками баркодов, что позволяет выявлять несвязывающиеся белки и обеспечивает воспроизводимость данных.
— Данные DEL-библиотеки, собранные на уровне миллиардов измерений, становятся источником «лабораторных симуляций» для обучения ИИ-агентов в реальном времени.
— Модель Hermes, обученная только на данных Leash, справляется с задачами на уровне конкурентов (Boltz), но затем учитывается нарушение обобщения — модель запоминает «никнеймы» белков, а не их биологические сайты.
— Система выявляет аномалии, например, молекулы, похожие на Lumacaftor, как маркеры несформированных белков.
— Появляется открытая среда Minos, где ИИ-агенты могут проводить научные рассуждения и находить оптимальные молекулы среди 6,5 млн вариантов с бюджетом в 100.

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

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

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

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

Crossing the Threshold: How OpenAI and Anthropic Approach Autonomy and Safety in Financial Agents

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

Ключевая мысль конференции AI Engineer New York — безопасная автономия достигается не за счёт количества ограничений, а за счёт выбора места для вмешательства человека и контроля. Оба крупных лаборатории — OpenAI и Anthropic — и финансовые институты фокусируются на том, как встроить безопасность в агенты, не уменьшая их полезности. OpenAI подчёркивает «порог полезности» — момент, когда модель становится надёжной и может сэкономить время пользователя. В финансах это означает, что агенты могут генерировать инвестиционные идеи и участвовать в торговле. Anthropic предлагает три этапа построения доверия: идентификация агента, санкционирование действий и устойчивость к изменениям. Bloomberg акцентирует внимание на внешних механизмах контроля — валидации входных данных, логировании и «выключателях», чтобы предотвратить аварийные действия.

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

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

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

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

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

[AINews] AI Engineer NYC: Gemini 4 Argon, Vals AI Benchmarks

Открыть оригинал ↗ Перевод заголовка: AI Engineer NYC: Gemini 4 Argon, Vals AI Benchmarks

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

  1. Gemini 4 Argon доступен по разным тарифам — включая API и платформу, с начальными ценами $2–$10 на миллион токенов, но после 30 ноября стоимость удваивается, что важно для бюджетных оценок.
  2. Модель показывает значительные улучшения в агентных задачах (на 35% больше кодовых вводов, сокращение откатов), но при этом демонстрирует высокий уровень ложных утверждений в анализе кода — разрыв между «хорошей» генерацией и «доверенной» аналитикой.
  3. В оценках по разным метрикам (например, Vision, документы, агенты) Argon и Muse показывают сильные результаты, но разные тесты (например, UI-генерация, баг-фикс) дают противоречивые выводы — качество не унифицировано.
  4. Новые архитектуры (например, LongHarness, ReHarness) решают проблемы долгосрочной памяти и структурированного выполнения, но их эффективность зависит от конкретных задач и не подтверждены в масштабах production.
  5. Вопросы безопасности и надёжности остаются открытыми — модели могут обходить мониторинг, а эксплуатация в реальных условиях (например, в Chrome) требует человеческого вмешательства, несмотря на заявленную автономность.

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

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

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

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

Java / Spring

Engineering With Java

Spring Boot Interview Question: Spring Boot API That Returns Too Much Data

Открыть оригинал ↗ Перевод заголовка: Вопрос на собеседовании по Spring Boot: API возвращает слишком много данных

В приложении для управления подписками, построенном на Spring Boot и React, при открытии страницы с планами подписки браузер замедляется и становится неактивным при больших объёмах данных. Анализ показывает, что API возвращает полные JPA-сущности, включая неиспользуемые коллекции, хотя frontend использует только ID и имя плана. Это приводит к чрезмерной загрузке и парсингу данных, несмотря на то, что большинство полей не используются.

  1. Для определения источника задержки необходимо изолировать каждый этап: выполнение запроса в БД, гидрацию сущностей, сериализацию JSON, передачу по сети и обработку в браузере — каждый из них должен быть измерен отдельно.
  2. Вместо возвращения полных сущностей следует использовать DTO-проекции, которые выбирают только необходимые поля (например, ID и имя), что снижает объём данных и уменьшает нагрузку на сеть и frontend.
  3. Важно использовать запросы с явным выбором столбцов (например, через JPQL), чтобы избежать загрузки неиспользуемых полей и ассоциаций, даже если они помечены как ленивые.
  4. Внедрение пагинации и поиска на сервере позволяет сократить объём ответа и сделать его управляемым при больших объёмах данных.
  5. Несмотря на настройку ленивых загрузок, необходимо проверять реальное поведение — возможно, ассоциации не загружаются вообще, а не вызывают дополнительных запросов.

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

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

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

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

Foojay

Lightweight Spring Boot Monitoring Without Prometheus and Grafana

Открыть оригинал ↗ Перевод заголовка: Лёгкий мониторинг Spring Boot без Prometheus и Grafana

Для небольшого количества Spring Boot-приложений на VPS часто достаточно базового контроля — проверки доступности, роста ошибок и перезапусков. Стандартные инструменты, такие как Actuator и Micrometer, уже предоставляют необходимую информацию, но их JSON-эндпоинты не подходят для ежедневного использования в виде визуального дашборда. StatLite решает эту проблему, предлагая лёгкий дашборд на базе Go, который читает данные из Actuator и показывает ключевые метрики: здоровье, ошибки, задержки, память, время работы и перезапуски. Он работает как один бинарник, хранит историю в SQLite и требует минимальных ресурсов.

  • StatLite использует существующие конфигурации Actuator и Micrometer, не требуя дополнительных агентов или инструментов.
  • Он запускается как один Go-процесс, что делает его идеальным для небольших серверов с ограниченными ресурсами.
  • Настройка происходит за несколько шагов: включение эндпоинтов в Spring Boot, установка StatLite и конфигурация одного целевого приложения.
  • Дашборд работает локально и не требует сложной инфраструктуры, что упрощает управление в production-среде.
  • Поддерживается масштабируемость — StatLite может быть расширен до нескольких приложений в одной конфигурации.

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

Материал полезен для разработчиков и операторов, работающих с небольшой инфраструктурой (например, 1–5 Spring Boot-приложений на VPS), где требуется быстрый, лёгкий и независимый дашборд без необходимости внедрения сложных систем мониторинга.

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

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

Habr Spring

Октябрь ещё не закончился: 50 бесплатных уроков от падающего Spring Boot до мультиагентных систем

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

В октябре OTUS проводит серию из 50 бесплатных открытых уроков по ключевым направлениям IT — от устаревших технологий, таких как Spring Boot и SQL-запросы, до передовых тем, включая ИИ-агенты и мультиагентные системы. Уроки охватывают как технические навыки (например, оптимизацию запросов, работа с базами данных), так и мета-аспекты разработки — управление командами, внедрение метрик, стратегии принятия решений. Программа включает как подготовительные курсы по фундаментам (SQL, Git), так и специализированные вебинары по инструментам и архитектурным подходам.

  • Уроки по Spring Boot и JDBC помогут понять, почему сервисы работают локально, но падают в production — важный компонент для диагностики и устранения ошибок.
  • Вебинары по ИИ-агентам (например, Tool Calling, LLM-интеграция, мультиагентные системы) показывают, как ИИ может автоматизировать рабочие процессы и взаимодействовать с корпоративными системами.
  • Темы по управлению и метрикам помогают разработчикам и менеджерам оценивать ценность ИИ и внедрять его в бизнес-процессы.
  • Предложены мини-курсы по базовым навыкам (Linux, Git, SQL), что позволяет новичкам и специалистам с фундаментальными пробелами начать обучение.
  • Программа охватывает широкий спектр — от DevOps и тестирования до аналитики и управления, что делает её полезной для разных ролей в IT.

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

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

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

  1. В каких условиях мультиагентные системы могут привести к нестабильности в рабочих процессах, и как это можно предотвратить без значительных изменений в архитектуре?
  2. Какова сложность и масштабируемость реализации Tool Calling в реальных приложениях, особенно при интеграции с корпоративными системами через API?
  3. В каких сценариях использование GitLab CI/CD и CML для автоматизации ML-экспериментов может привести к ухудшению качества моделей, и как это можно избежать?

System Design

AWS Architecture Blog

How UTS established a modern curriculum data services foundation on AWS

Открыть оригинал ↗ Перевод заголовка: Как Университет Технологий Сиднея (UTS) создал современную основу сервисов данных по учебным программам на AWS

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

  1. Университет сохранил официальную систему управления учебными программами как единственный источник правды, при этом создал слой сервисов, который делает данные доступными через API, графовые запросы и семантический поиск без нарушения авторитета исходной системы.
  2. Архитектура использует серверные и асинхронные компоненты (Amazon MSK, Amazon Neptune, Amazon OpenSearch), что позволяет масштабироваться под пиковые нагрузки и быстро восстанавливаться при сбоях.
  3. Все компоненты работают в режиме без состояния, что обеспечивает отказоустойчивость и позволяет избежать глубоких сбоев в одной части системы.
  4. Доступ к данным осуществляется через стандартизированные интерфейсы (REST, GraphQL), а не через прямой доступ к базам, что упрощает безопасность и управление правами.
  5. Операционная нагрузка сокращена до одного инженера благодаря использованию AWS-managed сервисов, что делает систему экономически эффективной и легко масштабируемой.

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

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

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

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

ClickHouse

How Ridgeline unified Iceberg and ClickHouse into one analytics layer for investment management

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

Ridgeline перешёл от Postgres к ClickHouse Cloud, чтобы решить проблемы масштабируемости и производительности при обработке сложных аналитических запросов. В системе теперь используются два слоя: современные данные — в ClickHouse, исторические — в Iceberg, которые затем читаются через специальный коннектор. Это позволяет обеспечить как высокую скорость аналитики, так и полное покрытие истории портфелей с нулевым ущербом для точности.

  1. ClickHouse обеспечивает высокую скорость выполнения сложных аналитических запросов (вплоть до 40 мс на чтение), что критично для оперативных отчётов и реального времени.
  2. Использование Iceberg для хранения исторических данных позволяет сэкономить ресурсы, так как большие объёмы данных хранятся эффективно, а затем читаются через ClickHouse через специальный коннектор.
  3. Материализованные представления в ClickHouse автоматически обрабатывают данные и обеспечивают стабильность и точность, позволяя разработчикам быстро создавать и внедрять новые аналитические схемы.
  4. Архитектура с разделением на staging и production, с изоляцией данных и управлением через ClickHouse Cloud, обеспечивает соответствия требованиям безопасности (SOC 2) и упрощает операционное управление.
  5. Система позволяет не только масштабироваться вперёд (с ростом клиентов в 10–40 раз), но и внедрять новые функции, такие как реальное время аналитики, которые ранее были невозможны.

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

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

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

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

Why Redshift Serverless can’t match ClickHouse Cloud for real-time analytics

Открыть оригинал ↗ Перевод заголовка: Почему Redshift Serverless не может конкурировать с ClickHouse Cloud в реальном времени для аналитики

В статье сравниваются два сервиса для обработки потоковых данных: ClickHouse Cloud и Redshift Serverless. В ходе непрерывного ввода 113,2 миллиарда цитат ClickHouse Cloud показал в 1996 раз более высокую эффективность по стоимости на конечный результат, чем Redshift Serverless. Основное преимущество заключается в том, что ClickHouse формирует предварительные агрегации и упорядочивает данные в процессе ввода, в то время как Redshift обрабатывает данные в отдельных этапах — сортировка, обновление материализованных представлений — и их выполнение не синхронизировано с запросами.

  1. ClickHouse формирует агрегаты и упорядочивает данные в момент ввода, что позволяет поддерживать свежесть данных и сокращать время выполнения запросов.
  2. В отличие от Redshift, где подготовка данных проходит в отдельных этапах и не синхронизируется с запросами, ClickHouse сохраняет актуальные суммарные данные во время ввода.
  3. Стоимость подготовки и выполнения запросов в ClickHouse на 18,2–495 раз ниже, а общее время выполнения запросов — на 104,8 раз меньше.
  4. В Redshift запросы к агрегатам и детализации зависят от завершения обновлений, что приводит к значительным задержкам, особенно в условиях высокой нагрузки.
  5. ClickHouse обеспечивает более быструю реакцию на запросы и поддерживает свежесть данных в реальном времени, что критично для интерактивных аналитических систем.

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

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

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

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

DEV System Design

System Design Fundamentals: Designing a Scalable URL Shortener (Bitly)

Открыть оригинал ↗ Перевод заголовка: Фундаменты системного проектирования: создание масштабируемого URL-сокращителя (Bitly)

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

  1. Важно оценивать соотношение чтения и записи при проектировании системы, чтобы избежать перегрузки хранилища и оптимизировать производительность.
  2. Вместо хранения хеш-срезов (MD5) рекомендуется использовать Base62-кодирование для сокращения URL, так как оно обеспечивает более равномерное распределение по буквам и уменьшает вероятность коллизий.
  3. Генерация уникальных идентификаторов с использованием алгоритма Snowflake позволяет обеспечить глобальную уникальность и последовательность, при этом поддерживая низкую задержку и масштабируемость.
  4. Архитектура должна включать слой кэширования (например, Redis), чтобы снизить нагрузку на базу данных и ускорить ответы на запросы.
  5. Критически важно внедрять механизмы отказоустойчивости: таймауты, повторные попытки, логирование с корреляционными идентификаторами и обработку дублирования операций.

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

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

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

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

Designing a Distributed Rate Limiter: Token Bucket, Leaky Bucket, and Sliding Window Counters

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

При проектировании распределённых систем лимитер скорости — ключевой элемент для предотвращения перегрузки и обеспечения стабильности. В статье рассматриваются три основных алгоритма: бакет с токенами (Token Bucket), бакет с просачиванием (Leaky Bucket) и счётчики с движением окна (Sliding Window Counters), с акцентом на их практическое применение и производственные компромиссы. Особое внимание уделяется реализации с помощью Redis, где используются команды ZADD и ZREMRANGEBYSCORE для атомичного управления окном времени. Также подчёркивается важность контроля за памятью и отказоустойчивостью, чтобы избежать крахов из-за неограниченных очередей или зависаний.

  1. Бакет с токенами подходит для гибких лимитов, но требует точного управления запасом токенов и может не обеспечивать равномерную нагрузку.
  2. Бакет с просачиванием даёт стабильную скорость потока, но не подходит для систем с переменной нагрузкой и не позволяет настраивать пиковые лимиты.
  3. Счётчики с движением окна обеспечивают более точную оценку скорости, но требуют сложной синхронизации и могут создавать нагрузку на память при больших объёмах данных.
  4. Redis-реализация с ZADD и ZREMRANGEBYSCORE позволяет реализовать атомичные операции, но требует внимательного контроля за временными рамками и переполнением.
  5. Важно устанавливать жёсткие лимиты на очереди и таймауты, чтобы избежать масштабируемых сбоев и падений системы.

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

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

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

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

Message Queues in Modern Backends: Decoupling Microservices with RabbitMQ and Redis

Открыть оригинал ↗ Перевод заголовка: Сообщения в современных бэкендах: декуплинг микросервисов с RabbitMQ и Redis

В современных распределённых системах без Message Queues невозможно обеспечить надёжность, масштабируемость и отказоустойчивость. Прямые вызовы между микросервисами приводят к каскадным сбоям, нестабильной задержке и трудностям в поддержке кода. Эта статья предлагает практические паттерны, включая публикацию/подписку, точечные очереди, пулы рабочих потоков и обработку "загадочных" сообщений через Dead Letter Queues (Dlq), с акцентом на производственные ограничения и риски.

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

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

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

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

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

Building Scalable Supply Chain Visibility: Architecture Patterns for Multi-Protocol Asset Tracking

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

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

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

  1. Разделение по среде: использование RFID/BLE/NFC для внутренних складов, GPS/LoRaWAN/NB-IoT для внешних маршрутов и телеметрии в условиях ограниченной связи.
  2. Фильтрация на уровне датчиков: датчики и гатвеи обрабатывают данные локально, передавая только критические события (например, резкий скачок температуры или нарушение геозоны).
  3. Использование распределённых брокеров событий (Kafka, Kinesis) и баз данных временных рядов (TimescaleDB, InfluxDB) для обработки потоков данных без задержек.
  4. Обеспечение целостности данных через идемпотентность и индексацию пространственных данных (PostGIS, Redis) для быстрого определения нарушений геозон.
  5. Интеграция с ERP и WMS через REST/GraphQL-интерфейсы или вебхуки для синхронизации в реальном времени.

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

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

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

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

Senior Engineer, Haven't Interviewed in Years? What Changed and an 8-Week Plan

Открыть оригинал ↗ Перевод заголовка: Старший инженер, не проводил интервью уже годы? Что изменилось и 8-недельный план

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

  1. Практикуйте интервью на уровне, который вы хотите достичь — используйте инструменты, которые адаптируют вопросы и оценку под ваш уровень (Junior, Mid/Senior, Staff/Lead).
  2. Начните с полного мок-интервью в области, где вы чувствуете наименьшую уверенность, чтобы оценить, насколько "закисло" ваше мастерство.
  3. Следуйте структуре: изучайте паттерны (NeetCode 150), затем системное проектирование (Hello Interview), рассказывайте истории о реальных проектах, включая неудачи и решения.
  4. Практикуйте полные мок-интервью с включением системного проектирования и поведенческих вопросов, постепенно увеличивая сложность.
  5. Уточняйте у рекрутера формат интервью — включает ли он AI-ассистента, и как именно проводятся сессии — это критично для подготовки.

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

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

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

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

Engineering a Modern Vehicle-Rental Marketplace: Architecture, Search, and UX Challenges

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

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

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

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

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

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

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

DesignGurus

PostgreSQL vs MySQL in System Design Interviews: Explain Your Choice and Its Trade-offs

Открыть оригинал ↗ Перевод заголовка: PostgreSQL vs MySQL в интервью по системному дизайну: объясните свой выбор и его компромиссы

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

  1. PostgreSQL лучше подходит для сложных запросов с JSON, полнотекстовым поиском, оконными функциями и материализованными представлениями — его расширенный индексный фреймворк (GIN, GiST, BRIN) позволяет эффективно работать с неструктурированными данными.
  2. MySQL выигрывает в производительности при высоких объёмах одновременных чтений и при простых, стабильных запросах благодаря лёгкой архитектуре на основе потоков и эффективной системе буферизации.
  3. PostgreSQL требует больше ресурсов при большом количестве соединений из-за процессного моделирования, что делает обязательным использование пулов (например, PgBouncer), в то время как MySQL эффективнее масштабируется под высокую нагрузку без дополнительных пуллеров.
  4. Вставка с UUID-ключами в MySQL может привести к фрагментации и снижению производительности из-за дисперсии в B-дереве, в PostgreSQL такой эффект минимальный из-за отсутствия кластеризованного индекса.
  5. Для систем с высокой нагрузкой на чтение и простотой управления — MySQL; для систем с сложными аналитическими запросами, расширенными типами данных и требованием точности — PostgreSQL.

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

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

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

  1. Какой из двух подходов — кластеризованный индекс в MySQL или хэп-хранилище в PostgreSQL — будет более эффективным при работе с большими таблицами, где ключи вставляются случайным образом, и как это влияет на производительность в условиях высокой частоты вставок?
  2. В каких сценариях производительность MySQL может быть уступать PostgreSQL несмотря на более простую архитектуру, и как это связано с особенностями индексов и типов данных?
  3. Какой из двух подходов к логированию (WAL vs redo + binary log) обеспечивает лучшую отказоустойчивость при сбое сервера и как это влияет на время восстановления после сбоя в production-среде?

Coding / Algorithms

DEV Data Structures

Java Collections Framework Explained Simply

Открыть оригинал ↗ Перевод заголовка: Простое объяснение Java Collections Framework

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

  1. Программирование по интерфейсам (например, Collection) позволяет легко заменять реализации (например, ArrayList на HashSet) без изменения кода.
  2. Каждая коллекция может быть безопасно итерирована, но при изменении во время итерации возникает ConcurrentModificationException — для этого нужно использовать Iterator или метод removeIf.
  3. Ключевые структуры: Map для поиска по ключу, Set для уникальных элементов, List для упорядоченных данных, Queue/Deque для очередей и стеков.
  4. Алгоритмы из Collections (например, sort, binarySearch, max) работают на любых List, но требуют, чтобы список был отсортирован перед использованием binarySearch.
  5. Для корректной работы с ключами в HashMap или HashSet необходимо переопределить equals() и hashCode() в собственных классах, иначе поиски не сработают.

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

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

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

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

Part 6: Quotient Filters - the Theory

Открыть оригинал ↗ Перевод заголовка: Часть 6: Фильтры-частные — теория

Фильтры-частные (Quotient Filters) решают проблему удаления элементов, которая ограничивает традиционные фильтры, такие как Bloom. В отличие от них, QF вычисляет один хеш-значение и делит его на квоту (индекс) и остаток (фингерпринт), хранящийся в соответствующем слоте. Структура использует метаданные — три бита на слот — для отслеживания состояния: заполненность, непрерывность и смещение элемента, что позволяет поддерживать удаление без увеличения памяти. Операции поиска, добавления и удаления строятся на поиске соответствующего квота, идентификации последовательности (run) и перестройке слотов при изменении данных.

  1. QF использует один хеш-значение, разделяя его на квоту и остаток, что позволяет сохранять информацию о позиции и идентификаторе элемента, обеспечивая возможность удаления без потери точности.
  2. Метаданные на каждом слоте (isOcc, isCont, isShifted) позволяют определить, где начинается run, как он продолжается и где элемент был смещен, что критично для корректного поиска и удаления.
  3. Структура организует runs в порядке возрастания квот, и при наличии циклической структуры (вращение по слотам) необходимо учитывать переходы между концом и началом таблицы.

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

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

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

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

DEV LeetCode

Solved 300 LeetCode Problems but Still Freeze in Interviews? It's a Rehearsal Problem

Открыть оригинал ↗ Перевод заголовка: Решал 300 задач LeetCode, но всё равно замерзаю на собеседованиях? Это проблема тренировки, а не знаний

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

  1. Всегда объясняйте каждую задачу вслух: переформулируйте условие, пройдите пример, назовите жёсткий подход и его сложность, затем улучшите его — это тренирует навык пошагового мышления под давлением.
  2. Освойте сценарий "заблуждения": при срыве в мыслях не молчать — просто перечитайте ввод/вывод, решите мини-пример вручную, назовите брутальный подход или задайте уточняющий вопрос.
  3. Практикуйте интервью под наблюдением: проводите полноценные, тайм-контролируемые сессии, начиная за несколько недель до собеседования, а не в последний день.
  4. Повторяйте до тех пор, пока процесс не становится скучным — 10–15 полноценных сессий в течение 2–3 недель, чтобы привыкнуть к формату и снизить психологическую реакцию на давление.

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

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

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

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

LeetCode.ca Solutions

4038 - Count Integers Appearing in a Single Block

Открыть оригинал ↗ Перевод заголовка: 4038 - Считать целые числа, встречающиеся в одном блоке

Данная задача требует определить количество различных целых чисел, все вхождения которых находятся в одном последовательном блоке. Для этого в массиве идёт проход по элементам, где отслеживается начало нового блока (когда значение отличается от предыдущего), и подсчитывается количество вхождений каждого числа в отдельном блоке. Если число встречается только один раз в каком-то блоке, оно считается "специальным". Результат — количество таких чисел, у которых в ходе подсчёта блоков было ровно одно вхождение.

  1. При проходе по массиву отслеживается начало каждого блока посредством сравнения текущего и предыдущего элемента.
  2. Для каждого значения создаётся счётчик, который увеличивается только при начале нового блока.
  3. После завершения прохода подсчитывается количество значений, у которых счётчик равен 1.
  4. Максимальное значение в массиве ограничено 100, поэтому можно использовать массив размером 101 для хранения частот.
  5. Алгоритм работает за линейное время и пространство, что делает его эффективным для заданных ограничений.

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

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

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

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