sa-lessons/modules/module1/sections/09-architecture-examples.md

# Примеры архитектур известных систем

## Навигация
- [🏠 Главная страница курса](../../../README.md)
- [📚 Модуль 1](../README.md)

---

## Twitter

### Обзор системы
Twitter - социальная сеть для микроблогинга, где пользователи публикуют короткие сообщения (твиты) до 280 символов.

### Архитектурный стиль
- **Микросервисная архитектура** с event-driven подходом
- **Гибридная архитектура**: комбинация микросервисов и монолитных компонентов
- **CQRS** (Command Query Responsibility Segregation) для разделения чтения и записи

### Архитектурная диаграмма

```mermaid
graph TB
    subgraph "Twitter Architecture"
        subgraph "Client Layer"
            Web[Web App]
            Mobile[Mobile App]
            API_Client[API Clients]
        end
        
        subgraph "API Gateway"
            LB[Load Balancer]
            Gateway[API Gateway]
        end
        
        subgraph "Core Services"
            Timeline[Timeline Service]
            Tweet[Tweet Service]
            User[User Service]
            Search[Search Service]
            Media[Media Service]
        end
        
        subgraph "Data Layer"
            MySQL[(MySQL)]
            Redis[(Redis)]
            ES[(Elasticsearch)]
            S3[(AWS S3)]
        end
        
        subgraph "Message Queue"
            Kafka[Apache Kafka]
        end
    end
    
    Web --> LB
    Mobile --> LB
    API_Client --> LB
    LB --> Gateway
    
    Gateway --> Timeline
    Gateway --> Tweet
    Gateway --> User
    Gateway --> Search
    Gateway --> Media
    
    Timeline --> Redis
    Timeline --> MySQL
    Tweet --> MySQL
    Tweet --> Kafka
    User --> MySQL
    Search --> ES
    Media --> S3
    
    Kafka --> Timeline
```

### Основные компоненты

#### 1. Timeline Service
- **Назначение**: Генерация персональных лент пользователей
- **Технологии**: Scala, Finagle
- **Особенности**: 
  - Реалтайм генерация лент
  - Кэширование популярного контента
  - Асинхронная обработка

#### 2. Tweet Service
- **Назначение**: Создание, хранение и распространение твитов
- **Технологии**: Scala, MySQL, Redis
- **Особенности**:
  - Fan-out паттерн для распространения
  - Шардирование по user_id
  - Event sourcing для аудита

#### 3. User Service
- **Назначение**: Управление пользователями и профилями
- **Технологии**: Scala, MySQL
- **Особенности**:
  - Аутентификация и авторизация
  - Управление подписками
  - Профильная информация

#### 4. Search Service
- **Назначение**: Поиск по твитам и пользователям
- **Технологии**: Elasticsearch, Scala
- **Особенности**:
  - Индексирование в реальном времени
  - Полнотекстовый поиск
  - Геопространственный поиск

#### 5. Media Service
- **Назначение**: Обработка изображений и видео
- **Технологии**: Scala, AWS S3
- **Особенности**:
  - Загрузка и оптимизация медиа
  - CDN для быстрой доставки
  - Метаданные медиафайлов

### Качественные атрибуты

#### Производительность
- **Время отклика**: < 200ms для timeline
- **Пропускная способность**: 6,000 твитов/сек
- **Метрики**:
  - 99.9% запросов < 1 секунды
  - Кэш hit rate > 95%

#### Масштабируемость
- **Горизонтальное масштабирование**: Все сервисы масштабируются независимо
- **Шардирование**: Данные разделены по user_id
- **Кэширование**: Многоуровневое кэширование (Redis, CDN)

#### Надежность
- **Доступность**: 99.9% uptime
- **Отказоустойчивость**: Graceful degradation при сбоях
- **Резервирование**: Multi-region deployment

