Having built out my first game engine for the first time (in 20 years), and completely ignored alot of good literature (I should of read more but oh well :)). I can offer a few quick insights into my issues and what dawned on me. That question is why do I need to pass objects locally around, there are good reasons in many cases, but what I found was to limit that and at the least make it a pattern of use.
I won't go into actual architecture, because there are a number of ways to do this. I've used your model of update and render. So it triggered some recollections.
Firstly I thought more about how to loosely couple systems together so I can swap out and enhance components as I went. One such method that worked for me was I found that by using an event manager (in my experience) where objects subscribed and unsubscribed from events removed about 80% of my coupling across the system. All components had the right to post events to the system and really became the piping for alot in my game engine. This event system was VERY basic, passing around an event type, subtype and a payload (it could be anything else, this is just my example). I still have coupling afterwards but now only for creating certain entities in game. The model itself allows you to have completely different classes and systems convey simple loosely coupled messaging between systems. Having said that, my Eventmanager was a Singleton, which probably contradicts point 2 to a degree.
Secondly, Globals most of the time won't help, in fact, it just makes it worse in many cases (YES, they do help in some spots, so its actually cleaner way although they are a bit of a crutch) . So I used container classes for the more major manager objects and don't be afraid to group managers into specific containers, my grouping was coarse, graphics and game logic managers for example.
In respects to globals, I found that it meant I had flattened the dependency tree of the various system components. Removing the globals meant I was forced to address the hierarchy of my critical objects and order them more logically. The globals were a reflection of my lack of planning in the architecture of my engine. It has a number of roll improvements once I had fixed this, controlling the order of destruction and creation of objects was natural. Rather than having to understand explicitly dependence of objects, it was implied and also enforced a standard.
Thirdly (and a little off topic), you will continue to learn and that will mean you will see patterns where you didn't before. So don't be hard on yourself, there is code you will look at and say "What the hell was I thinking.". Always revise, and improve. You can read a book, but if you shoe horn yourself into a discipline/design and don't end up liking it, it will kill your enjoyment. So diving in on your project can be a good and bad experience, but just keep learning.
Finally, all is a disclaimer, because of my experience with developing my own game. I've learned alot and would redo some things from the start, but I have had some surprising results around design and execution just through learning. good luck. Everyone's experience is different, I'm sure you will get some good tips from others on here.