Realtidsdata

”Realtid” är ett svar på en fråga som inte ställts än. Frågan är vem som ska agera på datan, hur snabbt, och vad som går fel om den är för gammal. Först när du vet det går det att säga hur snabbt flödet behöver vara, och vad det får kosta.

Hur färskt är färskt nog?

Det beror på vad som händer med ett gammalt värde. Ett lagersaldo som ligger efter kan sälja något du inte har. En rapport kan läsas en gång i veckan och ändå behöva morgonens siffror på mötet. Ett larm från en maskin ska fram innan det är för sent att göra något, oavsett om mottagaren är en person eller ett automatiskt stopp. Vi ställer två frågor per flöde: hur gammal får datan vara i det ögonblick den används, och vad kostar det när den är äldre än så.

Svaren styr arkitekturen, flöde för flöde. Batch och händelsedrivet är två verktyg, inte två läger. Väljer du ett av dem för allt betalar du antingen för realtid där ingen agerar i realtid, eller väntar på en nattkörning där någon behövde svaret på förmiddagen.

Vad ett händelsedrivet flöde kräver

• En kö, så att mottagaren får hämta i egen takt utan att sändaren väntar.
• Mottagare som tål att samma händelse kommer två gånger. Kontrollera vad kön lovar: leverans minst en gång betyder att mottagaren måste känna igen en dubblett.
• Återförsök med växande väntetid, och ett tydligt slutläge för det som ändå inte går igenom.
• Möjlighet att köra om ett dygns händelser i efterhand, med en plan för vilka effekter som ska göras om och vilka som redan är gjorda.
• Övervakning som larmar på uteblivet flöde, inte bara på fel. Ett flöde som stannar ger inget felmeddelande.

Det sista är lätt att glömma. Kraschar en tjänst får du ett fel i loggen. Slutar en källa skicka får du en siffra som slutar röra sig, och den syns inte förrän någon undrar varför den står still. Därför bygger vi larm på frånvaro av data också. Ska datan vidare till dataanalys och rapportering eller driva processautomation är det samma flöden som matar dem.