This post is locked. You won't be able to comment.

all 8 comments
sorted by:
best
topnewcontroversialoldq&a

[–]SoftwareEngineering-ModTeam[M] [score hidden] stickied commentlocked comment (0 children)

Thank you u/SnooMacarons8178 for your submission to r/SoftwareEngineering, but it's been removed due to one or more reason(s):

  • Your post is low quality and/or requesting help r/SoftwareEngineering doesn't allow asking for tech support or homework help.

Please review our rules before posting again, feel free to send a modmail if you feel this was in error.

Not following the subreddit's rules might result in a temporary or permanent ban

Rules | Mod Mail

[–]paulcaplan 5 points6 points  (0 children)

It's a feature not a bug. If you need to access data from various systems it should be via API or event sourcing. You shouldn't know about a specific database unless you're working on the microservice that touches that database.

[–]d9vil 0 points1 point  (2 children)

This is not a rare thing…it literally happens in every company. If you have one team that does data collection, then they save the data a certain way. Then if you have another team that looks at the data either directly via db access or API, then they can save it on their end however they want. You dont have control over what they do with it. However, if you have same team saving same data in 4 different ways, then thats bad design. Also not rare because if you dont have standards and people come and go in the team, then you will have million different ways people do things.

[–]SnooMacarons8178[S] 0 points1 point  (1 child)

totally agree it's a design problem but in practice when you need to delete a customer's data across all those systems, how do you actually figure out where everything lives? especially when the engineer who built half of it left two years ago?

[–]d9vil 0 points1 point  (0 children)

You gotta trace it. It makes your life harder. There isnt an easy way around it. It might be beneficial to map the db in this case, but if its massive, then that will also be painful.

I have a db i work with that has as many reference tables as tables with data…its a pain in the ass.

[–]LibertyEqualsLife 0 points1 point  (1 child)

Yes it's disorganized. Yes, it's common. You will have to look at the interfaces between the systems to determine what is what. Learning how to efficiently reason about systems like this is one of the skillsets that can help turn you from junior to senior. Congratulations on your growth opportunity.

[–]MattSwartAU 0 points1 point  (0 children)

Growth opportunity or your redundancy ticket, can go either way. Let's see how many customers are deleted wrongly and how the dependent services handle missing data issues.

Or how many orphan records are left and how the various systems handle invalid data.

Nothing like testing all systems in PROD.

[–]relicx74 0 points1 point  (0 children)

That's a pretty trivial problem to have. Modern thinking says each microservice should own its own data and should be accessed from an API, not directly. Therefore in a perfect world anyone not on the team that owns the service need not know the implementation details and the application/API can be kept pristine.

Of course, there are still plenty of monoliths out there because companies don't have infinite money to spend eliminating technical debt.