Golang

Използването на ScyllaDB преди продюсера е антипаттерн. Как правилно да организираме дедупликацията?

Защо трябва да съхраняваме сурови данни в S3 хранилището? Правилно ли е да използваме TTL от 5 минути в Redis, или е по-добре да ги съхраняваме по-дълго — 24 часа, и да използваме ScyllaDB като източник за проверка на данните?

Да предположим, че сме голяма рекламна мрежа. Поставяме банери на партньорски сайтове по целия свят. Трябва да проектираме система за събиране и обработка на събития в реално време. Тези данни са критични за две цели: Фактуриране: Изчисляване на суми за кликвания от рекламодатели. Аналитика: Показване на текущата ефективност на кампаниите (CTR, импресии) в личния панел. Входни данни (за изчисляване на натоварването) Трябва сами да оцените необходимите капацитети (RPS, трафик, съхранение), базирайки се на следните метрики: Партньорска мрежа: 500 000 активни сайта. Трафик: Средно, всеки сайт получава 2 прегледа на страница в секунда. Рекламни блокове: На всяка страница се показват 3 банера едновременно. Конверсия: Средният CTR (Click-Through Rate) е 1%. Несъответствие: Пиковата натовареност (вечерните часове) е 4 пъти по-висока от средната. Размер на събитието: Обектът на събитието (ID на банера, ID на сайта, UserID, Timestamp, тип на събитието) тежи около 500 байта. Технически изисквания Near Real-Time: Данните в аналитичния интерфейс трябва да се появяват с закъснение не повече от 10 секунди. Надеждност: Загубата на кликвания не е допустима (това означава пряка загуба на пари). Загубата на импресии (impressions) е допустима в рамките на 0,01%. Мащабируемост: Системата трябва лесно да се разширява при растежа на броя на платформите.