#system_design — Public Fediverse posts

Книга: «System Design. Проектирование мобильных систем. Подготовка к сложному интервью»

Привет, Хаброжители! Что вас ждет на интервью по проектированию мобильных систем (MSD)? Что делать, если вас попросят разработать новый YouTube или телеграм? Практическое руководство MSD превращает сложные собеседования в предсказуемый процесс. Вы получаете 5-шаговую схему эффективного прохождения интервью и разбор 7 реальных кейсов (лента новостей, мессенджер, YouTube, Google Drive, трейдинговая платформа и др.), позволяющих проектировать архитектуру клиента, API, офлайн-режим, кэширование и масштабируемость. Здесь вы найдете готовые шаблоны, trade-off’ы и шпаргалки — всё, чтобы уверенно проходить интервью в топ-компаниях и расти от мидла до стафф+.

https://habr.com/ru/companies/piter/articles/1039648/

#system_design #сюй #мобильная_разработка #вебразработка #котлин #kotlin

Первые отзывы на новинки о System Design

Привет, Хаброжители! Спешим поделится с вами первыми рецензиями на предзаказы: «System Design. Проектирование мобильных систем. Подготовка к сложному интервью» и «Object Oriented Design. Подготовка к сложному интервью».

https://habr.com/ru/companies/piter/articles/1037222/

#system_design #подготовка_к_собеседованию #техническое_собеседование #ood #проектирование_систем #предзаказ #ооп

Первые отзывы на новинки о System Design

Привет, Хаброжители! Спешим поделится с вами первыми рецензиями на предзаказы: «System Design. Проектирование мобильных систем. Подготовка к сложному интервью» и «Object Oriented Design. Подготовка к сложному интервью».

https://habr.com/ru/companies/piter/articles/1037222/

#system_design #подготовка_к_собеседованию #техническое_собеседование #ood #проектирование_систем #предзаказ #ооп

Первые отзывы на новинки о 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

Почему 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

Почему 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

Почему 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: проектируем сервис быстрых знакомств

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

https://habr.com/ru/articles/1026316/

#system_design #backend #highload #подготовка_к_собеседованию #распределенные_системы #архитектура #проектирование_систем #системный_дизайн #паттерн_проектирования #собеседования_задачи

[Перевод] System Design: проектируем сервис быстрых знакомств

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

https://habr.com/ru/articles/1026316/

#system_design #backend #highload #подготовка_к_собеседованию #распределенные_системы #архитектура #проектирование_систем #системный_дизайн #паттерн_проектирования #собеседования_задачи

[Перевод] 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 #подготовка_к_собеседованию #распределенные_системы #архитектура #проектирование_систем #системный_дизайн #паттерны_проектирования #собеседования_задачи

Потоковая обработка данных на С

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

https://habr.com/ru/articles/1023522/

#C #Linux #system_design #highload

System Design. Как пройти в любую компанию

Привет, Хабр! Хочу поделиться своим опытом прохождения Системного Дизайна (aka System Design) в Бигтех . От первых шагов и провалов до успешно пройденной секции. Лично мне изначально эта секция показалась попроще чем алгоритмы. В целом я до сих пор так думаю, но проще – это не значит просто . Что же кроется в мелочах? Давайте разберемся.

https://habr.com/ru/articles/1019726/

#бигтех #faang_собеседования #system_design #собеседования_разработчика #собеседования_в_it

System Design. Как пройти в любую компанию

Привет, Хабр! Хочу поделиться своим опытом прохождения Системного Дизайна (aka System Design) в Бигтех . От первых шагов и провалов до успешно пройденной секции. Лично мне изначально эта секция показалась попроще чем алгоритмы. В целом я до сих пор так думаю, но проще – это не значит просто . Что же кроется в мелочах? Давайте разберемся.

https://habr.com/ru/articles/1019726/

#бигтех #faang_собеседования #system_design #собеседования_разработчика #собеседования_в_it

System Design. Как пройти в любую компанию

Привет, Хабр! Хочу поделиться своим опытом прохождения Системного Дизайна (aka System Design) в Бигтех . От первых шагов и провалов до успешно пройденной секции. Лично мне изначально эта секция показалась попроще чем алгоритмы. В целом я до сих пор так думаю, но проще – это не значит просто . Что же кроется в мелочах? Давайте разберемся.

