ਹਰ ਕੋਈ ਰੀਅਲ-ਟਾਈਮ ਅਪਡੇਟਸ ਚਾਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਉਹ ਇਹ ਨਹੀਂ ਸਮਝਦੇ ਕਿ "ਤੇਜ਼" ਅਤੇ "ਸਹੀ" ਇੱਕੋ ਗੱਲ ਨਹੀਂ ਹਨ। ਇੱਕ ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਸਿਸਟਮ (distributed system) ਵਿੱਚ, ਇਵੈਂਟਸ ਪ੍ਰਕਾਸ਼ ਦੀ ਗਤੀ ਨਾਲ ਚੱਲ ਸਕਦੇ ਹਨ ਅਤੇ ਫਿਰ ਵੀ ਗਲਤ ਕ੍ਰਮ ਵਿੱਚ ਪਹੁੰਚ ਸਕਦੇ ਹਨ। WebSockets ਡਿੱਗ ਸਕਦੇ ਹਨ ਅਤੇ ਦੁਬਾਰਾ ਕਨੈਕਟ ਹੋ ਸਕਦੇ ਹਨ। Message brokers ਪੈਕੇਟਾਂ ਨੂੰ ਦੁਬਾਰਾ ਭੇਜ ਸਕਦੇ ਹਨ। Background workers ਟਾਈਮਆਊਟ ਕੈਂਸਲੇਸ਼ਨ ਦੇ ਵਿਰੁੱਧ ਦੌੜਦੇ ਹਨ। ਨਤੀਜਾ? ਇੱਕ ਕਲਾਇੰਟ ਇਵੈਂਟ 42 ਦੇਖ ਸਕਦਾ ਹੈ, ਫਿਰ ਇਵੈਂਟ 40, ਫਿਰ ਇੱਕ ਸਨੈਪਸ਼ੌਟ ਜੋ ਦਾਅਵਾ ਕਰਦਾ ਹੈ ਕਿ ਸਿਸਟਮ ਪਹਿਲਾਂ ਹੀ ਇਵੈਂਟ 45 'ਤੇ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ ਏਜੰਟ ਵਰਕਫਲੋ (agent workflows) ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਉਹ ਹਫੜਾ-ਦਫੜੀ ਕੋਈ ਐਜ ਕੇਸ (edge case) ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਬੇਸਲਾਈਨ ਹੈ। ਡਿਲੀਵਰੀ ਦੇ ਮਿਲੀਸੈਕਿੰਡ ਘਟਾਉਣ ਦੀ ਚਿੰਤਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਇਵੈਂਟਸ ਦੇ ਕ੍ਰਮ ਨੂੰ ਠੀਕ ਕਰੋ।
"Real-Time" ਦੀ ਉਲਝੀ ਹੋਈ ਹਕੀਕਤ
ਰੀਅਲ-ਟਾਈਮ ਇੱਕ ਟ੍ਰਾਂਸਪੋਰਟ ਪ੍ਰੋਪਰਟੀ ਹੈ। ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਇੱਕ ਪੈਕੇਟ ਤਾਰ ਰਾਹੀਂ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਚਲਦਾ ਹੈ, ਨਾ ਕਿ ਇਹ ਕਿ ਉਹ ਜੋ ਕਹਾਣੀ ਸੁਣਾ ਰਿਹਾ ਹੈ ਉਹ ਤਰਕਪੂਰਨ ਹੈ ਜਾਂ ਨਹੀਂ। ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ ਕੰਮ ਹਰ ਅਸੰਗਤਤਾ ਨੂੰ ਵਧਾ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਸਮੇਂ ਦੇ ਨਾਲ ਫੈਲੇ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਮਾਡਲ ਟ੍ਰੇਨਿੰਗ ਜੌਬ, ਇੱਕ ਮਲਟੀ-ਸਟੈਪ ਅਪਰੂਵਲ ਫਲੋ, ਜਾਂ ਇੱਕ ਵੀਡੀਓ ਰੈਂਡਰਿੰਗ ਪਾਈਪਲਾਈਨ ਮਿੰਟਾਂ ਜਾਂ ਘੰਟਿਆਂ ਦੌਰਾਨ ਦਰਜਨਾਂ ਇਵੈਂਟਸ ਜਾਰੀ ਕਰ ਸਕਦੀ ਹੈ। ਉਸ ਦੌਰਾਨ, ਕੁਝ ਵੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ।
ਇੱਕ ਬ੍ਰੋਕਰ ਕਿਸੇ ਸੁਨੇਹੇ ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇੱਕ ਐਕਨੌਲੇਜਮੈਂਟ (acknowledgement) ਗੁੰਮ ਹੋ ਗਈ ਸੀ। ਇੱਕ ਲੋਡ ਬਾਲੈਂਸਰ ਦੋ ਇਵੈਂਟਸ ਨੂੰ ਵੱਖਰੇ ਨੈੱਟਵਰਕ ਪਾਥਾਂ ਰਾਹੀਂ ਰੂਟ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਨਵਾਂ ਇਵੈਂਟ ਪਹਿਲਾਂ ਪਹੁੰਚ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਵਰਕਰ ਪ੍ਰੋਸੈਸ ਡਾਟਾਬੇਸ ਵਿੱਚ ਲਿਖਣ ਤੋਂ ਬਾਅਦ ਪਰ ਸਫਲਤਾ ਇਵੈਂਟ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਦੂਜਾ ਵਰਕਰ ਕੰਮ ਨੂੰ ਚੁੱਕਦਾ ਹੈ ਅਤੇ ਆਪਣੀ ਪ੍ਰਗਤੀ ਜਾਰੀ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ ਫਰੰਟਐਂਡ ਇਹ ਮੰਨਦਾ ਹੈ ਕਿ ਸਭ ਤੋਂ ਨਵਾਂ ਸੁਨੇਹਾ ਸਭ ਤੋਂ ਸਹੀ ਸੁਨੇਹਾ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਅਜਿਹੀ ਸਥਿਤੀ (state) ਦਿਖਾਏਗਾ ਜੋ ਕਦੇ ਸੀ ਹੀ ਨਹੀਂ। ਉਪਭੋਗਤਾ "completed" ਬੈਜ ਨੂੰ ਵਾਪਸ "processing" 'ਤੇ ਫਲਿੱਕਰ ਕਰਦੇ ਦੇਖਣਗੇ, ਜਾਂ ਇਸ ਤੋਂ ਵੀ ਮਾੜਾ, ਇੱਕ ਰੱਦ ਕੀਤਾ ਗਿਆ ਕੰਮ ਅਚਾਨਕ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਹੋ ਜਾਵੇਗਾ। ਕ੍ਰਮ (ordering) ਤੋਂ ਬਿਨਾਂ ਸਪੀਡ ਸਿਰਫ ਉੱਚ ਫਰੇਮ ਰੇਟ 'ਤੇ ਉਲਝਣ ਹੈ।
ਸੀਕੁਐਂਸ ਨੰਬਰ ਹੀ ਅਸਲੀ ਘੜੀ ਹਨ
ਇਸ ਦਾ ਹੱਲ ਪ੍ਰੋਡਿਊਸਰ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਗਏ ਸਖ਼ਤ, ਮੋਨੋਟੋਨਿਕ (monotonic) ਸੀਕੁਐਂਸ ਨੰਬਰ ਹਨ। ਹਰ ਉਹ ਆਪਰੇਸ਼ਨ ਜੋ ਸਟੇਟ (state) ਨੂੰ ਬਦਲਦਾ ਹੈ, ਉਸ ਨੂੰ ਇੱਕ ਅਜਿਹਾ ਨੰਬਰ ਮਿਲਦਾ ਹੈ ਜੋ ਬਿਨਾਂ ਕਿਸੇ ਗੈਪ ਜਾਂ ਰੋਲਬੈਕ ਦੇ, ਬਿਲਕੁਲ ਇੱਕ ਨਾਲ ਵਧਦਾ ਹੈ। ਉਹ ਨੰਬਰ ਇਵੈਂਟ ਦੇ ਨਾਲ ਹੀ ਉਸੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਵਿੱਚ ਸੁਰੱਖਿਅਤ (persist) ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਡਾਟਾਬੇਸ ਰੋਅ ਅਪਡੇਟ ਹੁੰਦੀ ਹੈ ਪਰ ਸੀਕੁਐਂਸ ਕਮਿਟ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਦੋਵਾਂ ਨੂੰ ਰੋਲਬੈਕ ਕਰ ਦਿਓ। ਇਹ ਤਰਕਸ਼ੀਲ ਟਾਈਮਲਾਈਨ ਨੂੰ ਸਟੇਟ ਚੇਂਜ ਦੇ ਨਾਲ ਅਟਮਿਕ