Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Incorrect. Frequently, UI lag on components that hit server side back services is made significantly worse by naïve microservices, especially in the face of organic growth.

Specifically, every API call that traverses a machine, boundary, necessarily impart, additional latency, and uncontrolled microservices can have a multiplicative effect



I agree that a bad implementation may lead to poor performance. However, this is irrespective of the architecture. The effects of an architecture are more noticeable in the context of maintainability, scalability, and extensibility.

Or perhaps I am misunderstanding your comment?


it's not actually irrespective of architecture. Some architectures are significantly more prone to certain kinds of problems than others. For example, monoliths can become so large as to make development, especially many-team development, inconvenient or impossible. In the specific case of microservices, the key benefit (multiple teams can develop and deliver in parallel without stepping on each other, separating concerns into their own ownership areas) has the tradeoff of distributed systems overhead, which can range from high latency (when a number of microservices are in a serialized hot path and the complexity is not being effectively managed) to lowered availability or consistency (when data is radiating through a network of microservices asynchronously and different services 'see' different data and make conflicting correct decisions). Monoliths see this set of performance problems much, much later in their lifecycle, because they have much better data locality and local function call characteristics.


Anything that is front-facing a UI or API typically has a response cache.

More so for something like a web app like AppleTV where the content is largely static.

There should be zero difference in performance between microservices and monolith in this scenario.


Incorrect. Many calls, such as to auth, identity, ad service, metrics, etc., cannot be cached.


Ad serving and metrics are asynchronous so won't block any UI. And authentication/identity has the same behaviour with monolith/microservices. It's ultimately just a look up this user in some database.

It's the serving of the content that requires coordination across multiple services and most of that should be cached at the serving layer.


Incorrect, in most apps nontrivial content is highly personalized and dynamically served, auth in microservices is frequently two or more hop rather than one hop, and ad serving and metrics frequently involve synchronous steps.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: