No. This is one component of Prime which is no longer a microservice. Indicating they still heavily use microservices.
They needed to solve a problem. It was probably a low priority thing they wanted, didn’t need it to scale as or be highly used. They designed and built it quickly.
It outgrew the architecture.
But during that time it solved the problem and made them money.
The requirement of software is to solve a problem. A second requirement is often to make money. It ticked both boxes.
That does not mean it’s bad design. This is something juniors and intermediate programmers forget. That something does not need to be designed perfectly on day one. It needs to work.
> A second requirement is often to make money. It ticked both boxes.
In this case it caused 10x higher AWS bills when compared to proper design, so I'm not sure if it ticked the second box.
If you know that your product will absolutely outgrow the architecture soon (again, we are talking about Prime Video) it makes more sense to design it properly from the beginning.
> They designed and built it quickly.
> That something does not need to be designed perfectly on day one. It needs to work.
But they tried to design it perfectly on day one, with the wrong assumptions. A monolith would be easier to design and quicker to implement. Again, I am speaking for this special case (because of the scale of the company/product). This is not premature optimisation, it is common sense.
They needed to solve a problem. It was probably a low priority thing they wanted, didn’t need it to scale as or be highly used. They designed and built it quickly.
It outgrew the architecture.
But during that time it solved the problem and made them money.
The requirement of software is to solve a problem. A second requirement is often to make money. It ticked both boxes.
That does not mean it’s bad design. This is something juniors and intermediate programmers forget. That something does not need to be designed perfectly on day one. It needs to work.