It's hard to say because the familiarizing depends a lot on how you learn best as an individual. Some folks do better with more formal training and documentation, others do better with jumping in and tracing code to see how things flow. Most will have a lot of questions as they learn more. I would say do the most that you can with what is available depending on the style of learning you favor (e.g. reading documents, tracing code, etc.) and then compile a list of questions you can't get answered through your own discovery and find a mentor on the team who you can ask.
When talking to a mentor, I find it better to ask for an overview of how things work rather than the exact specifics. I like to take notes while they go over things so I can review them later - I never expect to remember everything at once. This also includes copying down diagrams and such, they can be very helpful. Your mentor will also often be able to point you towards other resources and people you can ask. The important thing is that you need to do the legwork yourself - do the research yourself and see what you can figure out first, then go to the mentor to help fill in the gaps.
One thing I also suggest is to ask to be included on code reviews from other programmers working on similar tasks. This is a way for you to get exposed to other systems that you aren't super familiar with and see how the other programmers are working. During code reviews you don't just have to point out issues with the code - you can also ask questions about how something works and the more experienced programmers can explain it. Even senior programmers don't always 100% understand everything in another programmer's code review, so asking should be no big problem for anyone.
Got a burning question you want answered?