https://habr.com/ru/articles/1019726/

#бигтех #faang_собеседования #system_design #собеседования_разработчика #собеседования_в_it

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

[Перевод] Разбор задач по System Design. Проектируем Ticketmaster

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

https://habr.com/ru/articles/1018516/

#system_design #архитектура #распределенные_системы #проектирование_систем #интервью #собеседование #системный_дизайн #паттерны_проектирования

Книга: «Интервью по машинному обучению. 151 вопрос от FAANG»

Привет, Хаброжители! Хотите построить карьеру в области ML? Воспользуйтесь опытом и советами Пенга Шао, чтобы научиться тому, как успешно пройти собеседование по машинному обучению. Книга охватывает весь процесс подготовки к интервью: от базовых концепций ML и программирования до проектирования сложных систем и инфраструктуры. Практические примеры, стратегии ответов на типичные вопросы и советы по прохождению различных этапов интервью помогут вам уверенно справиться как с техническим телефонным скринингом, так и с углубленным обсуждением моделей и оценок. Независимо от уровня — новичок вы или опытный специалист — эта книга станет вашим надежным навигатором в мире ML-собеседований, сочетая теорию, практику и реальные инсайты от экспертов.

https://habr.com/ru/companies/piter/articles/1017908/

#книги_по_программированию #глубокое_обучение #машинное_обучение #ML #system_design #Алекс_Сюй #faang #faang_собеседования

Как поход в кино превратился в сессию системного дизайна

Недавно ходил в кино и, пока стоял в очереди на вход, поймал себя на мысли, что проектирую систему, которой пользуется контролер. На первый взгляд задача примитивная: есть база билетов, контролер сканирует QR, система должна проверить билет и пустить человека. Главное условие - один билет используется ровно один раз. Я прикинул, и понял, что проблем там гораздо больше, чем кажется ..

https://habr.com/ru/articles/1017332/

#distributed_systems #распределенные_системы #проектирование_систем #system_design #software_engineering #postgresql #разработка_программного_обеспечения #idempotency #backend #backendразработка

Как поход в кино превратился в сессию системного дизайна

Недавно ходил в кино и, пока стоял в очереди на вход, поймал себя на мысли, что проектирую систему, которой пользуется контролер. На первый взгляд задача примитивная: есть база билетов, контролер сканирует QR, система должна проверить билет и пустить человека. Главное условие - один билет используется ровно один раз. Я прикинул, и понял, что проблем там гораздо больше, чем кажется ..

https://habr.com/ru/articles/1017332/

#distributed_systems #распределенные_системы #проектирование_систем #system_design #software_engineering #postgresql #разработка_программного_обеспечения #idempotency #backend #backendразработка

Как поход в кино превратился в сессию системного дизайна

Недавно ходил в кино и, пока стоял в очереди на вход, поймал себя на мысли, что проектирую систему, которой пользуется контролер. На первый взгляд задача примитивная: есть база билетов, контролер сканирует QR, система должна проверить билет и пустить человека. Главное условие - один билет используется ровно один раз. Я прикинул, и понял, что проблем там гораздо больше, чем кажется ..

https://habr.com/ru/articles/1017332/

#distributed_systems #распределенные_системы #проектирование_систем #system_design #software_engineering #postgresql #разработка_программного_обеспечения #idempotency #backend #backendразработка

Как поход в кино превратился в сессию системного дизайна

Недавно ходил в кино и, пока стоял в очереди на вход, поймал себя на мысли, что проектирую систему, которой пользуется контролер. На первый взгляд задача примитивная: есть база билетов, контролер сканирует QR, система должна проверить билет и пустить человека. Главное условие - один билет используется ровно один раз. Я прикинул, и понял, что проблем там гораздо больше, чем кажется ..

https://habr.com/ru/articles/1017332/

#distributed_systems #распределенные_системы #проектирование_систем #system_design #software_engineering #postgresql #разработка_программного_обеспечения #idempotency #backend #backendразработка

Метод Компонентов – Роскошный максимум инженерии

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

https://habr.com/ru/articles/1014448/

#ddd #maven #gradle #msbuild #system_design #architecture #Component_Method

Метод Компонентов – Роскошный максимум инженерии

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

https://habr.com/ru/articles/1014448/

