4 ms·
The single biggest way to mitigate this is to switch from "push" to "pull" architecture where possible. Let the central servers reach out to the "clients" at th
by pphysch 3y ago
The single biggest way to mitigate this is to switch from "push" to "pull" architecture where possible. Let the central servers reach out to the "clients" at their own honest pace. Not every process can be modeled this way, but a surprising amount can, particularly internal processes where you control all of the agents.
- cbsmith 3y agoIronically, stream processing, which we tend to call "push" architecture, is largely the same solution.
- pphysch 3y agoDo you mean something like "at most once" delivery over UDP?
- cbsmith 3y agoNo, that's more like traditional load shedding. I'm talking more like Kafka/NATS/0mq/etc.
- pphysch 3y agoSure, but that's just moving most of the chaos from your app to a message bus. Which is almost always correct, assuming you are actually at the scale where you need that level of architectural complexity.
- cbsmith 3y agoI wouldn't agree that it is moving reliability issues to the message bus. This is more a scaling/availability problem than a reliability problem, but the message bus is definitely helping to solve scaling/availability problems. While Kafka can indeed be pretty complex, streaming architectures aren't necessarily complex at all. For example, having a AWS Kinesis stream sitting in front of an AWS Lambda is pretty simple, and provides efficiency benefits even at comparatively small scale.