Перейти к основному контенту
Tech Path Finder
КурсыИнтервьюКод-ревьюБлог
Tech Path Finder

Персонализированный путеводитель в IT. Квизы, мок-интервью, код ревью и аналитика прогресса.

@potapov_me

Платформа

  • Курсы
  • Прогресс
  • Мок-интервью
  • Код ревью
  • Живое ревью с ИИ
  • Тренажёр переговоров
  • Закладки

Контент

  • Блог
  • Главная
  • Обратная связь

Компания

  • О проекте
  • Тарифы
  • Условия использования
  • Конфиденциальность
  • Согласие на обработку данных
  • Cookie
  • Реквизиты

Аккаунт

  • Войти
  • Зарегистрироваться
  • Профиль

© 2026 Tech Path Finder. Все права защищены.

·ИП Потапов К.С.·Политика конфиденциальности·
Сделано с ❤️ в России
  1. Системный дизайн для Python-разработчика
System Design / API·12 тем·128 вопросов·уровень Junior, Middle, Senior

Системный дизайн для Python-разработчика

Практический курс по системному дизайну для Python-разработчиков уровня Middle+ и выше. Охватывает архитектурные паттерны, проектирование API, базы данных, кэширование, очереди, микросервисы, масштабирование, observability, безопасность и event-driven архитектуру. Каждая тема включает теорию, примеры кода на Python, разбор реальных кейсов и практические задания.

Начать курс

Системный дизайн для Python-разработчика

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

Двенадцать тем. Основание — принципы (SOLID, DRY, KISS, YAGNI) и архитектурные схемы: слоёная, гексагональная, чистая, событийная, с разбором того, какая задача каждую из них породила.

Затем по слоям системы. API: REST, GraphQL и gRPC как выбор, а не как мода, контрактный подход, версионирование. Базы данных: схема, индексы, транзакции и уровни изоляции, шардирование и репликация. Кэширование: стратегии, инвалидация и три классических способа положить систему — stampede, penetration, avalanche. Очереди: Celery, Kafka и RabbitMQ, фоновые задачи и потоки событий. Микросервисы: где резать монолит, service discovery, circuit breaker, saga вместо распределённой транзакции. Масштабирование и балансировка, авто-скейлинг, ограничение частоты запросов. Observability: метрики, логи, трассировка и алерты, которые не будят зря. Безопасность: OAuth2, JWT, сессии, OWASP Top 10, хранение секретов. Event-driven: event sourcing, CQRS, реактивные схемы.

Финал — сквозной кейс: система проектируется с нуля, от требований и оценок нагрузки до схемы и плана масштабирования.

Уровень — middle и выше. Примеры на Python, но темы к языку не привязаны.

  1. 1

    SOLID и принципы проектирования

    Фундамент чистого кода: пять принципов SOLID, DRY, KISS, YAGNI. Как писать поддерживаемый и расширяемый код на Python.

    8 вопросов
  2. 2

    Архитектурные паттерны

    Layered Architecture, Hexagonal, Clean Architecture, Event-Driven — когда и зачем применять каждый паттерн.

    10 вопросов8.0(1)
  3. 3

    Проектирование API

    REST, GraphQL, gRPC — выбор инструмента. Контрактный подход, версионирование, документирование API.

    10 вопросов
  4. 4

    Базы данных и проектирование схемы

    Нормализация, индексы, транзакции, isolation levels, оптимизация запросов, шардирование и репликация.

    12 вопросов
  5. 5

    Кэширование и стратегии производительности

    Стратегии кэширования, Redis, CDN, инвалидация кэша, cache stampede, cache penetration, cache avalanche.

    12 вопросов
  6. 6

    Очереди и асинхронная обработка

    Celery, Kafka, RabbitMQ — фоновые задачи, event streaming, паттерны обработки очередей.

    12 вопросов
  7. 7

    Микросервисы и распределённые системы

    Декомпозиция монолита, сервис-дискавери, circuit breaker, saga, распределённые транзакции.

    12 вопросов
  8. 8

    Масштабирование и балансировка нагрузки

    Horizontal vs vertical scaling, load balancing алгоритмы, auto-scaling, rate limiting.

    10 вопросов
  9. 9

    Observability: логирование, мониторинг, трейсинг

    Три столпа observability, метрики, алертинг, distributed tracing, structured logging.

    12 вопросов
  10. 10

    Безопасность и аутентификация

    OAuth2, JWT, сессии, rate limiting, защита от OWASP Top 10, безопасное хранение секретов.

    10 вопросов
  11. 11

    Event-driven архитектура

    Event sourcing, CQRS, event storming, реактивные системы, паттерны event-driven архитектуры.

    12 вопросов
  12. 12

    Кейс: проектирование системы с нуля

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

    8 вопросов
  13. Зачёт

    Доступен после всех тем (0 из 12)

  14. Экзамен

    Доступен после зачёта

