Tak ono staci se podivat trocha na coalescing... jak ty zavisle ukoly planovat tak, aby se to nezahltilo.
Problem je velice podobny tomu s cim se musi vyporadat napr cron - pokud ukol trva dele nez hodinu a mate to naplanovano v hourly, tak jaky pristup zvolit? Nasilne dodrzovat plan, ze se to bude poustet co hodinu ale riskujete zahlceni.. anebo se pozadavek vypusti, kdyz dana vec se nestihla dokoncit v ramci sveho periodickeho okna?
Zprávička je o tom, že Amazon měl v automatických úlohách spouštěných na pozadí léta chybu race condition, která se projevila teď po letech a v důsledku způsobila chyby mnoha služeb v nejdůležitějším regionu AWS skoro na celý den. Argument „mně to tak léta funguje“ mi pod takovou zprávičkou připadá poněkud bezzubý.
Že je kód, kde by mohlo docházet k race condition, správně, se neověří tak, že ten kód dlouho poběží bezchybně. Ověříte ho jedině tak, že kód projdete, zjistíte, co dělá, jaké jsou předpoklady toho, co dělá, a ověříte, že všechny ty předpoklady jsou splněné.
Je dost možné, že to tak máte, protože zajistit na Linuxu pomocí zamykacího souboru, že proces poběží maximálně jednou, je jednoduché. (Zajistit, že poběží právě jednou, je úplně jiná disciplína.) Ale „běží to dlouho bez chyb“ to nedokazuje.