Webhooks - Slanje i automatsko gašenje
Webhook je jednostavan mehanizam koji omogućava da web aplikacije međusobno komuniciraju. Princip je prilično jednostavan i oslanja se na postojeće web tehnologije.
Kada se nešto bitno u aplikaciji #1 desi, ta aplikacija napravi HTTP zahtev na unapred definisan URL aplikacije #2 sa detaljima o tom događaju. Na primer, kada korisnik napravi zadatak u svom ActiveCollab nalogu, ActiveCollab može da pošalje detalje o tom događaju drugoj aplikaciji koja proveri da li je zadatak visokog prioriteta i ako jeste pošalje SMS osobi koja dežura (stvaran scenario).
ActiveCollab ima podršku da šalje webhookove već 5 godina. Ono što nije imao do nedavno je mogućnost da sam sebe “zaštiti” od aplikacija koje su prestale da primaju webhookove ili su počele da vraćaju greške. Umesto da prepozna probleme i prestane sa slanjem, naš sistem je jednostavno nastavljao da šalje bez obzira na to šta druga strana radila. To nam je napravilo probleme u par navrata, kada nam se red za slanje zagušivao. Problem mi se učinio zanimljivim i po prirodi je takav da sam mogao njime da se bavim bez da saplićem timove koji radi na proizvodu, pa sam uzeo da ga radim.
Prva stvar koju je trebalo uraditi je odlučiti šta sistem tačno da radi kada uoči da je sistem sa druge strane prestao da odgovara ili da vraća greške. Pogledali smo par drugih aplikacija i ne postoji jedan “najbolji pristup”. Problem je pre svega u tome da razaličiti sistemi različito šalju obaveštenja: neki šalju serijski, jedan po jedan zahtev, neki paralelno, neki šalju puno događaja, neki malo, kod nekih su obaveštenja izuzetno bitna (tipa, podaci o naplatama), a kod nekih ne toliko.
Druga stvar koji smo znali je da treba da prestanemo da šaljemo webhookove na sistem koji ne odgovara (ili odgovara sa greškom), ali nismo hteli to da uradimo na prvi znak problema. Umesto toga, hteli smo da napravimo takav sistem da prestajemo sa slanjem kada smo sigurni da problem na drugoj strani nije privremen, a da nas naša želja da budemo sigurni ne dovede do novih zagušenja. Jer dok mi čekamo da se skupi dovoljno podataka da nam potvrdi da je sistem sa druge strane nedostupan, slanje ka tom sistemu može izazvati usporenje ili čak i zagušenje reda za slanje.
Tokom priče o tome kako da rešimo problem, tim je predložio da umesto gašenja prvo spustimo prioritet problematičnim sistemima. Na ovaj način bi red za slanje uvek prvo slao stabilnim sistemima, a nestabilnim bi se bavio tek kada taj posao završi. Kada se nakupi dovoljno podataka da određeni sistem okarakterišemo kao nedostupan, tek onda bi ga gasio. Evo kako smo napravili da sistem radi:
Imamo tri nivoa prioriteta - visok, normalan i nizak,
Krećemo sa poverenjem i svim sistemima se u startu dodeljuje visoki priortet,
10 uzastopnih neuspeha pri slanju smanjuje prioritet sa visokog na normalan. Sledećih 10 uzastopnih neuspeha će ga spustiti na nizak,
Promena prioriteta radi i u suprotnom smeru - 10 uzastopnih uspeha diže prioritet, sa niskog na normalan, pa posle na visok,
Ukoliko sistem u 4 sata ima procenat greške od 50%, a ne manje od 10 slanja, prestajemo sa budućim slanjem i obaveštavamo administratora o tome.
Ovaj sistem smo pustili u rad prošle nedelje i radi lepo. Do puštanja smo imali ~30% neuspelih slanja. Sada smo na ~1%. Greške nikada nećemo moći skroz isključiti, zbog prirode sistema, ali nizak jednocifren procenat je nešto sa čime možemo da radimo.
Nadam se da vam je ova priča bila koliko-toliko zanimljiva. Napisao sam je kao još jednu perspektivu i moguće rešenje za problem komunikacije između dva sistema razmenom webhookova. Kada ne postoji "najbolje rešenje" imati na raspolaganju različite ideje i iskustva nije višak. Nama svakako kombinacija prioriteta i gašenja u prvom krugu razmišljanja nije bila očigledna, ali nam se kasnije pokazala kao prihvatljiv balans između pouzdanosti i brzine reakcije.
Do sledećeg čitanja, pozdrav. 👋
Fotografija: Joe Dudeck @ Unsplash.
