правильно, зачем разбираться с деадлоками, лучше другую бд взять :)

Ну поэтому мой первый и финальный совет - это как раз таки разобраться с дедлоками:)
А насчёт Кафки - это не в смысле «эту проблему можно обойти, если взять кафку». Это в дополнение, что под подобный план нагрузки она может отлично подойти.

Необходимости навыка решать проблему дедлоков никто не отменял ;)

Доброго
подскажите как такое реализовать
есть определенное приложение TT и мы выдаем ему ключи апи CGVBJ%^&*()
на основании этого ключа приложение может работать
посылать запросы /api/userDetalis/  
как правильно проверять этот ключ?
в каком месте?
есть примеры таких решений?

Определиться с форматом ключа, хоть jwt, хоть hmac

Ключ случайно будет генерится

Если это черновая БД, то MySQL там оверхед. Надо брать что-то очень быстрое и тупое, я бы попробовал Redis.

Проверять в соответствии с алгоритмом генерации ключа.
В middleware.
Посмотри существующие решения oauth, jwt

При этом данные не должны потеряться в случае падения сервера и т.д

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

Редис умеет сыпаться. Даже с персистом.  Чтобы говорить про Надежность и отказоустойчивость в редисе,  лучше говорить про кластер

Ну я в Редисе ничего важного не храню, и не храню долговременно. Использую как промежуточное хранилище. Записал, использовал, передал дальше, удалил. И память не жрëт и работает быстро.

Одно дело использовать его как кэш, который всегда можно переналить данными. Другое дело - как консистентную бд data lake. Вы советуете редис именно под второй сценарий. Я бы так не советовал делать под эту задачу как минимум без кластера.

Ещë ни разу не попадал на сбой в Редисе. Возможно везло. Но не знаю. Я бы сначала сделал, посмотрел как работает. Возможно бояться там нечего.

В любом случае это не единственное тупое и быстрое хранилище на свете. Вариантов много. Главное что не использовать MySQL, она там лишняя.

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

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

2020 на дворе. Пора перестать зацикливаться на мускле

Добрый день, кто знает, есть ли аналог uLogin, чтобы была поддержка Instagram OAuth, ибо на uLogin разработчики судя по всему давно забили, и ввиду недавних изменений, авторизация через Instagram отвалилась.

Угу. А вы точно все сценарии использования знаете? Уверены, что все выборки по pk и реляции не нужны?

Я вот не наванговал на утверждение «неподходящий тип хранилище»

Это называется прогаматизм. Если у тебя на каждую бд есть своя машина - без вопросов, делай как хочешь. Если у тебя 1 машина и куча бдшек, а бд как правило жрут очень много памяти. То у тебя очень скоро возникнут проблемы.

Там был ещё вариант с Кафкой.

Но тут как говорится, можно код начать оптимальный писать, а можно железом заливать. Зачем  учиться писать качественный код, когда в 2020 году многое гуглится на SO.

И да, я сейчас не защищаю подход  «надо использовать mysql».

Но если писать многопоточный код как однопоточный и решать все «чёрной коробкой бд не понимая, как работает все внутри», далеко уехать вряд ли получится. Под нагрузкой особенно