I'm with you on this one. I was an architect of a quite large SVOD streaming service and this sounds like a runaway engineering division that's lost.
Sure, you can log and trace every tiny event but they've forgotten to ask whether or not they should and what are you getting out of it. It's creating a problem that doesn't exist, then solving it (by creating 2 more complex systems). 500 microservices sounds excessive but not out of the realm of belief.
I do wonder if it might relate to the way they're measuring engineering performance.
I think you're misunderstanding Netflix's scale and their culture. I am sure the SVOD service you architected was great but it probably wasn't Netflix scale.
Netflix's culture is heavily biased towards collecting metrics and experimenting with them. Their entire ethos is data oriented therefore they tend to capture a lot of metrics. You are terming it as a 'runaway engineering division that's lost' is unfair. You probably need to work at their scale for a while to appreciate the complexity of their business and technology needs. If it was easy to build Netflix, then everyone would.
From my BA experience it could also be a runaway project manager issue or runaway data analytics issue as people just say hey let's get that piece of data.
Is it useful? Rarely asked. But more importantly, they rarely got pulled off when proved to be useless.
Sure, you can log and trace every tiny event but they've forgotten to ask whether or not they should and what are you getting out of it. It's creating a problem that doesn't exist, then solving it (by creating 2 more complex systems). 500 microservices sounds excessive but not out of the realm of belief.
I do wonder if it might relate to the way they're measuring engineering performance.