Первые отзывы на новинки о System Design
Привет, Хаброжители! Спешим поделится с вами первыми рецензиями на предзаказы: «System Design. Проектирование мобильных систем. Подготовка к сложному интервью» и «Object Oriented Design. Подготовка к сложному интервью».
https://habr.com/ru/companies/piter/articles/1037222/
#system_design #подготовка_к_собеседованию #техническое_собеседование #ood #проектирование_систем #предзаказ #ооп
[Перевод] System Design: проектируем Dropbox, сервис для хранения и обмена файлами
Самая интересная часть в проектировании Dropbox — не хранение метаданных, а работа с самими файлами: как загружать большие объекты без перегрузки своих серверов, как возобновлять загрузку после обрыва и как быстро синхронизировать изменения с другими устройствами. В статье подробно разберём, как всё это складывается в работающую архитектуру облачного хранилища.
https://habr.com/ru/articles/1032184/
#system_design #backend #highload #подготовка_к_собеседованию #распределенные_системы #архитектура #проектирование_систем #системный_дизайн #паттерны_проектирования #собеседования_задачи
Тайна общей тарелки или System Design дачного шашлыка на 20 гостей
Дядя Петя съедает 12% всего шашлыка. Backend-инженер видит классический hot key в multi-tenant. Дачный шашлык на 20 гостей это producer-consumer система с общей тарелкой как bounded buffer . 8-часовой маринад работает как pre-warm cache с TTL. Шампуры это connection pool с риском утечки. Соседская собака утащила мясо, и это unhandled storage failure без backup’а. Шеф приостанавливается при полной тарелке, чистый backpressure . Парные сравнения альтернатив, таблица failure modes, измерения с дачи, ссылки на DDIA и Release It!. Принципы те же что в backend, инструменты другие.
https://habr.com/ru/articles/1034968/
#системный_анализ #архитектура #backend #system_design #шашлык #майские_праздники
Почему spec-driven development плохо работает на микросервисах: часть 1. Где теряется контекст
Я работаю в большой продуктовой компании с тысячей микросервисов. В такой системе даже небольшая фича часто проходит через несколько сервисов, событий и внутренних контрактов. Spec-driven development с LLM уже применяется в некоторых командах для планирования и ревью фич, поэтому мне было важно понять, где этот подход помогает, а где начинает ошибаться. Пока задача живёт внутри одного сервиса, всё обычно идёт быстро: спека короткая, описание и реализация помещаются в контекст модели. Но как только фича проходит через несколько сервисов, начинаются проблемы. По отдельности каждый кусок выглядит нормально: разбиение на слои, именование по код стайлу, прохождение тестов и ревью. Но в целом система не работает должным образом. Типичные ошибки: нет идемпотентности, LLM упускает сценарии и edge case-ы, появляются циклические вызовы сервисов. Чем больше делаешь правок, тем больше ошибок она допускает. Для эксперимента я собрал отдельный стенд: Go-проект - платформа для поиска фрилансеров . Внутри 12 микросервисов, связанных через gRPC и брокер сообщений; в этом проекте брокером выступает NATS. Одни сервисы хранят задачи и профили исполнителей, другие подбирают кандидатов, считают расстояния, проверяют портфолио и отправляют уведомления. Проект специально спроектирован с шестью категориями архитектурных ловушек: они проявляются не внутри одного сервиса, а на границах между сервисами. Фича для эксперимента была такой: если выбранный фрилансер отказался от оффера, платформа должна автоматически найти следующего подходящего кандидата, отправить ему новый оффер и уведомить заказчика о переназначении. Claude написал спеку, реализацию и юнит-тесты, но полный сценарий отказа и переназначения не сошёлся. Два независимых ревью нашли одну и ту же группу ошибок: по отдельности сервисы выглядели нормально, а вместе работали не так, как нужно. На это можно ответить, что нужен end-to-end тест на весь сценарий, но это не закрывает проблему целиком. End-to-end тесты есть не везде, их дорого поддерживать, и они не покрывают все развилки: особенно редкие edge case-ы, дубликаты событий, гонки и редкие комбинации условий. Главное же в другом: на этапе spec-driven разработки модель должна помочь собрать требования, ограничения и контекст, а именно там она часто ошибается. Разработчик тоже не всегда заранее знает, где спрятана проблема. Он может помнить про Outbox, дедупликацию уведомлений или особые требования конкретного сервиса к входным данным, но не сформулировать это как ограничение для новой фичи. LLM читает документы по сервисам, задаёт уточняющие вопросы и всё равно может пропустить связь между ними. В итоге спека получается подробной, но неполной: в ней есть локальные изменения по сервисам, зато нет системных инвариантов, которые живут между сервисами. Реализация может быть нормально разложена по слоям, тесты отдельных компонентов проходят, а ошибка обнаруживается уже на уровне сценария или ревью. Где LLM теряет контекст
https://habr.com/ru/articles/1033510/
#claude_code #specdriven_development #microservices #system_design #llm #архитектура #code_review #go #clean_architecture
[Перевод] System Design: проектируем сервис быстрых знакомств
Tinder — это хороший пример system design задачи, где нужно быстро формировать ленту кандидатов, учитывать геолокацию и пользовательские предпочтения, а также надёжно обрабатывать свайпы и совпадения. В статье разберём архитектуру такого сервиса и узкие места, которые появляются при росте нагрузки.
https://habr.com/ru/articles/1026316/
#system_design #backend #highload #подготовка_к_собеседованию #распределенные_системы #архитектура #проектирование_систем #системный_дизайн #паттерн_проектирования #собеседования_задачи
[Перевод] System Design: проектируем сервис заказа такси
Uber — это хороший пример System Design задачи, где сочетаются geo-search, real-time уведомления, многошаговый workflow и строгие требования к согласованности. В статье разберём, как проектировать такую систему, чтобы она быстро находила водителей поблизости, гарантировала назначение водителю только одной поездки и выдерживала пиковую нагрузку.
https://habr.com/ru/articles/1022478/
#system_design #backend #highload #подготовка_к_собеседованию #распределенные_системы #архитектура #проектирование_систем #системный_дизайн #паттерны_проектирования #собеседования_задачи
Потоковая обработка данных на С
Привет, Хабр! Кратко о том что такое потоковая обработка данных и в чем её отличие от пакетной. Пакет данных, это часть информации поступающая в систему которая содержит законченный или не полный фрагмент данных. Большинство механизмов цифровой передачи информации в современных системах построены на пакетной передаче. Отличие потоковых и пакетных систем обработки в том...
System Design. Как пройти в любую компанию
Привет, Хабр! Хочу поделиться своим опытом прохождения Системного Дизайна (aka System Design) в Бигтех . От первых шагов и провалов до успешно пройденной секции. Лично мне изначально эта секция показалась попроще чем алгоритмы. В целом я до сих пор так думаю, но проще – это не значит просто . Что же кроется в мелочах? Давайте разберемся.
https://habr.com/ru/articles/1019726/
#бигтех #faang_собеседования #system_design #собеседования_разработчика #собеседования_в_it
Как я в одиночку сделал систему аналитики для Clubs в EA FC, потому что нормальной статистики там просто нет
Начну с контекста. Я играю в EA FC (ранее FIFA) в режиме Clubs (11×11), где каждым виртуальным игроком управляет человек. Сам по себе режим интересный, но мне, как человеку, который любит цифры и аналитику, довольно быстро стало не хватать доступной статистики. Я пришёл в лигу, у которой уже был свой сайт (я в этой статье опущу тему о том, что я администрировал проект порядка 3 лет). Там статистику собирали вручную: люди пересматривали записи матчей и заносили базовые показатели — голы, ассисты, перехваты, отборы и так далее. На основе этих данных считались различные рейтинги: лучшие игроки, бомбардиры, разрушители и прочее. Выглядело это примерно так: набор таблиц, где действия сгруппированы по категориям и амплуа.
https://habr.com/ru/articles/1019286/
#EA_FC #clubs #футбольная_аналитика #статистика #анализ_данны #метрики #nextjs #mysql #петпроект #system_design
Начну с контекста. Я играю в EA FC (ранее FIFA) в режиме Clubs (11×11), где каждым виртуальным игроком управляет человек. Сам по себе режим интересный, но мне, как человеку, который любит цифры и...
[Перевод] Разбор задач по System Design. Проектируем Ticketmaster
Разбираем, как спроектировать систему бронирования билетов на интервью по System Design. Обсудим, как избежать двойных бронирований, справиться с большим объемом чтения, обновлять карту мест в реальном времени и ускорить поиск мероприятий.
https://habr.com/ru/articles/1018516/
#system_design #архитектура #распределенные_системы #проектирование_систем #интервью #собеседование #системный_дизайн #паттерны_проектирования
Habr
