Great to know! I’m happy I wasn’t being lied to and that an Amazon engineer would just spill the beans like that (probably to sell me on AWS). Amazing that the architecture that is probably 5 or even 10+ years old and would still be considered state of the art today.
Yeah, the stuff I work on has a similar meta-service dependency.
I’m sure there have been some changes to make things more efficient, I would guess that most of the page is baked so that you don’t have to call a bunch of services to stitch the page together, so the real work on the backend is making that bake process quick to incorporate new data (reviews and comments mostly). Probably the only part of the page that isn’t baked into the larger page is the recommendations part since it’s dependent on the user. The larger page would still be divided into chunks that load dynamically so that it comes up quicker. Again, I don’t work on it, these are just my assumptions based on how we do similar things in AWS.
I generally follow a rule that if you need to interleve more than a handful of services’ data to serve a single request, you stick an aggregating/caching middle tier in there.
Or maybe those services should have been one service to begin with.
Well, in those cases it’s always that those services are being used independently elsewhere as well. Lots of single-service callers.
But then there’s one thing that needs to call a bunch of those otherwise-independent services.
Depends how frequently this aggregate call is made and how many other services need access to that aggregate.