To my knowledge it's pretty standard to do option (1) in a more classic IT sense. If you have an IT architecture built on top of many independent microservices (APIs) where each of them does one little thing very well in insolation, only to pass it on to another microservice to perform another thing, you're gonna end up passing on really large volumes of data that way. But that's actually completely fine, to my knowledge that is really what's considered the best practice in today's IT world.
In our DS department we embrace the same concept where the API is only responsible for receiving all the data in the request and using that data to make a prediction. We only relay on option (2) when for instance there is no IT service yet that can make the request with the entire requested payload in the form that we need it OR if that's a Shiny app and the user interacts with DB through the UI. Coming back to the prediction part, in the request we then accept some kind of an id (uuid) wich is only as a trigger to make the DB querying entirely on our APIs side.
Long story short, it sort of depends on the entire philosophy that your company has in terms of building up its IT architecture, but option (1) is what is generally preferred because the service is more isolated and faster. Btw: 20 variables is really nowhere close to "large amounts of data" 