3 ms·

But it also says it was never intended or designed to run at high scale. They built something that solved the problem at the time. It worked. They outgrew it a

But it also says it was never intended or designed to run at high scale. They built something that solved the problem at the time. It worked. They outgrew it and evolved the architecture. Now everyone’s on HN and Twitter claiming to be experts saying they would never do that and they know better.

selcuka 3y ago
> But it also says it was never intended or designed to run at high scale. Doesn't this statement itself indicate bad design? I mean, it's Amazon Prime Video. If you design a system for Prime Video you should design it to run at high scale.
- throwaway2990 3y ago
  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.
  - selcuka 3y ago
    > 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.

selcuka 3y ago

> But it also says it was never intended or designed to run at high scale. Doesn't this statement itself indicate bad design? I mean, it's Amazon Prime Video. If you design a system for Prime Video you should design it to run at high scale.

throwaway2990 3y ago
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.
- selcuka 3y ago
  > 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.