Timeline for How to handle shared data across microservices?
Current License: CC BY-SA 4.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 16, 2024 at 17:16 | comment | added | Ján Halaša | @MichaelYousef please how did you solve the problem? In your question, I miss info about who initiates the reward calculation process (whitch needs the language an the user's reward tier). Maybe the values could be included in the request/message somehow (at least the language), so they don't have to be fetched from the user service. | |
| Mar 16, 2022 at 13:48 | comment | added | Flater | "This causes us to have to access the data outside of the microservice it's stored in." And why is this a problem? However, this seems really naive. How so? In both cases you've pointed at something that you consider to be a problem, but haven't really elaborated on why that is the case. These considerations matter, because you may have subtly different requirements or circumstances from one of the answerers, which can impact what the right decision should be. | |
| Mar 15, 2022 at 18:04 | answer | added | trustMeImAnAdult | timeline score: 0 | |
| Oct 15, 2019 at 17:01 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Oct 2, 2019 at 18:00 | history | tweeted | twitter.com/StackSoftEng/status/1179456168835596288 | ||
| Sep 15, 2019 at 16:20 | answer | added | Eduard Gan | timeline score: 10 | |
| Feb 17, 2019 at 23:05 | comment | added | Kain0_0 | Alternately if your architecture considers these micro-services to be an implementation detail then the API is a truly separate entity. You might offer end-points which are one stop shops for obtaining all the relevant data for a given UI/Batch process. This is fairly pragmatic as the network is by far one of the slowest aspects of a networked application, reducing the need to connect to several instances and construct the data remotely can have a huge net-positive effect on the client applications responsiveness. In this case its not a design flaw but a feature, it is just not a micro service | |
| Feb 17, 2019 at 22:58 | comment | added | Kain0_0 | Whether it is a design flaw or not depends on how you architect the system. If your architecture is to expose pure micro-services to the outside world then yes it contradicts the essence of truly separate data. The central claim you are advertising is that one service and co-located end-points are the only source/gateway for that data. By providing the data on several end-points you posit the question as to which is authoritative, particularly if they ever desync, which is likely because the client might be comparing data from an hour ago against the fresh request. | |
| Feb 14, 2019 at 16:29 | comment | added | Michael Yousef | If I understand you correctly, you're saying that the reward tier data coming back from the GET /user/X/profile endpoint is a design flaw? | |
| Feb 12, 2019 at 2:16 | comment | added | Kain0_0 | From the way you are discussing it, supporting the API as is is crucial. To that end, separate that API as a separate proxying/aggregating service. Its job is to support a stable user facing interface and allow your team to re-organise the services behind it. When it becomes too messy, then is the time to publish a New API that is more inline with the current back-end, and decommission the old API. With appropriate caching this will not be significantly slower, and may even be an optimisation. It also allows you to support single call behaviours that return all relevant data. | |
| Feb 12, 2019 at 2:04 | comment | added | Kain0_0 | Fair enough, but again you are mixing up how data is consumed, with how it is stored and processed. Unfortunately the lingo for both is service, but they are by no means the same thing. A well designed micro-service contains a single cohesive set of data and behaviour, it is identical in every sense of the word to a module. It alone exposes that data, and that data is not replicated elsewhere (except via caching). If you need to present data from several services in a single call you effectively have a presentation problem, essentially making the published API a separate aggregating service. | |
| Feb 11, 2019 at 15:00 | comment | added | Michael Yousef | So what happens when /user/X/profile has to include reward data in the response? Then it has to hit two different services. That's what I'm trying to work through. I don't like the idea of splitting up everything into different endpoints. In fact, there's no GET for reward tier only, it comes back in the user profile type endpoint. If I split everything into different endpoints it becomes trivial but then there's so many endpoints that consuming it is really cumbersome. | |
| Feb 10, 2019 at 10:56 | comment | added | Kain0_0 | Hmm, I think that is the problem. You are looking at how you wish to present state to a downstream system. In this context I would agree that rewards appear to model along user lines. However Micro Services are not about this. They are about containing state and behaviour together in a tightly coupled module, which is only vaguely coupled to other services. You can obtain the logical grouping on the API by routing various sub-paths to different service behind the api. eg /user/X/reward can route to the rewards service, while /user/X/profile routes to the user profile service. | |
| Feb 7, 2019 at 13:55 | comment | added | Michael Yousef | No, it doesn't do anything other than CRUD. The issue comes from a concern of how CRUD accesses that data. Let's suppose for a minute that I put it entirely in the rewards service, how do I access it? By hitting /rewards/<user_id>/something? Does that make more sense than doing /users/<user_id>/update and giving it a new reward tier? From the perspective of an API, you end up with too many endpoints doing far too little if you take this approach. | |
| Feb 6, 2019 at 22:28 | comment | added | Kain0_0 | Does the User Service actually do anything with the data. Besides providing CRUD operations? If it does not actually do anything, why could that data not be referred too? Even if it does do something, are those actions almost identical/similar to the rewards service? Also natural sense, who's natural sense? Yours? How did you get this natural sense? Take a step back, look at the data and behaviours of your system. This duplication is telling you that the current services are wrong and do not fit. So treat it like a monolith, then figure out how to decompose it back into good services. | |
| Feb 6, 2019 at 16:24 | comment | added | Michael Yousef | The data belongs to a user, it's a property of them. It makes sense for the get and set for that data to be hitting the user model. A user has a reward tier, that just naturally makes sense. The data is used for calculating rewards by the reward service. The data is definitely identical. You can't join them together without creating a monolithic service. Making more services is just option 2. If querying the data has to hit a middle service then it's no better than what we already have. | |
| Feb 5, 2019 at 23:28 | comment | added | Kain0_0 | Sounds to me like there is another service sitting in there waiting to break out. Either each piece of that shared data is different (its a perspective) in which case its not shared, Or each piece of data is identical and copied to each service verbatim in which case listen to the data and break it out. Take a hard look at why it is fundamentally a member of each service and see how it is used. If you could redraw the boundaries between services would it naturally arise? You might surprise yourself. | |
| Feb 5, 2019 at 16:31 | history | asked | Michael Yousef | CC BY-SA 4.0 |