#ddd #maven #gradle #msbuild #system_design #architecture #Component_Method

Как я проектирую OLTP-БД с нуля: принципы, trade-off'ы и архитектурные решения

Почему эксплуатация современных баз данных всё чаще напоминает сборку сложного карточного домика, я уже разбирал в прошлых статьях. Теперь самое интересное: как построить движок, чтобы этих проблем избежать. В этой статье я открываю капот своей OLTP-базы данных, которую пишу с нуля на Rust. Это не обзор готового коробочного решения, а честный рассказ про инжиниринг на раннем этапе. Я покажу, как абстрактные идеи вроде «fail-closed контрактов» превращаются в работающий код, почему я выбрал UNDO-log MVCC вместо Multi-version Heap и зачем всё это упаковывается в PostgreSQL-wire протокол. Архитектура ещё подвижна, и сейчас — лучшее время, чтобы обсудить её с теми, кто каждый день эксплуатирует БД в продакшене. Заглянуть под капот движка

https://habr.com/ru/articles/1014098/

#базы_данных #СУБД #архитектура_бд #Rust #OLTP #MVCC #undolog #PostgreSQL #разработка_субд #system_design

Как я проектирую OLTP-БД с нуля: принципы, trade-off'ы и архитектурные решения

Почему эксплуатация современных баз данных всё чаще напоминает сборку сложного карточного домика, я уже разбирал в прошлых статьях. Теперь самое интересное: как построить движок, чтобы этих проблем избежать. В этой статье я открываю капот своей OLTP-базы данных, которую пишу с нуля на Rust. Это не обзор готового коробочного решения, а честный рассказ про инжиниринг на раннем этапе. Я покажу, как абстрактные идеи вроде «fail-closed контрактов» превращаются в работающий код, почему я выбрал UNDO-log MVCC вместо Multi-version Heap и зачем всё это упаковывается в PostgreSQL-wire протокол. Архитектура ещё подвижна, и сейчас — лучшее время, чтобы обсудить её с теми, кто каждый день эксплуатирует БД в продакшене. Заглянуть под капот движка

https://habr.com/ru/articles/1014098/

#базы_данных #СУБД #архитектура_бд #Rust #OLTP #MVCC #undolog #PostgreSQL #разработка_субд #system_design

Как я проектирую OLTP-БД с нуля: принципы, trade-off'ы и архитектурные решения

Почему эксплуатация современных баз данных всё чаще напоминает сборку сложного карточного домика, я уже разбирал в прошлых статьях. Теперь самое интересное: как построить движок, чтобы этих проблем избежать. В этой статье я открываю капот своей OLTP-базы данных, которую пишу с нуля на Rust. Это не обзор готового коробочного решения, а честный рассказ про инжиниринг на раннем этапе. Я покажу, как абстрактные идеи вроде «fail-closed контрактов» превращаются в работающий код, почему я выбрал UNDO-log MVCC вместо Multi-version Heap и зачем всё это упаковывается в PostgreSQL-wire протокол. Архитектура ещё подвижна, и сейчас — лучшее время, чтобы обсудить её с теми, кто каждый день эксплуатирует БД в продакшене. Заглянуть под капот движка

https://habr.com/ru/articles/1014098/

#базы_данных #СУБД #архитектура_бд #Rust #OLTP #MVCC #undolog #PostgreSQL #разработка_субд #system_design

Как я проектирую OLTP-БД с нуля: принципы, trade-off'ы и архитектурные решения

Почему эксплуатация современных баз данных всё чаще напоминает сборку сложного карточного домика, я уже разбирал в прошлых статьях. Теперь самое интересное: как построить движок, чтобы этих проблем избежать. В этой статье я открываю капот своей OLTP-базы данных, которую пишу с нуля на Rust. Это не обзор готового коробочного решения, а честный рассказ про инжиниринг на раннем этапе. Я покажу, как абстрактные идеи вроде «fail-closed контрактов» превращаются в работающий код, почему я выбрал UNDO-log MVCC вместо Multi-version Heap и зачем всё это упаковывается в PostgreSQL-wire протокол. Архитектура ещё подвижна, и сейчас — лучшее время, чтобы обсудить её с теми, кто каждый день эксплуатирует БД в продакшене. Заглянуть под капот движка

https://habr.com/ru/articles/1014098/

