SQL Design for a subcription microservice
I'm trying to develop SQL tables for a subscription service as part of my uni coursework. It's for a subscription microservice, so it only handles subscription related stuff. A subscription then grants certian 'privileges' such as ad-free and bla bla which will affect how the other microservices work. My question is: there's only one paid tier, so the structure is very simple.
Should i:
a) make a sql table which can detail exact tiers and attributes (adfree, send notifications etc)
b) leave the attributes which aren't strictly payment/billing related OUT of the table because the microservices can handle that on their own (like ie this is a plus member so this microservice can figure out on its own what extra priviledges relevant to itself it should grant)
B seems like the cleaner option, as from a development perspective it makes no sense to necessitate passing the user's exact priviledges to every single microservice it accesses when they can within their own service easily determine what to do. But what worries me about this implementation is that there isn't exactly a 'single source of truth' for what tier does what. I also don't want to be seen as lazy like maybe I found a way to not have to bother with writing out all the tier attributes myself?
Also since this is a coursework piece the other microservices do not actually exist so it isn't possible to just check whether they handle it on their own