#### Безопасность
- **Аутентификация**: OAuth 2.0
- **Шифрование**: TLS для всех соединений
- **Аудит**: Логирование всех действий

### Архитектурные решения

#### 1. Fan-out Pattern
```scala
// Упрощенный пример fan-out для твитов
class TweetFanoutService {
  def fanoutTweet(tweet: Tweet, followers: List[UserId]): Unit = {
    followers.par.foreach { followerId =>
      timelineService.addToTimeline(followerId, tweet)
    }
  }
}
```

#### 2. Event Sourcing
```scala
// События для аудита твитов
sealed trait TweetEvent
case class TweetCreated(tweetId: String, userId: String, content: String) extends TweetEvent
case class TweetDeleted(tweetId: String, userId: String) extends TweetEvent
case class TweetLiked(tweetId: String, userId: String) extends TweetEvent
```

#### 3. CQRS Implementation
```scala
// Command side - запись
class TweetCommandHandler {
  def createTweet(command: CreateTweetCommand): Unit = {
    // Валидация и создание твита
    val tweet = Tweet(command.content, command.userId)
    tweetRepository.save(tweet)
    eventBus.publish(TweetCreated(tweet.id, tweet.userId, tweet.content))
  }
}

// Query side - чтение
class TimelineQueryService {
  def getTimeline(userId: String): List[Tweet] = {
    // Чтение из оптимизированного read store
    timelineRepository.findByUserId(userId)
  }
}
```

---

## Netflix

### Обзор системы
Netflix - стриминговая платформа для видео контента с более чем 200 миллионами подписчиков по всему миру.

### Архитектурный стиль
- **Микросервисная архитектура** с cloud-native подходом
- **Event-driven architecture** с Apache Kafka
- **Serverless** компоненты для обработки медиа

### Архитектурная диаграмма

```mermaid
graph TB
    subgraph "Netflix Architecture"
        subgraph "Client Layer"
            Web[Web Browser]
            Mobile[Mobile App]
            TV[Smart TV]
            Console[Gaming Console]
        end
        
        subgraph "CDN Layer"
            CloudFront[AWS CloudFront]
            OpenConnect[Open Connect]
        end
        
        subgraph "API Gateway"
            Zuul[Zuul Gateway]
            Eureka[Eureka Registry]
        end
        
        subgraph "Microservices"
            User[User Service]
            Content[Content Service]
            Recommendation[Recommendation Service]
            Playback[Playback Service]
            Billing[Billing Service]
        end
        
        subgraph "Data Layer"
            Cassandra[(Cassandra)]
            Elasticsearch[(Elasticsearch)]
            Redis[(Redis)]
            S3[(AWS S3)]
        end
        
        subgraph "ML Pipeline"
            Spark[Apache Spark]
            TensorFlow[TensorFlow]
            Kafka[Apache Kafka]
        end
    end
    
    Web --> CloudFront
    Mobile --> CloudFront
    TV --> OpenConnect
    Console --> CloudFront
    
    CloudFront --> Zuul
    OpenConnect --> Zuul
    
    Zuul --> Eureka
    Eureka --> User
    Eureka --> Content
    Eureka --> Recommendation
    Eureka --> Playback
    Eureka --> Billing
    
    User --> Cassandra
    Content --> Elasticsearch
    Recommendation --> Redis
    Playback --> Redis
    Billing --> Cassandra
    
    Content --> S3
    Playback --> S3
    
    Recommendation --> Spark
    Spark --> TensorFlow
    Kafka --> Recommendation
```

### Основные компоненты

#### 1. API Gateway
- **Назначение**: Единая точка входа для всех клиентов
- **Технологии**: Zuul, Spring Cloud Gateway
- **Особенности**:
  - Маршрутизация запросов
  - Аутентификация и авторизация
  - Rate limiting и throttling

#### 2. User Service
- **Назначение**: Управление пользователями и подписками
- **Технологии**: Java, Spring Boot, Cassandra
- **Особенности**:
  - Профили пользователей
  - Управление подписками
  - Предпочтения контента

