Константин Андреевич, по списку - отсутствие серверного шифрования как класс, что приводит нас к высокому шансу того что в случае утечки ваши файлы будут полностью открыты. Кроме того в BackBlaze все данные хранятся в одном датацентре, судя по информации и как они при этом обеспечивают 8*9 of durability - неизвестно. Вероятнее всего враньё. Далее по трафику - большое число жалоб на скорость взаимодействия с их сервисами, а значит там даже намека нет на CDN.
Ну и в довесок в нормальных облаках ещё несколько десятков сервисов, которые интегрируются с хранилищем
mint_candy, это для других задач. Например, представьте анонимный чатик где люди общаются только пока не оборвалось соединение) я сейчас утрировал, но примерно так. В целом - каждой задаче свой инструмент
mint_candy, нельзя перепослать всем сообщение. По тому что это:
- трата сухого трафика
- трата чужих ресурсов
- потенциальное место налажать
- не безопасно
Хранить на сервере нельзя по тому что вам надо гарантированно идентифицировать клиента (а не пользователя)
Перепослать сообщения нужно стандартным механизмом - пришел клиент, получили для него сообщения с последнего стейта, послали сообщения как и всегда
Проверку на клиенте на дубль сообщения делать обязательно. Возможность переполучить что-то в сокете высока
mint_candy, вы в любом случае при нескольких клиентах обязаны сделать stateless backend и перенести логику запросов сообщений на клиента. Сообщения модно посылать как угодно. Но лучше точечно ибо в группу посылают только в случае когда отключившиеся клиенты больше никогда не участвуют в получении информации
mint_candy, сервер не должен знать ничего про клиента. Все клиенты не зависят друг от друга и имеют право иметь в отсутствие сети разный набор сообщений. Если одна система получила сообщение то и другая обязана получить
Иван Шумов
@inoise Куратор тега Amazon Web Services
IlikoN, во первых, давайте избавимся от мусора и переведем это в термины AWS. У вас есть EC2 instance, который качает трафик. Встает насколько вопросов - КАКОЙ именно это инстанс? Не все инстансы входят во free tier. И никому тут не известно как вы это организовали, поэтому неизвестно сколько у вас исходящего трафика.
Из советов - настройте Billing Alarm и настройте alarm на трафик с инстанса (возможно вам дополнительно придется для этого настроить VPC Flow logs). Так же проверьте в настройках аккаунта чтобы вам присылались уведомления про выход из лимитов free tier и только тогда вы сможете спать спокойно.
Учтите только что задержки по cloudwatch alarm по billing могут составлять 6 часов
IDONTSUDO, во-первых в гайдлайнах по монго написано черным по белому "можно сделать, но только если вы отбитый на голову", а во-вторых монго рассчитана как и любая документ-ориентированной база на горизонтальное масштабирование и то что вы хотите противоречит ее идеологии. Если вам нужна выдача в порядке появления записи по используйте Поля с timestamp , например, created_at
razer96, я предлагал смотреть на архитектуру, а не на продукт - это раз. Если у вас стартап то вам нужно MVP, что приводит к упрощению взаимодействия. Ну а два это то что AWS хоть и не бесплатен, но имеет Free tier и что касается подобных сервисов то они не дорогие, да и TCO понижается что важно. Плюс из коробки хорошая отказоустойчивость. Если надо то могу даль легкую консультацию) Для стартапа очень важно быстро выйти на рынок же
Ну и в довесок в нормальных облаках ещё несколько десятков сервисов, которые интегрируются с хранилищем