Блог

Рассмотрим пример приложения для чата, в котором пользователь приобретает ежемесячные / годовые подписки (подписки, такие как Amazon Prime и т. Д.).

По истечении срока действия подписки пользователь не сможет отправлять сообщения в приложении.

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

На мой взгляд, одно решение (интерфейс) — кэшировать дату окончания в приложении и перед каждой операцией «отправить сообщение» сравнивать дату окончания и текущую дату.

Но проблема в том, что если пользователь завершит подписку раньше, пользователь все равно сможет отправить сообщение.

Как я могу нажать обновить новую дату окончания подписки в кэше.

Другим решением было (серверная часть) — у меня есть таблица в серверной части, в которой хранятся сведения о подписке, такие как subscription_id, user_id, subscription_enddate. Поэтому перед любой операцией «отправить сообщение» запросите таблицу подписки и сравните даты, а затем продолжите / отмените дальнейшие операции.

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

Q2. Также хранит сведения о подписке в отдельной таблице best practice или в любом другом хорошем дизайне. ?

PS- Пример приложения для чата основан на хранилище данных AWS Amplify

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

Вопрос 1-

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

Добавление кэша внешнего интерфейса для подписки гарантирует, что вы сможете фильтровать большинство сообщений во внешнем интерфейсе, если кэш не поврежден.

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

Вопрос 2-

В зависимости от вариантов использования и нагрузки у вас может быть отдельная таблица или отдельная микросервис для самой подписки.

Когда нужно создавать отдельную микросервису?

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

Когда нужно создавать отдельную таблицу? В других случаях, когда вы считаете, что добавление службы будет излишним. Вы можете хранить данные отдельно в другой таблице / базе данных, что дает вам возможность изменять подписку и даже легко извлекать ее в будущем.