#базы_данных #СУБД #архитектура_бд #Rust #OLTP #MVCC #undolog #PostgreSQL #разработка_субд #system_design

Поиск с возвратом

Привет, Хаброжители! Мы открыли предзаказ на книгу «Паттерны Coding Interview. Подготовка к сложному техническому интервью» Алекса Сюя и Шона Гунавардана. Предлагаем ознакомиться с главой 14 «Поиск с возвратом». Основные понятия Представьте, что вы находитесь на перекрестке в лабиринте и знаете, что один из трех маршрутов впереди ведет к выходу:

https://habr.com/ru/companies/piter/articles/1011832/

#предзаказ #книги_по_программированию #system_design #интервью #собеседование #кодинг

[Перевод] О размерах пула соединений

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

https://habr.com/ru/companies/spring_aio/articles/1011770/

#java #kotlin #connection_pool #system_design #system_development #system_designer #spring #spring_boot #spring_framework #postgres

[Перевод] О размерах пула соединений

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

https://habr.com/ru/companies/spring_aio/articles/1011770/

#java #kotlin #connection_pool #system_design #system_development #system_designer #spring #spring_boot #spring_framework #postgres

[Перевод] О размерах пула соединений

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

https://habr.com/ru/companies/spring_aio/articles/1011770/

#java #kotlin #connection_pool #system_design #system_development #system_designer #spring #spring_boot #spring_framework #postgres

[Перевод] О размерах пула соединений

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

https://habr.com/ru/companies/spring_aio/articles/1011770/

#java #kotlin #connection_pool #system_design #system_development #system_designer #spring #spring_boot #spring_framework #postgres

[Перевод] Разница между параллельными и распределёнными вычислениями

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

https://habr.com/ru/companies/spring_aio/articles/1008990/

#system_design #consistency #distributed_computing #distributed_systems #distributed #parallels #parallelism #parallel_computing #spring #spring_boot

[Перевод] Разница между параллельными и распределёнными вычислениями

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

https://habr.com/ru/companies/spring_aio/articles/1008990/

#system_design #consistency #distributed_computing #distributed_systems #distributed #parallels #parallelism #parallel_computing #spring #spring_boot

[Перевод] Разница между параллельными и распределёнными вычислениями

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

https://habr.com/ru/companies/spring_aio/articles/1008990/

#system_design #consistency #distributed_computing #distributed_systems #distributed #parallels #parallelism #parallel_computing #spring #spring_boot

[Перевод] Разница между параллельными и распределёнными вычислениями

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

https://habr.com/ru/companies/spring_aio/articles/1008990/

#system_design #consistency #distributed_computing #distributed_systems #distributed #parallels #parallelism #parallel_computing #spring #spring_boot

Контракт вместо настроек: чего я жду от OLTP-БД

После первой статьи в комментариях несколько раз прозвучало примерно одно и то же: "Всё правильно, но это же про любую зрелую СУБД — что с этим делать?" Я думал над этим вопросом несколько недель. И в итоге решил не искать ответ в виде "возьмите правильный инструмент X" — а попробовать честно сформулировать: какими свойствами OLTP-БД должна обладать сама по себе , независимо от того, насколько хорош ваш оператор, консультант или runbook. Что такое "контракт" — и почему это не маркетинг Попробую объяснить не через определение, а через ощущение. Когда вы покупаете автомобиль, вы не читаете инструкцию к тормозам каждое утро. Вы просто знаете: нажал педаль — машина тормозит. Это контракт . Он не зависит от того, правильно ли вы настроили тормозную жидкость этим утром или не забыли включить "режим торможения" в меню.

https://habr.com/ru/articles/1007602/

#postgresql #rust #data_base #oltp #hiload #system_design #субд

[Перевод] Введение в модели согласованности

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

https://habr.com/ru/companies/spring_aio/articles/1006474/

#system #system_design #java #kotlin #consistency

[Перевод] Часы Лампорта

Сегодня мы живём в мире распределённых систем: Apache Kafka, Apache Spark, Apache Cassandra — это уже не экзотика, а повседневная инфраструктура продакшена. Сервисы пишут события, стримы обрабатываются в реальном времени, данные реплицируются по датацентрам. И почти в каждом таком сценарии возникает фундаментальный вопрос: Как понять, что произошло раньше, а что позже, если глобального времени не существует? Здесь в игру вступают логические часы Лампорта — простая, но концептуально мощная идея, лежащая в основе причинно-следственного порядка в распределённых системах. Подробнее - в новом переводе от команды Spring АйО .

