It is difficult to answer these questions with much clarity because they are conceptual and the concept applied to each of these could be widely different depending on the engine and needs of any particular game. So I'm going to try to be fairly general.
1. Scene Manager
The scene manager keeps track of the scenes in a game, allowing to switch between them. At it's basic, it provides a centralized place to load and unload the scenes, keeping track of which one is loaded and handle unloading that scene when a new one is loaded.
See here for a basic example of a SceneManager.
It can get quite a bit more complicated, depending on the engine/game but primarily, its job is to provide a place to manage all the scenes so that each scene doesn't need to be uniquely referenced in the game code. Instead of the game having to deal with 10 or 20 (or 100) different scenes all over the code for example, by using a SceneManager and assigning all the scenes to it the game code can refer to the SceneManager and never need to know about any particular scene, how many scenes there are or if one is added/removed. In this way, to the rest of the code the number of scenes and specific names of the scenes does not need to matter.
This is a rather generic description. Some games or engines may use the scene manager a bit differently but the general concept will still apply. Usually the difference will come down to how a scene is defined. In most engines a scene is an entire level. In others a scene might be a subset of a level. In yet others, there may be no concept of a scene and instead they use screens but the same idea would still apply.
Really, this is just a software design pattern. In other areas of software development, we might call this a Facade or Mediator design pattern.
2. Scene Graph
I'm not going to get into explaining all the details of what a scene graph is since I think that this article does a better job of explaining it than I could and this answer would be too long otherwise. I will summarize though.
A scene graph is essentially a hierarchy of all the objects in a scene with parent-child relationships, such that manipulating one parent will implicitly affect the children. This is useful so that if you have a large number of objects, you can make one change to a node in a scene graph and that change will implicitly affect all the children of that node.
There are two key things that the scene graph helps with:
- spatial relationships
- behaviour relationships
The gamedev article I linked above uses a good example of a solar system to demonstrate how a scene graph is beneficial. Another example might be a squadron of ships, where they all act independently but also behave as a group, like a flock of birds.
3. Where to Store Caches
This is very subjective. You might have a ResourceManager to handle these things for your engine. You might have a manager for each type of resource or you might have both, where the ResourceManager coordinates all of the specific managers for each resource type. How much you need to break it down depends on the complexity of your game engine. Stick to the KISS principle and modify your design as you find that things are getting too messy and unmanageable.
I'm no expert on these engine specifics. I'd rather leave these types of details to someone else to provide for me so I can focus on building games instead of implementing an engine that is likely going to be inferior to one that others have already spent a lot of time and effort to get right. I've learned enough to know why and how but explaining it is a little beyond my experience. Hopefully I'm not sharing incorrect information or missing any important details.