29 / 29

Single Responsibility Principle (SRP)

SOLID и принципы проектирования

Принцип единственной ответственности: класс должен иметь только одну причину для изменения. Каждая сущность должна отвечать за одну конкретную функцию.

Пример

Класс User не должен отправлять email — это ответственность класса EmailService. User отвечает только за данные пользователя.

Связанные термины

Open/Closed Principle (OCP)

SOLID и принципы проектирования

Принцип открытости/закрытости: сущности должны быть открыты для расширения, но закрыты для модификации. Новое поведение добавляется через наследование или композицию, а не изменением существующего кода.

Пример

Добавление нового типа оплаты через создание класса PayPalPayment вместо изменения существующего класса CreditCardPayment.

Связанные термины

Liskov Substitution Principle (LSP)

SOLID и принципы проектирования

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

Пример

Если Square наследуется от Rectangle, но меняет поведение set_width/set_height, это нарушает LSP — код, ожидающий Rectangle, может сломаться.

Связанные термины

Interface Segregation Principle (ISP)

SOLID и принципы проектирования

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

Пример

Вместо интерфейса Worker с методами work(), eat(), sleep() создать отдельные Workable и Eatable — робот реализует только Workable.

Связанные термины

Dependency Inversion Principle (DIP)

SOLID и принципы проектирования

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

Пример

Сервис зависит от абстракции Repository, а не от конкретной реализации SQLAlchemyRepository. Это позволяет легко подменить реализацию.

Связанные термины

Hexagonal Architecture (Ports & Adapters)

Архитектурные паттерны

Архитектурный паттерн, где ядро приложения (бизнес-логика) изолировано от внешних зависимостей (БД, UI, API). Взаимодействие происходит через порты (интерфейсы) и адаптеры (реализации).

Пример

Ядро определяет порт UserRepository, а адаптер SQLAlchemyUserRepository реализует его. Для тестов можно подменить адаптер на InMemoryUserRepository.

Связанные термины

Clean Architecture

Архитектурные паттерны

Архитектурный подход Роберта Мартина с концентрическими слоями: Entities → Use Cases → Interface Adapters → Frameworks & Drivers. Зависимости направлены внутрь.

Пример

Use Case зависит только от Entities. Controller (Interface Adapter) зависит от Use Case. Flask/FastAPI (Frameworks) зависят от Controller.

Связанные термины

CQRS (Command Query Responsibility Segregation)

Event-driven архитектура

Паттерн разделения ответственности команд и запросов: операции чтения (queries) и записи (commands) разделены на разные модели, что позволяет оптимизировать их независимо.

Пример

Query-модель использует денормализованное представление для быстрого чтения, Command-модель — нормализованную для консистентной записи.

Связанные термины

Event Sourcing

Event-driven архитектура

Паттерн, где состояние системы определяется как последовательность событий. Вместо хранения текущего состояния хранится история всех изменений.

Пример

Вместо обновления баланса счёта записывается событие MoneyDeposited или MoneyWithdrawn. Текущее состояние вычисляется применением всех событий.

Связанные термины

REST (Representational State Transfer)

API и контракты

Архитектурный стиль API, где ресурсы идентифицируются URL, операции выполняются через HTTP-методы (GET, POST, PUT, DELETE), состояние передаётся в представлениях (JSON/XML).