#### 3. Content Service
- **Назначение**: Управление каталогом контента
- **Технологии**: Java, Spring Boot, Elasticsearch
- **Особенности**:
  - Метаданные фильмов и сериалов
  - Поиск и фильтрация
  - Многоязычная поддержка

#### 4. Recommendation Service
- **Назначение**: Персональные рекомендации
- **Технологии**: Python, TensorFlow, Apache Spark
- **Особенности**:
  - Machine Learning модели
  - A/B тестирование
  - Real-time рекомендации

#### 5. Playback Service
- **Назначение**: Воспроизведение видео
- **Технологии**: Java, Spring Boot, Redis
- **Особенности**:
  - Управление сессиями просмотра
  - Адаптивная потоковая передача
  - Аналитика просмотров

#### 6. CDN (Content Delivery Network)
- **Назначение**: Доставка видео контента
- **Технологии**: AWS CloudFront, Open Connect
- **Особенности**:
  - Глобальная сеть серверов
  - Кэширование популярного контента
  - Оптимизация для мобильных устройств

### Качественные атрибуты

#### Производительность
- **Время отклика**: < 100ms для API
- **Пропускная способность**: Миллионы запросов в минуту
- **Видео качество**: Адаптивная потоковая передача

#### Масштабируемость
- **Горизонтальное масштабирование**: Все сервисы масштабируются автоматически
- **Multi-region**: Развертывание в нескольких регионах AWS
- **Auto-scaling**: Автоматическое масштабирование на основе нагрузки

#### Надежность
- **Доступность**: 99.99% uptime
- **Fault tolerance**: Circuit breaker pattern
- **Disaster recovery**: Multi-region backup

#### Безопасность
- **DRM**: Защита контента от пиратства
- **Аутентификация**: OAuth 2.0 + JWT
- **Шифрование**: End-to-end шифрование

### Архитектурные решения

#### 1. Circuit Breaker Pattern
```java
@Component
public class RecommendationServiceClient {
    
    @CircuitBreaker(name = "recommendation-service")
    @Retry(name = "recommendation-service")
    public List<Movie> getRecommendations(String userId) {
        return recommendationService.getRecommendations(userId);
    }
}
```

#### 2. Event-Driven Architecture
```java
// Событие просмотра фильма
@Component
public class PlaybackEventHandler {
    
    @EventListener
    public void handleMovieWatched(MovieWatchedEvent event) {
        // Обновление рекомендаций
        recommendationService.updateUserPreferences(
            event.getUserId(), 
            event.getMovieId()
        );
        
        // Аналитика
        analyticsService.recordView(event);
    }
}
```

#### 3. Caching Strategy
```java
@Service
public class ContentService {
    
    @Cacheable(value = "popular-movies", key = "#region")
    public List<Movie> getPopularMovies(String region) {
        return contentRepository.findPopularByRegion(region);
    }
    
    @CacheEvict(value = "popular-movies", allEntries = true)
    public void updateMoviePopularity(String movieId) {
        // Обновление популярности
    }
}
```

---

## Uber

### Обзор системы
Uber - платформа для заказа поездок, которая соединяет водителей и пассажиров в реальном времени.

### Архитектурный стиль
- **Микросервисная архитектура** с domain-driven design
- **Event-driven architecture** для real-time обработки
- **CQRS** для разделения команд и запросов

### Архитектурная диаграмма

