The difference between seniors and non-senior staff is not technical ability but rather visibility.  With a micro-service architecture, junior and mid-level staff tend to only have visibility in the services they own.  At my company this is a feature, not a bug.  There are at least 2000 microservices in my organization.

So to increase your understanding I would 1) start with understanding the services adjacent to the ones you own.  Don't try to learn about every service all at once.  If your service calls theirs, or their service calls yours, it's likely that those systems will be easier to understand for you.  2) I would focus on a conceptual understanding of why these services exist rather than what they do or how they do it.  This can usually be summarized in a sentence or two but is sometimes difficult to get at because the folks that work on these systems want to talk about the finer points of how they do things.  3) I've found that in a microservices architecture, when trying to draw a box and arrows diagram it's easiest to collapse several services together that share similar responsibilities.  Once a diagram goes beyond 10-12 elements it gets too complicated to be useful.  4) Give yourself time to internalize things.  This is complicated stuff, if it was easy to understand then anybody could do it.  5) I know I have enough understanding with a system when I can read a document produced by another team and understand what it's saying.  When trying to figure out what a suite of services does, see if you can't get access to some of their documents.  Note the terms you don't understand, and then try to figure out what they mean.  I have found that people are happy to help if you make a concerted effort to understand what they work on and batch your questions so that you are respectful of their time.

Hope this helps.

\-Steve

Principal Software Engineer at Amazon

Steve Huynh

I'm interpreting what your saying as you are effectively acting as a senior engineer by being the SME on your team's services by doing things like fielding queries from other teams, and this is leading to you having to choose between acting in this capacity or addressing your team's ticket queue.

The simple answer is that a senior engineer is expected to do both at a high level. There are three paths forward

1. Work extra time. This isn't sustainable in the long-run, will lead to burnout, and potentially will introduce performance problems for you down the line.
2. Transition away from being the SME. I'm going to assume you want to be a senior so we'll rule this out.
3. Get more efficient, deep dive on root causes, and drive long-term fixes. It seems that you've started doing this on the SME side by creating documentation and wikis. Realize that this type of work is long-term and pays dividends in the future. You should apply this thinking to your team's ticket queue. If your team gets the same class of ticket, spend your oncall time and spare cycles working on fixing the root causes. Make sure your ticket queue doesn't boil over, but prioritize fixing bad alarming, getting finer grained metrics, and code-level problems rather than only focusing on ticket-level resolution. This may require some extra time and effort in the short term but it won't be permanent. Eventually, like the documentation work you are doing, things should get better over time and there will be less on your plate.

Realize that the way out of this is by taking a longer-term perspective and by making sure your day-to-day is chipping away at making yourself and your team's processes more efficient.

Hope that helps.

\-Steve

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

An ambitious SDE-I!  You will go far if you keep this up.

If you are having problems understanding your team's system design documents, I recommend that you proceed no further until you can understand your team's documents.  I would try to read a document several times and highlight the acronyms, concepts, and sentences that don't make sense and do your best to figure things out on your own.  If you get stuck, I would schedule time with folks on your team that can parse the document to walk you through it.  Repeat until you've consumed all of your team's documents, understand the problems each document is addressing, and the solution that was recommended.  This may take some amount of time but it's critical.

The reason I recommend this approach is that system design is a high-dimensional space and it's easy to get lost. You're unlikely to stumble upon a book, article, or video that's going to address the unknown-unknowns you currently have. At this point you likely both have gaps in conceptual understanding of general system design concepts *and* gaps in understanding your team's existing system, its endemic problems, and historical context.

Once you have a retrospective understanding of your team's software and systems, only then would I recommend that you attempt to write a prospective system design document.  The good news is that you need to search no further than your team's document repository and your team members to grow in this area.

Good luck!

\-Steve

The reality of the situation is as you get higher and higher in level scheduling becomes more and more of an issue. I wish I could show you the ridiculousness of my outlook calendar.  I often have triple and quadruple booked time slots and I have to make a judgement call about who I'll let down.  It sounds like your director is prioritizing his own time over your convenience but you should understand that you need him more than he needs you and his calendar is likely a circus like mine is.

I am allergic to reoccurring 1-1s.  My philosophy is the optimal time to meet mentors/mentees is on-demand because the necessity of the discussion is likely not going to be evenly distributed across time. When you had major issues to work through he had no problems meeting weekly.  When things stabilized the urgency left and his prioritization shifted.  

My recommendation is to proactively cancel meetings when there's nothing urgent to talk about. For weeks there is something meaty to talk about, I would recommend that you update the meetings agenda to reflect the value and urgency of the conversation that you'd like to have so he has a reason to shift his priorities around.  

\-Steve