Поясніть, хто знається краще на мережевих технологіях: чи можна було б ГІОЦу для "спілкування" з платіжними системами виділити окремий логічний (чи навіть фізичний більшої гарантії) комунікаційний канал, щоб система Букінг могла отримувати підтвердження (квитанції) про успішну оплату тих замовлень, які системі вдалося дотягнути до етапу "на оплату". Тобто, якщо вже потенційному пасажиру так пощастило, що він дійшов до етапу "оплата", то наступний етап (отримання підтвердження платіжної системи) повинен бути хоча б в 10 раз гарантованіший, тобто канал зв'язку повинен бути в 10 раз менш зайнятий... а щоб це гарантувати, то краще прокласти окремий "кабельок" (в т.ч. оптичну жилу)... і тоді не потерпатимуть ті, хто сплатив за замовлення... і отримають квитки. Правильний хід думки?
Не зовсім. яким би не був кабель - імовірність помилки є. Ну тобто канал можна покращити, але головне - тримати інформацію про квитки корисувача навіть між сесіями, прив'язану до ідентифікатора користувача. Тоді не важливо - чи не відповів сервер оплати, чи пропав інтернет, чи пристрій покупця перезавантажився, можна зайти в свій кабінет, побачити статус квитків і залишок часу для оплати. В такому випадку неуспішну операцію легко повторити. (до речі приблизно так у ПКП).
п.м. Зараз модель вибудувана так, як в передових магазинах часів застою (в СРСР), тільки в "електронному еквіваленті": покупець стояв у черзі на оформлення покупки, йому називали суму, він йшов до касира, стояв теж у черзі, називав номер відділу і суму, давав готівку, касир видавала чек, потім знову стояв у черзі, аби той чек обміняти на відкладений для нього товар... тільки в нашому випадку з Букінгом "людині з чеком" потрібно ставати ще раз в ту первинну чергу, але регламент каже "15хв і допобачення"... тобто "людина з чеком" стоїть хоча б 16хв, і "все пропало".
Зараз модель приблизно така сама - продаж квитків окремо, оплата окремо. Єдине, інтернет дозволяє сховати це від користувача. Дійсно, підхід УЗ це вчорашній день, і не дуже гарне usability. Хорошим тоном вважається показувати покупцю за що він платить. Тобто - крім даних картки і кнопки "оплатити" - коротенький текстовий опис - у випадку квитка - маршрут, прізвище, дата. І не переадресовувати на сервер оплати, а використовувати його як API, а покупець взаємодіє тільки з сервером УЗ.
Також можна подумати про організацію веб-черги. Бачив схоже на УЄФА при купівлі квитків, можливо суміщене з балансуванням. Як працює - користувач заходить на сайт, а по факту - на сервер черги. Якщо сервер продажу вільний (або імовірніше - є вліьний кластер) - користувача одразу переадресують на сайт купівлі. Якщо ж сервер/кластери купівлі завантажені - видається повідомлення, що за пару хвилин він користувач потрапить на сайт купівлі. Коли з'являться ресурси - перенаправля на вільний (або єдиний) сервер. Тут перевага в тому, що сайт купівлі не буде перевантажений неуспішними операціями. Наприклад, позавчора, чи коли там, я купив квитки з 8 разу, тобто сім спроб - це пусте завантаження.
Можливо спеціалісти з devops більше скажуть.