```mermaid
graph TB
    subgraph "Uber Architecture"
        subgraph "Client Layer"
            Rider[Rider App]
            Driver[Driver App]
            Web[Web Dashboard]
        end
        
        subgraph "API Gateway"
            LB[Load Balancer]
            Gateway[API Gateway]
        end
        
        subgraph "Core Services"
            Dispatch[Dispatch Service]
            Trip[Trip Service]
            Payment[Payment Service]
            User[User Service]
            Notification[Notification Service]
            Map[Map Service]
        end
        
        subgraph "Data Layer"
            PostgreSQL[(PostgreSQL)]
            MongoDB[(MongoDB)]
            Redis[(Redis)]
            PostGIS[(PostGIS)]
        end
        
        subgraph "Message Queue"
            Kafka[Apache Kafka]
        end
        
        subgraph "External Services"
            Maps[Google Maps API]
            Payment_Gateway[Payment Gateway]
            SMS[SMS Service]
            Push[Push Notification]
        end
    end
    
    Rider --> LB
    Driver --> LB
    Web --> LB
    LB --> Gateway
    
    Gateway --> Dispatch
    Gateway --> Trip
    Gateway --> Payment
    Gateway --> User
    Gateway --> Notification
    Gateway --> Map
    
    Dispatch --> Redis
    Dispatch --> Kafka
    Trip --> PostgreSQL
    Trip --> Kafka
    Payment --> PostgreSQL
    User --> MongoDB
    Notification --> Kafka
    Map --> PostGIS
    Map --> Redis
    
    Map --> Maps
    Payment --> Payment_Gateway
    Notification --> SMS
    Notification --> Push
    
    Kafka --> Notification
    Kafka --> Trip
```

### Основные компоненты

#### 1. Dispatch Service
- **Назначение**: Сопоставление водителей и пассажиров
- **Технологии**: Go, Redis, Kafka
- **Особенности**:
  - Real-time геолокация
  - Алгоритмы сопоставления
  - Load balancing

#### 2. Trip Service
- **Назначение**: Управление поездками
- **Технологии**: Java, Spring Boot, PostgreSQL
- **Особенности**:
  - Жизненный цикл поездки
  - Расчет стоимости
  - Отслеживание статуса

#### 3. Payment Service
- **Назначение**: Обработка платежей
- **Технологии**: Java, Spring Boot, PostgreSQL
- **Особенности**:
  - Интеграция с платежными системами
  - Расчет комиссий
  - Обработка возвратов

#### 4. User Service
- **Назначение**: Управление пользователями
- **Технологии**: Go, MongoDB
- **Особенности**:
  - Профили водителей и пассажиров
  - Аутентификация
  - Рейтинги и отзывы

#### 5. Notification Service
- **Назначение**: Отправка уведомлений
- **Технологии**: Go, Kafka, Firebase
- **Особенности**:
  - Push уведомления
  - SMS и email
  - Персонализация

#### 6. Map Service
- **Назначение**: Картографические данные
- **Технологии**: Go, Redis, PostGIS
- **Особенности**:
  - Геокодирование
  - Маршрутизация
  - Трафик в реальном времени

### Качественные атрибуты

#### Производительность
- **Время отклика**: < 50ms для dispatch
- **Пропускная способность**: Миллионы запросов в минуту
- **Real-time**: Обновления каждые 3 секунды

#### Масштабируемость
- **Горизонтальное масштабирование**: Все сервисы масштабируются независимо
- **Sharding**: Данные разделены по регионам
- **Caching**: Агрессивное кэширование геоданных

#### Надежность
- **Доступность**: 99.9% uptime
- **Fault tolerance**: Graceful degradation
- **Data consistency**: Eventual consistency

#### Безопасность
- **Аутентификация**: Multi-factor authentication
- **Геолокация**: Защита персональных данных
- **Платежи**: PCI DSS compliance

### Архитектурные решения

#### 1. Event Sourcing для поездок
```java
// События поездки
public class TripEvent {
    private String tripId;
    private String eventType;
    private LocalDateTime timestamp;
    private Map<String, Object> data;
}

// Обработчик событий
@Component
public class TripEventHandler {
    
    @EventHandler
    public void handleTripStarted(TripStartedEvent event) {
        // Уведомление водителя и пассажира
        notificationService.notifyTripStarted(event.getTripId());
        
        // Обновление статуса
        tripService.updateStatus(event.getTripId(), TripStatus.IN_PROGRESS);
    }
}
```

