georgich, там выборка по условию с одним сервисом. Получится в предварительно много одинаковых записей и там уже проверяем сколько дублей. Где дублей столько сколько подзапросов там и правда. Но вообще это может быть болезненно. Это аналитический запрос и если нагрузка большая то проще использовать колоночные базы данных
kalaysolay, боты тема не то чтобы новая, просто готовые решения мало кому подходят и стоят примерно как крыло от Боинга. Иметь своего бота в любом облаке стоит копейки по расходникам
protracer, брокеры тупые и умеют только отправлять сообщения в порядке очереди по группам в нужные обработчики. Kafka, RabbitMQ хорошие решения. Если кэш не локальный то это уже не кэш просто как класс. Поэтому никаких распределенных кэшей. Локальный это в той же подсети самое дальнее, а лучше как часть инстанса
protracer, тогда вам ставить read реплики в нужные регионы и соединять их с местной копией сервера. Самое простое и дешевле. А запись вести в основную базу и страдать только там от задержек. Обязательно научиться в случае потери мастера делать одну из реплик мастером и быстро переконфигурировать приложения (можно через dns)
Стоит добавить что непонятно нагрузка на чтение или запись, какие требования к консистентности. Можно решить просто гео-репликицией с CQRS или Event Sourcing
Иван Шумов
@inoise Куратор тега Amazon Web Services
Евгений, это работа аутентификации через STS сервис, так называемая) то есть там история что вся аутентификация происходит через него, просто постоянный доступ обеспечивается только через креды в IAM. При логине любым способом пользователь получает STS токен и работает через него) Но все-равно это дикость - ели человеку надо работать с CLI то он прекрасно должен уметь работать с AWS и можно дать ему programmatic access и генерировать себе пары ACCESS KEY/SECRET. В чем вообще проблема-то я не понимаю))
DevMan, курсами пользуются все, но не сертификатами "я прошел курс, смотрите я молодец". В крайнем случае есть в CV такой раздел "обучение" и туда можно написать если таких с десяток)
Иван Шумов
@inoise Куратор тега Amazon Web Services
Макс, Ну, вообще это именно то что я и говорил. Другого способа аутентификации нет, а в статье - воркэраунд, который перестанет работать после того как креды будут сброшены в IAM. Это просто набор скриптов, которые можно также воспроизвести и на Linux и на osx. По федерации в cli никого не пустит - это отдельные доступы и пермишены, настраиваемые в iam
Иван Шумов
@inoise Куратор тега Amazon Web Services
Макс, Никак. Можно забыть об этом как класс. AWS имеет всего один тип аутентификации через cli: access key + secret и в ближайшем будущем это менять не планирует
Артемий Фамилий, Делать тестовое окружение, писать тесты и все в таком духе. Я в этом плане очень полюбил AWS - сделал себе API на API gateway + lambda на Serverless framework и вперёд с песнями. Запускать можно сколько угодно параллельных окружений, тестировать через postman и все production ready. Деплой простой и не мучительный. Как-то так. В GCP/Azure тоже можно так делать. Yandex cloud подтягивается. Стоит примерно ничего на фоне обычных решений
