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.
what is
fetch current subscription expiry for x seconds flow? I understood all flows except this oneYou can update the cache in the frontend by fetching the current expiry time of the subscription and add X seconds TTL so that you keep refreshing this data. X can be large (5-10mins) or small like 10 secs depending on your expected QPS.
solution of Q1 - since we are having check at backend so I think we don't need cache at front-end, to avoid checking twice. Solution of Q2- I would go with separate table since the logic is not complicated in my scenario.