#### 2. CQRS для геоданных
```java
// Command side
@Service
public class LocationCommandService {
    
    public void updateDriverLocation(String driverId, Location location) {
        // Обновление в write store
        locationRepository.updateDriverLocation(driverId, location);
        
        // Публикация события
        eventBus.publish(new LocationUpdatedEvent(driverId, location));
    }
}

// Query side
@Service
public class LocationQueryService {
    
    public List<Driver> findNearbyDrivers(Location passengerLocation) {
        // Чтение из оптимизированного read store
        return locationReadRepository.findNearbyDrivers(passengerLocation);
    }
}
```

#### 3. Saga Pattern для поездок
```java
@Component
public class TripSaga {
    
    @SagaOrchestrationStart
    public void startTrip(TripRequestedEvent event) {
        // 1. Найти водителя
        dispatchService.findDriver(event.getPassengerId())
            .thenAccept(driver -> {
                // 2. Создать поездку
                tripService.createTrip(event.getPassengerId(), driver.getId());
            });
    }
    
    @SagaOrchestrationStep
    public void handleDriverAccepted(DriverAcceptedEvent event) {
        // 3. Подтвердить поездку
        tripService.confirmTrip(event.getTripId());
    }
}
```

---

## Сравнительная диаграмма архитектурных паттернов

```mermaid
graph TB
    subgraph "Architectural Patterns Comparison"
        subgraph "Twitter - Event-Driven + CQRS"
            T1[Timeline Service]
            T2[Tweet Service]
            T3[User Service]
            T4[Search Service]
            T5[Media Service]
            TK[Kafka Events]
            TR[Redis Cache]
            TM[MySQL]
        end
        
        subgraph "Netflix - Cloud-Native + ML"
            N1[User Service]
            N2[Content Service]
            N3[Recommendation Service]
            N4[Playback Service]
            N5[Billing Service]
            NC[CDN]
            NK[Kafka]
            NCass[Cassandra]
        end
        
        subgraph "Uber - DDD + Real-time"
            U1[Dispatch Service]
            U2[Trip Service]
            U3[Payment Service]
            U4[User Service]
            U5[Notification Service]
            U6[Map Service]
            UK[Kafka]
            UPG[PostgreSQL]
            UMG[MongoDB]
        end
    end
    
    T1 -.-> TK
    T2 -.-> TK
    T3 -.-> TM
    T4 -.-> TM
    T5 -.-> TM
    
    N1 -.-> NK
    N2 -.-> NCass
    N3 -.-> NK
    N4 -.-> NCass
    N5 -.-> NCass
    
    U1 -.-> UK
    U2 -.-> UK
    U3 -.-> UPG
    U4 -.-> UMG
    U5 -.-> UK
    U6 -.-> UPG
```

## Сравнительная таблица архитектур

| Система | Архитектурный стиль | Основные технологии | Особенности |
|---------|-------------------|-------------------|-------------|
| **Twitter** | Микросервисы + CQRS | Scala, MySQL, Redis | Fan-out pattern, Event sourcing |
| **Netflix** | Микросервисы + Cloud-native | Java, Spring Boot, AWS | CDN, ML рекомендации |
| **Uber** | Микросервисы + DDD | Go, Java, PostgreSQL | Real-time геолокация, Saga pattern |

---

## Диаграмма ключевых архитектурных паттернов

