2

I have a multi-tenant application and the backend comprises of the microservices. The tenant admin will have a preferences page on the UI that can store system preferences for the tenant (i.e all users of the tenant).

I am thinking about what the best place for storing this would be?

SSM or Dynamo? Any trade-offs here for this use case?

we have a tenant microservice or we could create a system preferences microservice to store the preferences. I am trying to avoid all cross-service communication so the user of each tenant will get all the preferences on login and will send them back in the header. Should we continue to store the preferences in the tenant DB or system preferences microservice is the way to go?

systemdebt
  • 4,589
  • 10
  • 55
  • 116
  • How did it go? Is is still unclear what you can do? – Marcin Dec 09 '21 at 00:17
  • yes, I am not too happy with any of the solutions so far @Marcin. I have narrowed down that I'd like to keep it in DDB (most likely) but it either leads me to call a microservice from another or introduce a shared database, I don't like either way really. This is not a lot of information that I'd like to have an entire microservice for or make a sync call from another microservice. – systemdebt Dec 09 '21 at 00:30
  • What I may be open to doing is probably creating a microservice with no DB of its own but only pushing out events to 5-6 different services which will store their respective preferences in their DB. When it is time to get them, I can make those 5-8 calls from each of the microservices, What do you think? @Marcin – systemdebt Dec 09 '21 at 00:30
  • If your microservice fails, then all user data is lost without external DB? – Marcin Dec 09 '21 at 00:36
  • What I meant is : Client (system pref page) -> POST to orchestration microservice(one that comes in picture in situations like this) ->ASYNC(POST message to 5-6 different microservices that the system preferences updates belong to. (eventual consistency). When it's time to get system prefs (Orchestration microservice requests it from 5-6 diff microservices that have those settings saved in their DB). Orchestration microservice or a microservice specific for handling system prefs is subjective but this sounds more reasonable than 5-6 microservices querying system pref directly @Marcin – systemdebt Dec 09 '21 at 00:42
  • That is compared to if system pref service had its own database @Marcin – systemdebt Dec 09 '21 at 00:43
  • @SKhurana, any further insights? Which method did you choose? I'm facing the same dilemma too. Currently, I'm implementing it with SSM, but it can get pretty expensive since my lambdas need to access it on per request basis. – SimonSays Mar 03 '22 at 18:20
  • @SimonSays Decided against using SSM as the DB. It will be stored in the database itself. In addition to the costs, throttling was another factor. SSM calls are neither very fast nor cheap and have lower throttling limits – systemdebt Mar 03 '22 at 18:25
  • 1
    @SKhurana agreed. I was thinking about creating another microservice as you mentioned, but other then what Marcin has pointed out, the latency delay to that microservice is another issue. Maybe DynamoDB is the fastest and cheapest way to go – SimonSays Mar 03 '22 at 18:37
  • Just so that you know, I decided against creating a separate DB for storing preferences. They are being stored where they belong in DBs of different microservices. The preferences API will just call endpoints of other microservices to get this or the FE will call them directly. I did this to ensure other microservcies called preferences endpoint regularly. Would have resulted in a convoulatd mesh. @SimonSays – systemdebt Mar 03 '22 at 20:11
  • @SKhurana Have you publicly written up this solution anywhere? I've been googling all night and this is the closest answer to how to do user profiles / preferences in a Microservice architecture I've found. But there are a lot of other questions. Like how do you ensure new services play well with preference API/Service, keeping them in sync, etc. – Robert J Berger Apr 03 '22 at 05:14

1 Answers1

1

Configuration variables usually are stored in SSM Parameter Store. For one its free. From docs:

Parameter Store, a capability of AWS Systems Manager, provides secure, hierarchical storage for configuration data management and secrets management.

SSM Parameter Store also integrates natively with many other services. For example, you can seamlessly use them to pass secrets to ecs containers.

Marcin
  • 215,873
  • 14
  • 235
  • 294
  • These preferences are mostly related to how the users of a tenant will be looking at the app i.e what units for measurements, how many decimals for each measurement as such. Would you still say this belongs to SSM more than it does to Dynamo? (especially since Dynamo response is faster) . Also, any comment if the system pref should be a separate microservice or the tenant microservice should be expanded to store these? – systemdebt Dec 08 '21 at 01:28
  • @SKhurana SSM will be slower then DDb for sure. So it depends how frequently are you going to update and query them? If for each client request, then DDb will be faster. I have no concret opinion about "separate microservice". I guess if the preferences logic will be shared across all tenants, then maybe its better for it to be a separate service. – Marcin Dec 08 '21 at 01:32
  • 1
    @SKhurana There are also limits on how many SSM parameters you can have. With DDb there are no limits. – Marcin Dec 08 '21 at 01:34