There's a lot of benefits to this approach over a database join if you have async IO. Specifically, sharding becomes trivial and you can cache each movie individually, so if one movie changes you don't need to invalidate the cache for all of them.
Yes, it might make sense if you're Facebook or Amazon to do this stuff. For the rest of us, a single (reasonably optimised) database can scale up to thousands of hits per second. Probably more.
Also there's another downside to this approach: you lose the ability to do atomic transactions on the application's data.
Sure, but if you ever need to shard, you can no longer assume you can do atomic transactions anyway, which means you need to rewrite a lot of stuff.
By designing in this way, your scaling problems change from "the entire app fell over" to "the movie service fell over", which really helps with availability.
Not that there aren't disadvantages with microservices (overhead, distributed tracing, etc), I just think app architecture isn't one of them.
Right, so you implement this multi-get for every service, you work around the GET URL length limit by using POST or something, you do this slow HTTP join in parallel with any other service data you need if possible, in your application code, and you get what a single SQL JOIN gives you.