Пример

GET /users/123 возвращает JSON с данными пользователя. PUT /users/123 обновляет пользователя. DELETE /users/123 удаляет.

Связанные термины

GraphQL

API и контракты

Язык запросов для API, позволяющий клиенту запрашивать только нужные данные. Единая точка входа, типизированная схема, отсутствие over/under-fetching.

Пример

Запрос { user(id: 123) { name, email } } вернёт только имя и email, не загружая лишние поля.

Связанные термины

gRPC

API и контракты

Высокопроизводительный RPC-фреймворк от Google на основе HTTP/2 и Protocol Buffers. Используется для межсервисной коммуникации в микросервисах.

Пример

Определение сервиса в .proto-файле: service UserService { rpc GetUser(GetUserRequest) returns (User); }

Связанные термины

Нормализация БД

Базы данных

Процесс организации данных в БД для уменьшения избыточности и улучшения целостности. Формы нормализации: 1NF, 2NF, 3NF, BCNF и выше.

Пример

Разделение таблицы Orders с данными клиентов на отдельные таблицы Orders и Customers, связав их по customer_id.

Связанные термины

Индекс БД

Базы данных

Структура данных, ускоряющая поиск и сортировку записей в таблице. Обычно реализуется как B-дерево или хэш-таблица. Ускоряет чтение, замедляет запись.

Пример

CREATE INDEX idx_users_email ON users(email); — ускорит поиск по email, но замедлит INSERT/UPDATE.

Связанные термины

Уровни изоляции транзакций

Базы данных

Определяют, насколько транзакции видят изменения друг друга. Уровни: Read Uncommitted, Read Committed, Repeatable Read, Serializable. Более высокий уровень — больше консистентность, меньше параллелизм.

Пример

PostgreSQL по умолчанию использует Read Committed. Для финансовых операций может потребоваться Serializable.

Связанные термины

Write-Through кэширование

Кэширование

Стратегия кэширования, где данные записываются одновременно в кэш и в основное хранилище. Гарантирует консистентность, но медленнее при записи.

Пример

При обновлении профиля пользователя данные пишутся в Redis и PostgreSQL в одной транзакции.

Связанные термины

Cache Stampede (Dog Piling)

Кэширование

Проблема, когда множество запросов одновременно обнаруживают истечение кэша и идут в БД, вызывая перегрузку. Решения: locking, probabilistic early expiration, stale-while-revalidate.

Пример

Кэш популярной статьи истёк, 1000 запросов в секунду идут в БД. Решение: первый запрос генерирует кэш, остальные ждут.

Связанные термины

Очередь сообщений

Очереди и сообщения

Компонент для асинхронной коммуникации между сервисами. Сообщения помещаются в очередь и обрабатываются потребителями. Паттерны: point-to-point, pub/sub.

Пример

RabbitMQ, Redis Streams, AWS SQS. Сервис заказов публикует сообщение OrderCreated, сервис email читает и отправляет письмо.

Связанные термины

Event Streaming

Очереди и сообщения

Паттерн обработки непрерывного потока событий в реальном времени. События сохраняются в лог и могут читаться многократно разными потребителями.

Пример

Apache Kafka: события хранятся в топиках, потребители читают с любого оффсета, возможна повторная обработка.

Связанные термины

Circuit Breaker

Микросервисы

Паттерн для обработки ошибок в распределённых системах. При множественных неудачах «разрывает цепь», временно блокируя вызовы, давая сервису время на восстановление.

Пример

Если payment-service не отвечает 5 раз подряд, circuit breaker открывается на 30 секунд, все запросы сразу возвращают ошибку.

Связанные термины

Saga Pattern

Микросервисы

Паттерн управления распределёнными транзакциями через последовательность локальных транзакций с компенсирующими действиями для отката.

Пример

Заказ: 1) создать заказ, 2) списать деньги, 3) обновить склад. Если шаг 3не удался, выполнить компенсацию: вернуть деньги, отменить заказ.

Связанные термины