https://habr.com/ru/companies/spring_aio/articles/1005934/

#java #kotlin #system #system_design #architecture #architecture_design #spring #spring_boot

[Перевод] Часы Лампорта

Сегодня мы живём в мире распределённых систем: Apache Kafka, Apache Spark, Apache Cassandra — это уже не экзотика, а повседневная инфраструктура продакшена. Сервисы пишут события, стримы обрабатываются в реальном времени, данные реплицируются по датацентрам. И почти в каждом таком сценарии возникает фундаментальный вопрос: Как понять, что произошло раньше, а что позже, если глобального времени не существует? Здесь в игру вступают логические часы Лампорта — простая, но концептуально мощная идея, лежащая в основе причинно-следственного порядка в распределённых системах. Подробнее - в новом переводе от команды Spring АйО .

https://habr.com/ru/companies/spring_aio/articles/1005934/

#java #kotlin #system #system_design #architecture #architecture_design #spring #spring_boot

[Перевод] Часы Лампорта

Сегодня мы живём в мире распределённых систем: Apache Kafka, Apache Spark, Apache Cassandra — это уже не экзотика, а повседневная инфраструктура продакшена. Сервисы пишут события, стримы обрабатываются в реальном времени, данные реплицируются по датацентрам. И почти в каждом таком сценарии возникает фундаментальный вопрос: Как понять, что произошло раньше, а что позже, если глобального времени не существует? Здесь в игру вступают логические часы Лампорта — простая, но концептуально мощная идея, лежащая в основе причинно-следственного порядка в распределённых системах. Подробнее - в новом переводе от команды Spring АйО .

https://habr.com/ru/companies/spring_aio/articles/1005934/

#java #kotlin #system #system_design #architecture #architecture_design #spring #spring_boot

[Перевод] Часы Лампорта

Сегодня мы живём в мире распределённых систем: Apache Kafka, Apache Spark, Apache Cassandra — это уже не экзотика, а повседневная инфраструктура продакшена. Сервисы пишут события, стримы обрабатываются в реальном времени, данные реплицируются по датацентрам. И почти в каждом таком сценарии возникает фундаментальный вопрос: Как понять, что произошло раньше, а что позже, если глобального времени не существует? Здесь в игру вступают логические часы Лампорта — простая, но концептуально мощная идея, лежащая в основе причинно-следственного порядка в распределённых системах. Подробнее - в новом переводе от команды Spring АйО .

https://habr.com/ru/companies/spring_aio/articles/1005934/

#java #kotlin #system #system_design #architecture #architecture_design #spring #spring_boot

Когда нужен BFF и стоит ли смешивать его с API gateway

Всем привет, уважаемые читатели! В архитектуре проектов мы можем наблюдать применение паттерна BFF (Backend for frontend). При этом BFF может быть в архитектуре, где есть взаимодействие с клиентскими приложениями: веб, мобильное, смарт-устройства и т.д, но может быть всего-навсего один служебный фронтенд, доступ к которому возможен во внутрикорпоративном сегменте, например, банковская система, hr, логистика. Кажется, что при наличии одного фронтенда введение BFF избыточно. И возникает закономерный вопрос: если клиент всего один, да еще и работает внутри защищенного контура, зачем нам плодить отдельные компоненты системы? Не превращается ли BFF в лишний прокси-сервис, который только пробрасывает запрос и добавляет сетевую задержку? Но что, если фронтенд один и вдруг нуждается в данных из разных API системы, чтобы нормально функционировать? При этом запросы могут быть сложными: каждый требует особых параметров и возвращает много лишней информации. А если у вас несколько клиентских приложений и так же нужно подтягивать данные из разных API?

https://habr.com/ru/articles/1005128/

#BFF #api #gateway #soundcloud #webmobile #facade #frontend #system_design

Legacy-код человечества: почему ИИ — это не угроза, а единственный работающий антивирус

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

https://habr.com/ru/articles/1004384/

#искусственный_интеллект #agi #философия_it #system_design #legacy_code #машинное_обучение #этика_ии #архитектура_систем