Всем привет! Меня зовут Наташа, и я системный аналитик. Сейчас я в поиске работы, сходила на пару собеседований, и хочу описать ответы на некоторые вопросы, которые там встречались - некая рефлексия для меня, и надеюсь, эти короткие статьи будут полезны и еще кому-то.
В этой статье я делюсь реальным кейсом построения системы рекомендаций для картин. Сначала мы реализовали простой поиск по тегам, а затем перешли к эмбеддингам изображений с помощью CLIP и хранению в Elasticsearch. Также я показываю, как строим персонализированные рекомендации на основе лайков и просмотров пользователя. Статья будет полезна тем, кто хочет понять, как создать рабочую систему рекомендаций на Python и постепенно улучшать её точность.
В микросервисной архитектуре один падающий эндпоинт может скрывать проблему в совершенно другом сервисе. В этой статье я покажу пошаговый процесс расследования реального инцидента: от обнаружения 100% error rate до точной причины сбоя — и всё это менее чем за минуту.
Мы будем использовать Uptrace - OpenTelemetry-native платформу для трейсинга и мониторинга. Все примеры основаны на реальном demo-приложении с микросервисами.
Раньше наш способ собрать данные из всех микросервисов в одно место (в витрину) напоминал копролит (только не древний, а наш собственный ИТ-артефакт). Он был сложный, медленный, постоянно ломался и требовал много ручной работы. Данные размазывались по куче баз данных. Чтобы сделать отчёт или отправить данные во внешнюю систему, надо было собирать их вместе.
Высока вероятность, что у вас такой же или похожий. Если нет — приходите рассказать «а я же говорил» в комментариях.
Мы тратили время на латание дыр, а не на разработку. В какой-то момент решили, что пора выкинуть этот велосипед и внедрить нормальный, промышленный подход к работе с данными — Data Lakehouse с медальонной архитектурой.
«Сделайте нам строго по порядку» — эта фраза из бизнес‑требований часто становится началом долгого и дорогого инженерного триллера. В мире микросервисов и event‑driven систем классический FIFO превращается из простой очереди в проверку на прочность всей архитектуры. За обещанием «строгой последовательности» стоят сетевые задержки, алгоритмы консенсуса и суровые ограничения распределенных систем.
Один разработчик, один AI-напарник (Claude), ноль инвесторов. Рассказываю, как за 4 месяца я построил платформу автоматизации контент-маркетинга с 14 микросервисами, собственной очередью задач на SQLite вместо Redis, мультимодельным AI (MiniMax, YandexGPT, Replicate) и circuit breaker для автоматического fallback между провайдерами. Всё на одном сервере, всё через npm install.
Почему использование JSON как формата сообщений может стать узким местом в высоконагруженных системах? Что такое Apache Avro и Schema Registry?
Простым языком об этих технологиях, их работе и причинах их возникновения.
Для российских компаний выбор между серверами приложений на базе Apache Tomcat и WildFly давно перестал быть спором о «любимом стеке разработчиков». Это стратегическое решение, влияющее на устойчивость бизнес‑сервисов, стоимость владения ИТ‑ландшафтом и способность пройти путь импортозамещения без рисков для критичных систем.
В современных условиях ИТ‑инфраструктура почти всегда неоднородна: рядом живут легкие веб‑сервисы и тяжелые транзакционные ядра, экспериментальные микросервисы и строго регламентированные системы, попадающие под КИИ. В такой среде попытка «посадить все на один тип сервера приложений» приводит либо к избыточной сложности, либо к ограничениям по функционалу и масштабируемости.
Гораздо продуктивнее смотреть на сервер приложений на базе Apache Tomcat и сервер приложений на базе WildFly как на два разных типа решений под разные задачи – и выстраивать платформу, которая позволяет использовать оба подхода в едином управляемом контуре.
«Значит, смотрите. Payment-service ходит в booking-service, но только через API gateway, который дёргает auth-service, а тот валидирует токен в Redis, который шарит с notification-service…» — вы, объясняя архитектуру новому разработчику.
Десять лет мы разматывали нитки между сервисами на доске, как Чарли из «В Филадельфии». 42% компаний уже тихо сворачивают микросервисы обратно. Istio не осилил микросервисную архитектуру собственного control plane. Бывший CTO GitHub называет это «главной архитектурной ошибкой десятилетия».
А потом пришёл AI, которому не нужны ни митинг на 15 человек, ни три года в проекте, чтобы понять, почему бронирование — это цепочка из 12 HTTP-вызовов вместо одного function call.
Разбираю шесть причин дробления монолитов. Спойлер: половину из них AI уже отменил.
Что будет, если больше 200 бэкенд‑разработчиков запускают по 2–3 новых проекта в неделю в более чем 400 микросервисов, написанных на пяти разных языках — C++, Go, Python, Java и PHP? Ответ хорошо знаком любому, кто сталкивался с быстрорастущей распределённой системой: хаос появляется быстрее, чем успеваешь его отлавливать. И в какой‑то момент становится очевидно, что нужна надёжная точка контроля, чтобы поддерживать архитектуру в рабочем состоянии.
В Яндекс Еде этой точкой стало архитектурное ревью — процесс, который постепенно вырос из локальной инициативы в полноценный инструмент управления сложной системой. В этой статье я расскажу, как эволюционировало архревью, какие инсайты появились по пути и как этот процесс выглядит сегодня.
Всем привет, уважаемые читатели! В архитектуре проектов мы можем наблюдать применение паттерна BFF (Backend for frontend). При этом BFF может быть в архитектуре, где есть взаимодействие с клиентскими приложениями: веб, мобильное, смарт-устройства и т.д, но может быть всего-навсего один служебный фронтенд, доступ к которому возможен во внутрикорпоративном сегменте, например, банковская система, hr, логистика. Кажется, что при наличии одного фронтенда введение BFF избыточно.
И возникает закономерный вопрос: если клиент всего один, да еще и работает внутри защищенного контура, зачем нам плодить отдельные компоненты системы? Не превращается ли BFF в лишний прокси-сервис, который только пробрасывает запрос и добавляет сетевую задержку?
Но что, если фронтенд один и вдруг нуждается в данных из разных API системы, чтобы нормально функционировать? При этом запросы могут быть сложными: каждый требует особых параметров и возвращает много лишней информации. А если у вас несколько клиентских приложений и так же нужно подтягивать данные из разных API?
В данной статье хочу поделиться своим опытом по абстрактным классам. Думаю это будет полезно как разработчикам, только начинающим свой путь, так и уже имеющим опыт.
В материале можно посмотреть, как изящно связать свойства и абстрактные классы с реализацией принципа DRY .
Для начал кратко пробежимся по определениями и терминам, и далее ответим на вопросы, которые могут логично вытекать из этих определений.
Абстрактные классы - это базовые классы, определяющие каркас с методами, обязательными для реализации в наследниках и служащими для создания интерфейсов, однако сами экземпляры таких классов создать нельзя.
Абстрактные методы - методы с декоратором @abstractmethod, которые обязаны быть реализованы в дочерних классах.
Абстрактный класс может содержать как обычные, так и абстрактные методы.
Свойство - реализуется через декораторы @property (для чтения) и @<name>.setter (для изменения и валидации) обеспечивая инкапсуляцию, делая API удобным, при этом позволяя менять внутреннюю реализацию без изменения внешнего кода.
В современном финтехе скорость, надежность и глубина предоставляемой информации особенно важны. За интуитивно понятным интерфейсом, который видит трейдер, скрывается сложная архитектура из взаимосвязанных сервисов, отвечающих за сбор, обработку и доставку рыночных данных в реальном времени. Мы — команда MarketData компании «Финам», в этой статье мы рассказываем, как устроена наша система изнутри.
Микросервисная архитектура давно стала стандартом для распределённых систем, но её устойчивость определяется не количеством сервисов, а качеством их декомпозиции. В этой статье разберём, как выделять доменные границы, проектировать автономные сервисы и выстраивать коммуникации между ними на примере интернет-магазина. Речь пойдёт о принципах, которые позволяют системе масштабироваться без потери управляемости и предсказуемости.
Проблема: никто не знает, кто кого вызывает
В 2012 году биржевой брокер Knight Capital потерял $460 миллионов за 45 минут.
Причина — активация устаревшего модуля, который начал массово размещать ордера.
Отчёт SEC указал на ключевую ошибку:
Для кого статья: для техлидов и системных аналитиков (SA), архитекторов ПО.
О чём статья: об использовании некоторых удобных, современных подходов к проектированию ПО на стеке Java-Spring в enterprise в условиях большого количества команд и большой неопределенности.
Об авторе: лид стрима в облачном провайдере, в 2024-2025 гг. с коллегами разрабатывавший подходы к архитектуре микросервисов.
В условиях современной разработки, когда компании растут, а команды распределены по офисам и странам, классические подходы к проектированию часто становятся узким местом. Хаос в интеграциях, бесконечные согласования форматов данных и конфликты из-за изменений в API — это знакомые боли для многих архитекторов и тимлидов. Если вы тоже сталкивались с трудностями и конфликтами при разработке платформ с множеством микросервисов или хотите разрабатывать и не хотите сталкиваться – эта статья будет наверняка интересна.
Разбираем на практике, как гарантировать доставку сообщений в Kafka/RabbitMQ без распределенных транзакций, используя паттерн Transactional Outbox.
В этой статье рассмотрим наиболее полную реализацию паттерна Transactional Outbox, которую можно будет легко расширять и применять в продакшне. Данная статья будет полезна как для разработчиков, которые еще не встречались с данным паттерном, так и тем, кто уже применял его в своей работе.
Всем привет! Меня зовут Максим, я Go-разработчик в Wildberries & Russ. В высоконагруженных системах сотни сервисов взаимодействуют ежесекундно, и любой малейший простой системы напрямую влияет на прибыль бизнеса. Чтобы уметь быстро находить причины и устранять их за короткие сроки придуманы инструменты, обеспечивающие наблюдаемость приложения. Сегодня поговорим о том, как обеспечить observability и почему без нее жизнь продукта превращается в «черный ящик».
Transactional outbox обычно внедряют ради консистентности, а в итоге получают новый источник «случайной» задержки и постоянный фон нагрузки на базу из-за поллинга. В этой короткой статье разберем простой поворот идеи: не выбрасывая outbox и relay-процесс, попробовать отправлять событие сразу после коммита и превращать поллинг в редкий fallback. Посмотрим, что это даёт по задержкам и нагрузке, и какие неприятные нюансы всплывают с порядком доставки, дублями и наблюдаемостью.
Два месяца назад я писал на Хабр о первом релизе Funxy — гибридного языка программирования. Тогда это был эксперимент по созданию своего языка с выводом типов, императивного, с функциональными возможностями.
С тех пор вышло несколько релизов. Мы исправили много ошибок, переписали рантайм и добавили недостающие инструменты. Хочу рассказать, что изменилось.
Стабильность: десятки багфиксов — падения на валидном коде, рекурсия, edge-кейсы VM
Рантайм: tree-walk интерпретатор → стековая VM (быстрее, легче по памяти)
Язык: const, return, лямбды (\x -> x + 1), list comprehensions, block syntax для DSL
Типы: strict mode, flow-sensitive typing
Тулинг: LSP и дебаггер
Embedding: встраивание Funxy в Go-приложения как скриптовый движок
