3 ms·
Those are good advice and they are battle hardened experience. I would like to add a few points. 1. Design the program as if it has crashed the last time. Al
by ww520 11y ago
Those are good advice and they are battle hardened experience.
I would like to add a few points.
1. Design the program as if it has crashed the last time. Always start up to recover from the last crash state. A normal shutdown is just simply the degenerate case. This would make restart and retry of program so simple.
2. Do retry with RANDOM exponential backoff to spread out the load. You don't want all the retries end up at the same intervals.
- dvirsky 11y agore 1 - better design a program with no state beyond configurations.
- gabbo 11y agoEasier said than done, if you don't have any state you're probably not doing something all that interesting. The trick is to keep your state in the right place, the answer usually being to punt state management to a database/message queue/etc. - you definitely want to avoid, say, stateful frontends.
- fanf2 11y agoPattern 1 is called "crash-only software" https://www.usenix.org/conference/hotos-ix/crash-only-software https://www.usenix.org/conference/hotos-ix/crash-only-softwa... https://en.wikipedia.org/wiki/Crash-only_software https://en.wikipedia.org/wiki/Crash-only_software