I have a Node.js application with a collection name drivers. In which I store these fields called carId, vendorId and clientId . All these are of type ObjectId, which is native to mongodb. Used to search, to which client and vendor a driver belongs. With these, I also store fields like. carName = Ford Mustang,carRegNo, vendorName and clientName . Which are more user friendly and people can directly Identify with them. Now I have two choices when I retrieve driver documents.

1. When I start the Node application/perform any update I store say [{driverId : {carId , carName}}],[{driverId : {vendorId}}], [{driverId : clientId}] in array of objects and in cache like Redis and augment the response object to plug each field(vendorName, clientName,carName) into the response object. Thereby achieving the purpose
2. I store these fields in the driver itself and no need to do these kind of update on cache operations, or maintain a cache and keep augmenting the response.

Pros and Cons in my view

1. First method is better as it saves space on database, but how much is still a debatable question. I am not expecting more than a million drivers to join the platform say in next 3 years. So how much difference will it cost on space is what I am confused about.
2. Now a page say will be refreshed say 20 times a day, calling the cache method 20 times and retrieving an updated array will cost me some time, maybe microseconds at first, but keep on growing , if I increase the number of arrays and size of each one of them.

Which method is better I am unable to decide. If you have made a similar call in the past, probably you can help me make a better decision.