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

Учитывая отложенный механизм сверки продаж в legacy-системе, в 12:54 обнаруживается проблема, что количество выписываемых билетов необычайно мало. Проверка оплат выявляет большое количество расхождений. Идентифицирована проблема: IP адреса платежного подсервиса не внесены в белые списки, ввиду чего в систему Тикетон не поступают подтверждения от платёжных систем и соответственно не завершаются продажи билетов

Тикетоновцы включили механизм виртуальной очереди, который, судя по всему, подменял IP адрес клиент своим и этот IP и был внесен в список белых адресов, а про IP адреса платежного сервиса забыли или не обо всех его адресах знали. Вот и получилось, что вебхук не принимал запросы от платежки об успешной транзакции и брони на места снимались. Теперь причина задвоения брони мест известна.

Этот случай напомнил мне нашу ситуацию в 2023 году во время фестиваля Soundstorm. У нас микросервисная архитектура на AWS и собственное мобильное приложение для сканирования QR кодов билетов клиентов.Также у нас не было реплик баз данных на чтение. Незадолго до имента мы внедрили новую фичу - оффлайн режим приложения для сканирования, чтобы избежать проблем с высокой задержки сигнала из-за слабого интернета на воротах на территорию фестиваля. Приложение скачивало себе все проданные билеты на фестиваль во внутреннее хранилище (где-то 150 тысяч билетов и ограниченный набор полей), чтобы в первую очередь взять информацию из него, а не с сервера. Возможные повторные проходки по одному билету нас не беспокоили в этой ситуации, мы былти к этому готовы, перформанс был на первом месте. Как оказалось, это нам и аукнулось во время фестиваля.

Спустя несколько часов после начала фестиваля наша система упала, нагрузка на БД возросла до 100% и каждый из нас немного поседел. Что произошло:

  1. Мобильное приложение скачивало все билеты после логина человеком. Устройств таких было около 200. По умолчанию приложение работало с сервером.
  2. Спустя некоторое время интернет на площадке начал работать хуже, так как нагрузка возросла в целом.
  3. Люди с девайсами, увидя медленную работу приложения, стали просто выгружать его из памяти и открывать и логиниться заново. Это приводило к повторному скачиванию всех билетов и, соответственно, к бОльшей нагрузке на сеть и БД. Мы этого не учли и даже не сразу поняли, что это происходит как снежный ком.
  4. Люди с девайсами начинали нервничать, что приложение открывается после логина долго, и снова выгружали его из памяти и открывали заново. Последствия этого уже известны.

Люди с девайсами нервничали, клиенты нервничали, так как не могли попасть на фестиваль, и мы тем более нервничали, пытаясь понять, как решить проблему. Остановить все сервисы - не вариант. Что мы сделали:

  1. Разработчик приложения быстро выпустил апдейт, убрав скачивание билетов. Мы на воротах быстро дали указание обновить приложение на девайсах.
  2. На одних из ворот паника возросла настолько, что люди начали отталкивать людей со сканерами и просто шли на фестиваль. Охрана приняла решение закрыть ворота на полчаса. Вторые ворота работали в обычном режиме, но расстояние между воротами было больше двух километров, так что нагрузка на работающие ворота не возросла. Люди на первых воротах просто ждали открытия.
  3. Нагрузка снизилась на инфраструктуру, дав возможность обработать все запросы в очереди.
  4. На следующий день уже мы добавили реплики баз данных на чтение, чтобы распределить нагрузку.

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

Какой из этого можно сделать вывод? Уже после анализа произошедшего кажется очевидным, что повторное скачивание всех билетов было лишним шагом, если уже было сдлеано скачивание ранее, и что это увеличит нагрузку на сеть и БД, но перед фестивалем об этом мы не задумались. Впредь стали учитывать, и фестиваль 2024го года прошел без проблем.

Учитесь на чужих ошибках, вот вам как раз я описал наш кейс и тикетон опубликовал разбор своего. Всем стабильной инфраструктуры