How do I better understand the various micro services that my team handles and the overall system design?
I am a Backend Engineer at a Platform Team.
Our team currently owns 9 micro services which serve as a platform which other teams use through the company.
5/9 of these services are actively being worked on and the rest are just running without any changes/ enhancements.
I have been working for the past 8 months on one of the services but haven’t had much exposure to others.
I want to learn about the others, how the data flows between them and how the overall system design is. I am just going through tons of design RFCs and reading code but with little understanding.
My primary motivation is to
- Understand more of our scope and work on them.
- Move out of my comfort zone.
- Handle On Call tasks better where understanding code is needed more than just following runbook.
How can I better understand at the service level?
![Senior Software Engineer [E5] at Meta company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fmeta.jpeg%3Falt%3Dmedia%26token%3Da7a5bcc0-e178-4b5b-b71e-09bf6c6aefae&w=48&q=75){kind=small}
![Entry-Level Software Engineer [L3] at Google company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fgoogle.jpeg%3Falt%3Dmedia%26token%3D780356ef-3efc-4728-9eb4-d909b75bb4a6&w=48&q=75){kind=small}
Discussion
(3 comments)- 132 years agoEx @Meta @Microsoft, Founder Algolab
Start with listing down APIs; these services expose for inter-service communication. The interaction between these services will help you see the overall design, critical paths, and scope.
Pick one service per week to go over its recent code commits, reported bugs, and discussions on those bugs and commits. Depending on the company culture, you may ask the owner of the service if there is a minor bug you can help fix.
Talk with the product managers to go over the history of the project and different services. They will happily share the context and background on why/who/when of the service.
Be proactive in investigating issues reported by tools such as DataDog and Sentry. Even if you are not on-call, you should take the initiative to examine the issue yourself and participate in the discussion with the on-call person to help them out. This could be the most critical work item you can take to answer your question.
- 92 years agoTech Lead/Manager at Meta, Pinterest, Kosei
I love Touseef's answer.
One of the challenges in your case is the sheer amount of stuff you could learn. There are 9 services and the surface area is huge. That can be overwhelming.
Here's the life hack I wish I knew earlier: spend 10 minutes upfront (each day or each week) to decide what to dive into.
Look at where the code is actively being modified, where the discussion is happening, and work backwards from alerts.
When you parse out what is actually important for the team, you create direction (and motivation) for deeper learning.
- 82 years agoPrincipal Software Engineer at Amazon
Another approach, if you have access to it, is to poke around at the client code base. Often times, if the service code is difficult to grok the code consuming code may be easier to understand.
Another advantage I've found with poking around client code is it often reveals the true behavior of APIs if there is weirdness like operations that do something different than their name. You will often find comments lamenting these oddities there rather than in the service code itself.
-Steve
