Postoji raširen mit u razvoju softvera: ako integracija radi u testnom okruženju, radi i u produkciji. Praksa redovito opovrgava tu pretpostavku. Razgovarali smo s četiri razvojna tima u proteklih godinu dana i svaki je imao isti obrazac — integracija je prošla sve testove, a zatim se raspala čim je krenula prava prometna opterećenja ili neočekivani rubni slučajevi.
Prvi uzrok je neadekvatna obrada grešaka. Mnogi timovi testiraju happy path i zaboravljaju da vanjski API može vratiti neočekivane HTTP kodove, prazne odgovore ili odgovore u krivu formatu. Kada to dogodi u produkciji, aplikacija pada bez razumljive poruke o grešci.
Drugi uzrok su vremenski limiti koji nisu realistični za produkcijsko opterećenje. U testnom okruženju API odgovara za 200ms — u produkciji, pod opterećenjem, može trebati 3–5 sekundi. Timeoutovi postavljeni prema testnim uvjetima uzrokuju lančane otkazivanja.
Treći uzrok je ignoriranje rate limitinga. API dokumentacija jasno navodi limite poziva, ali timovi ih zanemaruju dok ih API provajder ne počne blokirati. Implementacija exponential backoffa nije neobavezna — ona je nužna.
Četvrti uzrok je nekontrolirana verzioniranost. Vanjski API mijenja verziju bez najave u testnom okruženju. Produkcija još uvijek koristi staru verziju. Integracija tiho počne vraćati krive podatke umjesto greške.
Peti uzrok je odsustvo monitoring i alertinga. Ni jedna od opisanih grešaka nije neotkriva — problem je što tim za njih sazna tek od korisnika. Provjerne točke koje definiramo u tekstu pomažu uhvatiti svaki od tih uzroka prije nego ode u produkciju.