между европой и азией RTT примерно 200 мс (Германия-Сингапур)
https прошлых версии требует = 3-4 RTT (600-800 мс) + DNS
если у вас настроено TLS v 1.3 + 0-RTT = 2-3 RTT (400-600) + DNS
подробнее тут
https://blog.cloudflare.com/introducing-0-rtt/
Приложение и БД должны быть в одном датацентре (регионе) иначе каждый http-запрос будет отрабатываться как кол-во sql-запросов * RTT 200 мс = долго)
соотвественно если у вас трафик азии приземляется только на единственный сервер в европе пользователи из азии тратят больше на подключение, на 600-800 мс больше.
если вы купите слугу CDN для ускорения динамического сайта (или настроите свои сервера) и ваш https будет терминироваться в азии, а само приложение и бд останется все также в европе - оставшаяся задержка сократиться до 1 RTT = 200 мс,
также к этому прикручиваете быстрый anycast DNS, например Cloudflare (только DNS, без СDN) или AWS route 53 (он еще от ddos 3,4 уровня защищен)
тут статистика DNS сервисов по latency
https://www.dnsperf.com/
если будете смотреть CDN выбирайте тут:
https://www.cdnperf.com/
но услуга ускорение динамики есть не у всех
если хотите свое - можно использовать AWS Global Accelerator (в нем дают anycast ip) это даст:
- терминацию TCP близко к пользователя
- приоритетную сеть с меньшими задержками
- защиту от Ddos 3,4 уровня
- быстрое переключение на резервный датацентр/регион если основной упал
+ пару дешевых региональных EC2 под терминацию Https
как аналог еще смотрите Azure Front Door
Как уменьшить оставшиеся 200 мс:
1) Если использовать синхронную рекликацию между континентами, например как mysql galera/percona xtradb cluster - скорость чтения будут локальной, но кол-во транзакций записи в секунду будет очень медленным, тк упрется в RTT, а если оно 200 мс = 5 транзакций/секунда
2) Если делать шардинг пользователей по континентам, то будут возникать проблемы если у вас есть кроссшардовые операции или может быть решардинг (пользователь переезжает в другой континент).
Есть CockroachDB которые завляюят что у них это все это решается "из коробки" - на практике хз.
4) Если вам подходит eventual consistency и split brain на короткое время не сломает ваше приложение - можно попробовать БД, которые будут использовать Согласованность в конечном счёте используя асинхронную репликацию
Но так ли критично уменьшение этих оставшихся 200 мс?
Стоит ли использовать новые необкатанные БД в production с которыми нет опыта решение проблем ради оставшихся 200 мс?