The problem you proposed would be a mid level or senior dev type problem on most organizations' job role descriptions. In most organizations junior devs are not expected to design solutions for open ended problems on their own.
For mid-level, they are capable doing more of the problem triaging/classification and can handle vaguer, larger scoped problems. They can identify the correct stakeholders to engage with and, ideally, influence. Can identify the most likely best approach amongst a set of possible approaches. Guidance is high level- like a weekly or bi-weekly 1:1. Better design taste as far as how to measure outcomes or rollout changes safely.
For senior you're ideally solving classes of problems rather than specific problems. You're charting a longer term roadmap that generates work and exerts influence amongst number of teams to drive long-term business outcomes. You are mentoring juniors/mid-levels so they're setup for success and have the right work at the right level of guidance at the right time to grow in their careers.
Our service occasionally gets especially expensive requests
that amplify to our partners, one of those partners have
started complaining that our bursts of traffic are
impacting other users, talk to them and propose a solution
that aligns with our different requirements.
With the clarification above, I believe a junior dev could perform this task, even if the proposed solution is known to be a learning exercise.
The immediate value to the team is the collection of partner concerns.
I will say though, needing to socialize across other teams to understand the problem and drive the correct solution does strike me as more mid/senior level work.
Generally you don't put those skills in a Junior PD, but you would expect a Junior to take on these tasks if they hope to progress. The Mid level PD would have it listed and as the junior shows they can meet each and every additional skill, the option of a promotion becomes available.
When I was a junior I was allowed and given free reign to design the test system for the product and implement a design system for the frontend team.
Junior doesn't mean stupid, it just means less experience. How else do you expect people to gain experience if you don't give them basic independent projects?
Both 100 % open ended problems.
It's different from the one described above
> talk to them and propose a solution that aligns with our different requirements. Possible directions are X, Y, Z.
I'm sure some junior devs could do this but the majority wouldnt be able to