amazon web services - Checking subscription status realtime

Question

Consider sample chat application where user purchase monthly/annual subscriptions (subscriptions like Amazon Prime, etc).

As soon as the subscription expires, user should not be able to send messages in app.

User can end their subscription before the original subscription end date.

One solution in my mind (Frontend) - to cache the end date in app and before every "send message" operation, compare the end date and current date.

But the problem is - if user ends the subscription early, user will still be able to send the message.

How can I push update the new subscription end date in cache.

Another solution was (Backend) - I have a table in backend storing subscription details like subscription_id, user_id, subscription_enddate. So before any "send message" operation, query the subscription table and compare the dates and then continue/cancel further operations.

Q1. Should I go with Backend solution or can you please share some improvements to frontend method or any best practice for this scenario?

Q2. Also is storing subscription details in separate table best practice or any good design instead. ?

PS- Sample chat app is based on AWS Amplify Datastore

question from:https://stackoverflow.com/questions/65557451/checking-subscription-status-realtime

Answer 1

Let me try to breakdown the answer and give my opinion. I would also like to mention solutions to such problems are determined by the scale and various tradeoffs.

Q1-

If sending messages has an adverse effect, you should never rely on the frontend solution only as it is easy to bypass them. You can use a mixture to ensure that the load is not very high on the backend.

Adding a Frontend Cache for subscription will ensure you will be able to filter most of the messages on the frontend if the cache is not tampered with.

Adding a service before the queue, that validates whether the user subscription has expired adds one more layer of security. If the user subscription is valid it pushes the message to Queue else throws an error. This way any bad actor can also not misuse the system.

Q2-

Depending on the use-cases and load, you can have a separate table or a separate micro-service for the subscription itself.

When to have a separate micro-service?

When the subscription data is required from multiple applications in your system and needs to have its own scalability independent of others, it can be beneficial to have a separate micro-service.

When to have a separate table? In other cases, where you feel adding a service would be overkill. You can keep the data separate in a different table/DB giving you the flexibility to change subscription and even extract it easily in the future.