В данной статье рассматриваются некоторые ключевые термины индустрии 4.0., мнение автора на возможное гармоничное совместное использование понятий имитационная модель, симулятор, агентный планировщик, гибридные модели, а также алгоритмические и человеко-ориентированые (игры симуляторы) инструменты поиска лучших решений.
UX-аналитика – это сбор и анализ данных о взаимодействии пользователей с интерфейсом (клики, скроллы, навигация и прочие события). Такие события генерируются в огромных количествах, особенно при большой аудитории приложения. Чтобы эффективно обрабатывать эту информацию, необходима распределённая архитектура, способная масштабироваться под высокий поток событий и обеспечивать отказоустойчивость – т.е. работать надёжно даже при сбоях отдельных компонентов. Также важна возможность обработки данных в реальном времени, чтобы как можно быстрее получать метрики и инсайты об опыте пользователей. В этой статье мы рассмотрим ключевые аспекты такой архитектуры: масштабирование UX-событий, надёжный сбор метрик с устройств (в том числе офлайн), реалтайм-аналитику на основе потоковых технологий (Kafka, Flink, Kafka Streams, ClickHouse) и механизмы гарантированной доставки событий (at-least-once, exactly-once, retry, дедупликация). В результате станет понятно, как правильно спроектированная система UX-аналитики позволяет оперативно находить проблемные места UI, проводить A/B тесты и глубже понимать поведение пользователей.
Индексы – это «ускорители» доступа к данным в базах данных. Правильно выбранные индексы могут многократно ускорить запросы, что особенно критично в highload-системах с большими объёмами данных и большим числом запросов. Однако за ускорение чтения приходится платить усложнением записи и дополнительным расходом памяти. В этой статье мы подробно рассмотрим, как работают разные типы индексов в реляционных СУБД, как выбирать индекс под конкретный запрос, обсудим подводные камни (например, блоат, переиндексация, избыточные индексы) и затронем индексацию в NoSQL (MongoDB, Cassandra). Завершим чеклистом, который поможет выбрать оптимальный индекс под вашу задачу.
Разработка отказоустойчивых систем представляет собой важнейшую компетенцию для инженеров, занятых созданием распределённых и масштабируемых приложений. Под отказоустойчивостью понимается способность системы сохранять работоспособность в условиях сбоев отдельных компонентов или недоступности внешних сервисов. В данной статье рассматриваются практики обеспечения устойчивости на уровне программного кода, в частности в контексте серверных приложений, реализованных на языках Python и Java.
Особое внимание уделяется методам повышения надёжности при временных сбоях, включая: повторные попытки выполнения операций с экспоненциальной задержкой (exponential backoff), использование шаблона circuit breaker, механизмы плавной деградации функциональности (graceful degradation), задание таймаутов, реализация идемпотентности, ограничение одновременных вызовов (bulkhead isolation), а также внедрение систем мониторинга и алертинга. Приводимые примеры охватывают типовые сценарии — обращение к внешним API, взаимодействие с базами данных и выполнение фоновых задач.
Выбор подходящей системы управления базами данных (СУБД) — важнейшая задача при проектировании программных систем. Разработчики и архитекторы учитывают множество факторов: модель данных (реляционная или NoSQL), поддержку транзакций, масштабируемость, требования к согласованности и многого другое. Одним из ключевых архитектурных аспектов, влияющих на эффективность и надежность системы, является модель репликации данных. Репликация означает поддержание копий одних и тех же данных на нескольких узлах (серверах), соединённых по сети.
Зачем это нужно? Репликация позволяет: во-первых, держать данные ближе к пользователям (уменьшая задержку при запросах); во-вторых, продолжать работу системы даже при сбое отдельных узлов (повышая доступность); в-третьих, масштабировать систему, увеличивая число узлов для обслуживания запросов на чтение (повышая пропускную способность).
Однако реализация репликации сопряжена с серьёзными архитектурными компромиссами. Согласно теореме CAP, в распределённой системе невозможно одновременно гарантировать все три свойства: консистентность данных, доступность сервиса и устойчивость к разделению сети. При возникновении сетевых сбоев (разбиении на изолированные сегменты) системе приходится жертвовать либо мгновенной согласованностью данных, либо доступностью части узлов. Поэтому разные СУБД делают разные выборы в этих компромиссах. Архитектурная модель репликации, лежащая в основе СУБД, определяет, как база данных достигает (или не достигает) консистентности, доступности и отказоустойчивости. Понимание этих различий крайне важно для архитекторов и разработчиков: зная поведение репликации, вы сможете выбрать такую СУБД, которая лучше соответствует требованиям вашего проекта по масштабу, геораспределенности, допустимой задержке и устойчивости к сбоям.
Часто ли вы слышите о новом принципе проектирования IT-архитектуры? А об обновлении классических принципов? Попробую вас удивить и привнести что-то новое. 😎
У вас никогда не вызывало недоумения, что связанность и прочность (или связность) — это про примерно одно и то же (и то, и другое — это некая связь), но одно — хорошо, а другое — почему-то плохо? 🙂
Но давайте по порядку.
Продолжаем наращивать базу знаний по System Design. В этот раз освятим использование BLOB Storage, CDN, Message Broker. Посмотрим на основные концепции и области применения этих важных компонентов при проектирование высокодоступных отказоустойчивых систем.
Воркшоп для тех, кто впервые сталкивается с распределёнными системами.
В этой статье на примере решения несложного архитектурного кейса я покажу, что ответов только на 3 вопроса при проектировании систем распределённой параллельной обработки данных будет достаточно для обеспечения жёстких нефункциональных требований.
Kafka-консьюмеры не всегда работают так стабильно, как хотелось бы. Иногда они просто зависают — без ошибок, без падений, но и без обработки сообщений. LivenessProbe в Kubernetes помогает автоматически перезапускать зависшие сервисы, но с Kafka-консьюмерами всё не так просто: стандартного решения для них нет. В этой статье разберём, как правильно реализовать livenessProbe для консьюмеров с помощью паттерна Heartbeat, чтобы не перезапускать их вручную.
Redis — это высокопроизводительное хранилище «ключ-значение» в оперативной памяти, известное своей невероятной скоростью. Фактически, один сервер Redis может обрабатывать до 100 000 запросов в секунду (QPS). Такая скорость часто удивляет, особенно если учесть, что Redis в основном работает по однопоточной модели обработки запросов. Так почему же Redis работает так быстро, несмотря на однопоточный подход? Давайте рассмотрим ключевые факторы, влияющие на производительность Redis.
Это компиляция основных знаний по проектированию архитектуры ПО, которые мне удалось собрать. Конспект доступен по ссылке на Miro-доску.
Можно сказать, что это взгляд на System Design с точки зрения фронтенд-разработчика, который пытается разобраться в теме.
Привет, Хабр! Меня зовут Михаил Федяев, я работаю архитектором в департаменте управления технологиями МТС Диджитал. В нашей экосистеме порядка 500 разных продуктов — для их развития у всех команд должны быть общие правила принятия решений. Они сформулированы в виде 15 технологических принципов. Сегодня я хочу рассказать про один из них — «Микросервисы». Он определяет, как в нашей компании подходят к внедрению микросервисной архитектуры.
В этой статье я не буду говорить про NFT, про Ethereum и т.п. Я сосредоточусь на возможности и смысле перенести все доступное нам сейчас с Web 2 на Web 3.
В общем случае конфигуриоование распределенных и кластерных систем - задача непростая. Для кого может быть полезным инструмент Sparky? Если у вас не используется кубернетес и вам приходится конфигурить / обновлять распределенную инфраструктуры со сложными взаимосвязями. Здесь я покажу несколько примеров не претендующих на исчерпывающее покрытие данной темы
Базовая конфигурация
Для того что бы все работало необходимо установить Sparky агенты на все настаиваемые ноды вашего кластера и обеспечить сетевую связанность на уровне http/https.
Вам не нужно изучать какую‑либо теорию, кроме этой статьи, чтобы начать собеседоваться. После прочтения смело приступайте к решению типовых System Design задач.
Изучая System Design, вы часто видите только теоретические материалы. В этой статье я постарался показать в том числе практическую реализацию многих вещей, чтобы вы не просто готовились к собеседованиям, но и знали, как эти вещи используются в реальном мире.
Рассказать надёжный способ заработать на криптовалютах? Устраиваетесь в блокчейн-проект разработчиком, пишете код, получаете зарплату. Готово, вы стали богаче, пока другие прогорали на бирже!
Шутки шутками, но мир web3 разросся в индустрию со своими вакансиями. И в ней востребован JavaScript, причём не только на фронтенде. Так что у JS-разработчиков появился смысл обращать внимание на этот сегмент, а на нашей конференции HolyJS появились доклады об этом.
И для Хабра мы решили перевести в текстовый вид выступление Александра Казакова @AlexandrKazakov, помогающее влиться в тему. В этом докладе рассматривается блокчейн Solana, но после него проще будет разбираться и с другими вроде Ethereum или TON. Если вам удобнее видео, прилагаем ссылки: YouTube, VK Видео. Далее — текст от лица спикера.
