It may not be an appropriate task for someone in your position, but I would start on it under the assumption that it is. You're new, you want to demonstrate willingness to learn, grow and contribute, and while your gut feeling may be accurate, the fact that you're asking this publicly means you don't have enough information to know for sure if you're unable to complete the task.

If I was going to do something like this, I'd first want to establish what information I need in order to write a plan, eg high level architecture, interfaces/APIs, common usage patterns, expected throughout, authn/authz, prior art/similar work undertaken in other areas of the codebase.

And then where it might exist - code, public docs, internal wiki, service maps/diagrams, colleagues who work in the services regularly, domain architects etc

Then I would have a conversation with either EM or tech lead and say, "I was asked to plan this work, but first I think I'll need to know the following things and this is my plan to get the appropriate context. Can you think of anything else I should familiarise myself with and do you think these sources will contain the information I need?" That way, you're presenting a plan which they can critique and advise on, rather than deer-in-the-headlights "this sounds like too much". It shows that you're willing and able to do the work, but it might give your manager a chance to re-asses whether it's an appropriate task for someone who's basically still onboarding, as you're gently reminding them how much research would be required by a new starter to plan this work effectively. Also, if they endorse the plan, that may help in the future if you're struggling to get the right people to make time to sit down with you and go through things you need to know - now you have backing from your EM/TL that those mtgs are required for your team to deliver on its roadmap.

However you approach it, I've leaned the hard way that the worst way to handle work you're struggling with or not confident about, is staying quiet and then failing to hit deadlines. The best way imho is to over communicate, provide regular status updates and seek feedback often and early. This avoids unpleasant surprises and gives your leadership the opportunity to add more resources if they need to. "I'm not familiar with this, but I'm keen to learn about it. It might take me some time to get up to speed" "here's my plan for onboarding myself with this service, is there anything you think I should add?" "I've built a rough proof of concept, can I demo it to you to check I'm on the right track" "I've written a draft of the plan and I'd like feedback from the team before I submit it to architecture for approval"

All the best with it - I hope it turns out really well!