```mermaid
graph TB
    subgraph "Key Architectural Patterns"
        subgraph "Microservices Pattern"
            MS1[Service A]
            MS2[Service B]
            MS3[Service C]
            MS4[Service D]
            MSG[API Gateway]
            MSL[Load Balancer]
        end
        
        subgraph "Event-Driven Pattern"
            ED1[Event Producer]
            ED2[Event Bus/Kafka]
            ED3[Event Consumer A]
            ED4[Event Consumer B]
            ED5[Event Consumer C]
        end
        
        subgraph "CQRS Pattern"
            CQRS_C[Command Side]
            CQRS_Q[Query Side]
            CQRS_WS[(Write Store)]
            CQRS_RS[(Read Store)]
            CQRS_E[Event Bus]
        end
        
        subgraph "Caching Strategy"
            CACHE_L1[L1 Cache<br/>Application]
            CACHE_L2[L2 Cache<br/>Redis]
            CACHE_L3[L3 Cache<br/>CDN]
            CACHE_DB[(Database)]
        end
    end
    
    MSL --> MSG
    MSG --> MS1
    MSG --> MS2
    MSG --> MS3
    MSG --> MS4
    
    ED1 --> ED2
    ED2 --> ED3
    ED2 --> ED4
    ED2 --> ED5
    
    CQRS_C --> CQRS_WS
    CQRS_C --> CQRS_E
    CQRS_E --> CQRS_Q
    CQRS_Q --> CQRS_RS
    
    CACHE_L1 --> CACHE_L2
    CACHE_L2 --> CACHE_L3
    CACHE_L3 --> CACHE_DB
```

## Ключевые паттерны и решения

### 1. Микросервисная архитектура
- **Преимущества**: Независимое развертывание, масштабируемость
- **Недостатки**: Сложность, network latency
- **Применение**: Все три системы используют микросервисы

### 2. Event-Driven Architecture
- **Преимущества**: Слабая связанность, масштабируемость
- **Недостатки**: Сложность отладки, eventual consistency
- **Применение**: Twitter (твиты), Netflix (просмотры), Uber (события поездок)

### 3. CQRS (Command Query Responsibility Segregation)
- **Преимущества**: Оптимизация для чтения и записи
- **Недостатки**: Сложность, eventual consistency
- **Применение**: Twitter (timeline), Uber (геолокация)

### 4. Caching Strategies
- **Redis**: Для быстрого доступа к данным
- **CDN**: Для статического контента
- **Application Cache**: Для часто используемых данных

### 5. Database Patterns
- **Sharding**: Разделение данных по ключам
- **Read Replicas**: Для масштабирования чтения
- **Event Sourcing**: Для аудита и восстановления

---

## Диаграмма процесса анализа архитектуры

```mermaid
flowchart TD
    A[Выбор системы] --> B[Изучение документации]
    B --> C[Анализ технических блогов]
    C --> D[Изучение open-source компонентов]
    
    D --> E[Определение доменов]
    E --> F[Выделение сервисов]
    F --> G[Анализ взаимодействий]
    
    G --> H[Оценка производительности]
    H --> I[Анализ масштабируемости]
    I --> J[Проверка надежности]
    J --> K[Оценка безопасности]
    
    K --> L[Изучение паттернов]
    L --> M[Анализ технологий]
    M --> N[Выявление trade-offs]
    
    N --> O[Создание диаграммы]
    O --> P[Документирование решений]
    P --> Q[Финальный отчет]
    
    style A fill:#e1f5fe
    style Q fill:#c8e6c9
    style O fill:#fff3e0
```

## Рекомендации для анализа

### 1. Выберите систему
- Изучите публичную информацию о архитектуре
- Проанализируйте технические блоги компании
- Изучите open-source компоненты

### 2. Определите компоненты
- Выделите основные домены
- Определите границы сервисов
- Проанализируйте взаимодействие

### 3. Оцените качественные атрибуты
- Производительность (метрики, нагрузки)
- Масштабируемость (как система растет)
- Надежность (обработка сбоев)
- Безопасность (защита данных)

### 4. Изучите архитектурные решения
- Паттерны проектирования
- Технологические выборы
- Trade-offs и компромиссы

---