Kila mtu anataka sasisho za wakati halisi (real-time) mpaka pale wanapogundua kuwa "haraka" na "sahihi" si vitu vilevile. Katika mfumo uliosambazwa (distributed system), matukio yanaweza kusafiri kwa kasi ya mwanga na bado yakafika kwa mpangilio usio sahihi. WebSockets hukatika na kuunganishwa upya. Message brokers hutoa upya paketi. Wafanyakazi wa nyuma (background workers) wanashindana na ughairi wa muda uliopitiliza (timeout cancellations). Matokeo yake? Mteja anaweza kuona tukio la 42, kisha tukio la 40, kisha picha (snapshot) inayodai kuwa mfumo tayari upo kwenye tukio la 45. Ikiwa unajenga mifumo ya kazi za wakala (agent workflows) inayochukua muda mrefu, vurugu hiyo si jambo la nadra. Ni hali ya kawaida. Rekebisha mpangilio wa matukio yako kabla ya kuanza kuhangaika kupunguza milisekunde kwenye uwasilishaji.
Ukweli wa Vurugu wa "Wakati Halisi"
Wakati halisi ni sifa ya usafirishaji. Inaelezea jinsi paketi inavyosogea haraka kwenye waya, siyo ikiwa hadithi inayoeleza ina mantiki. Kazi zinazochukua muda mrefu huongeza kila kutofautiana kwa sababu zinavuka muda mrefu. Kazi ya mafunzo ya modeli (model training job), mtiririko wa idhini wa hatua nyingi, au mtiririko wa uundaji wa video (video rendering pipeline) unaweza kutoa makumi ya matukio kwa dakika au saa kadhaa. Katika kipindi hicho, chochote kinaweza kwenda vibaya.
Broker anaweza kujaribu tena ujumbe kwa sababu uthibitisho (acknowledgement) ulipotea. Load balancer inaweza kuelekeza matukio mawili kupitia njia tofauti za mtandao, na kuruhusu lile jipya lifike kwanza. Mchakato wa mfanyakazi (worker process) unaweza kufa baada ya kuandika kwenye hifadhidata (database) lakini kabla ya kuchapisha tukio la mafanikio, kisha mfanyakazi wa pili kuchukua kazi hiyo na kutoa maendeleo yake mwenyewe. Ikiwa sehemu yako ya mbele (frontend) inadhani kuwa ujumbe wa mwisho ndio ujumbe wa kweli zaidi, itachora hali