Supongamos que somos una gran red de publicidad. Colocamos banners en sitios asociados en todo el mundo. Necesitamos diseñar un sistema para recopilar y procesar eventos en tiempo real. Estos datos son críticos para dos propósitos: Facturación: Deducción de dinero a los anunciantes por clics. Analítica: Mostrar la efectividad actual de las campañas (CTR, impresiones) en el panel de control. Datos de entrada (para calcular la carga) Debe evaluar por sí mismo las capacidades requeridas (RPS, tráfico, almacenamiento), basándose en las siguientes métricas: Red de socios: 500,000 sitios activos. Tráfico: En promedio, cada sitio recibe 2 vistas de página por segundo. Bloques publicitarios: En cada página se muestran 3 banners simultáneamente. Conversión: La tasa media de clics (CTR) es del 1%. Irregularidad: La carga pico (horas de la noche) es 4 veces mayor que la media. Tamaño del evento: El objeto del evento (ID del banner, ID del sitio, UserID, Timestamp, tipo de evento) pesa aproximadamente 500 bytes. Requisitos técnicos Casi en tiempo real: Los datos en la interfaz analítica deben aparecer con un retraso no mayor a 10 segundos. Fiabilidad: La pérdida de clics no es aceptable (esto implica pérdida de dinero). La pérdida de impresiones es aceptable en un 0.01%. Escalabilidad: El sistema debe poder ampliarse fácilmente con el crecimiento del número de plataformas.

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

Оценка нагрузки

• Активных сайтов: 500,000
• Просмотры страниц в секунду на сайте: 2
• Баннеры на странице: 3
• CTR: 1%
• Пиковая нагрузка: ×4
• Размер события: 500 байт

Расчёт событий в секунду (RPS):

• Просмотры страниц: 500,000 × 2 = 1,000,000 в секунду
• Показов баннеров: 1,000,000 × 3 = 3,000,000 показов в секунду
• Клики: 3,000,000 × 1% = 30,000 кликов в секунду

Пиковая нагрузка: 3,000,000 × 4 = 12,000,000 показов и 30,000 × 4 = 120,000 кликов в секунду.

Трафик данных

• Показ: 500 байт × 12,000,000 = ~6 ГБ/сек
• Клик: 500 байт × 120,000 = ~60 МБ/сек

Архитектура системы

1. Сбор данных:

   • Использовать легковесные агенты или SDK на сайтах для отправки событий.
   • Протоколы: HTTP/2, gRPC или Kafka Producer для высокой пропускной способности.

2. Приём и буферизация:

   • Использовать распределённый брокер сообщений (например, Apache Kafka) для устойчивого приёма и буферизации событий.
   • Настроить партиционирование по ID сайта или баннера для масштабируемости.

3. Обработка:

   • Потоковая обработка с помощью систем типа Apache Flink, Kafka Streams или собственного сервиса на Go.
   • Клики обрабатывать с гарантией доставки (exactly-once или at-least-once).
   • Показов можно допускать небольшую потерю (0.01%), использовать компромиссы в обработке.

4. Хранение:

   • Для биллинга — база данных с транзакционной поддержкой (например, PostgreSQL, CockroachDB).
   • Для аналитики — OLAP-хранилище или колоночная БД (ClickHouse, Druid) для быстрых агрегаций.

5. Отображение данных:

   • Кэширование агрегированных данных для быстрого доступа в личном кабинете.
   • Обновление данных с задержкой не более 10 секунд.

Масштабируемость и надёжность

• Горизонтальное масштабирование всех компонентов.
• Репликация и резервирование брокеров и баз данных.
• Мониторинг и алерты на потерю данных и задержки.

Итог

• Система должна выдерживать до 12 млн событий в секунду на пике.
• Использовать распределённые технологии для приёма и обработки.
• Обеспечить гарантии доставки для кликов и минимальные потери для показов.
• Обеспечить near real-time обновление аналитики с задержкой до 10 секунд.