Service Discovery

Микросервисы

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

Пример

Consul, etcd, Kubernetes Service. Сервис orders-api регистрируется, сервис orders-ui находит его по имени через DNS или API.

Связанные термины

Горизонтальное масштабирование

Масштабирование

Добавление новых экземпляров системы для обработки нагрузки. Требует Stateless-архитектуры и балансировщика. Масштабируется лучше вертикального.

Пример

Вместо одного мощного сервера запустить 10 обычных за балансировщиком. Kubernetes автоматически добавляет поды при росте CPU.

Связанные термины

Load Balancer

Масштабирование

Компонент для распределения входящих запросов между несколькими экземплярами сервиса. Алгоритмы: round-robin, least connections, consistent hashing.

Пример

Nginx, HAProxy, AWS ALB. Запросы /api/users распределяются между 5 инстансами user-service.

Связанные термины

Structured Logging

Observability

Логирование в машиночитаемом формате (JSON) с полями вместо неструктурированного текста. Позволяет агрегировать и анализировать логи.

Пример

{"level": "ERROR", "service": "orders", "user_id": 123, "message": "Payment failed", "timestamp": "2026-03-03T10:00:00Z"}

Связанные термины

Distributed Tracing

Observability

Механизм отслеживания запроса через несколько сервисов. Каждый запрос получает trace_id, каждый шаг — span_id. Позволяет видеть полный путь запроса.

Пример

OpenTelemetry, Jaeger, Zipkin. Запрос пользователя проходит через API → Auth → Orders → Payment, все шаги связаны trace_id.

Связанные термины

OAuth 2.0

Безопасность

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

Пример

Вход через Google/Facebook. Приложение получает access_token для доступа к профилю, но не видит пароль пользователя.

Связанные термины

JWT (JSON Web Token)

Безопасность

Стандарт токенов в формате JSON с цифровой подписью. Состоит из header, payload, signature. Используется для stateless-аутентификации.

Пример

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsImV4cCI6MTY3... — содержит user_id и exp, подписан секретом.

Связанные термины

Rate Limiting

Безопасность

Ограничение количества запросов от клиента за единицу времени. Защищает от DDoS, злоупотреблений, обеспечивает fair usage.

Пример

100 запросов в минуту на IP. Реализация через Redis: INCR key, EXPIRE 60. При превышении — HTTP 429.

Связанные термины

Частые вопросы о курсе «Системный дизайн для Python-разработчика»

Состав курса, уровни, практика и способы проверки знаний.

Что входит в курс «Системный дизайн для Python-разработчика»?

Курс включает 12 тем и 128 вопросов с разбором ответа. Начать можно с первой темы курса.

Для какого уровня рассчитан курс «Системный дизайн для Python-разработчика»?

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

Как проверить, что материал усвоен?

После прохождения тем доступен зачёт по курсу «Системный дизайн для Python-разработчика» — 20 случайных вопросов с порогом 80%. После зачёта открывается экзамен с развёрнутыми ответами и автоматической оценкой, приближённый к техническому собеседованию.

Курс «Системный дизайн для Python-разработчика» бесплатный?

Да, курс полностью бесплатный: все 12 тем доступны без оплаты.

System Design на собеседовании: как готовиться

Архитектурный вопрос на собеседовании Middle/Senior обычно звучит как открытая задача: «спроектируйте сервис коротких ссылок» или «как бы вы построили ленту новостей». Оценивают не конкретное решение, а то, как вы задаёте уточняющие вопросы, проговариваете компромиссы и держите в голове систему целиком — от схемы БД до масштабирования.

Формат архитектурного ответа

Курс разбирает системный дизайн по слоям, которые обычно проходят на интервью в этом порядке:

  1. 1. Уточнение требований и ограничений (нагрузка, консистентность, задержки)
  2. 2. Проектирование API и схемы данных
  3. 3. Кэширование и асинхронная обработка
  4. 4. Масштабирование и балансировка нагрузки
  5. 5. Observability и безопасность

Практика на кейсах

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

Потренировать архитектурный ответ вслух на мок-интервью