Trei feluri în care se strică o sincronizare în două sensuri
Să ții două calendare la pas pare simplu până când ambele părți pot scrie. Atunci se strică în trei feluri ușor de recunoscut: duplicate, bucle și avalanșe de notificări. Le-am rezolvat pe toate trei, pe Microsoft Graph, la scară enterprise.
Cum se rupe bucla
O buclă începe când propria noastră scriere se întoarce ca noutate. Scriem un eveniment în Outlook, Graph trimite un webhook pentru acea scriere, iar o integrare naivă tratează webhook-ul ca pe o modificare nouă și scrie din nou.
Soluția este să recunoști un ecou. Comparăm strict change key-urile și ETag-urile ca să deosebim o modificare reală de reflexia propriei scrieri și ținem în Redis valori de idempotență cu viață scurtă, astfel încât aceeași modificare să nu fie aplicată de două ori. Același mecanism ține departe și duplicatele.
Așteptăm să treacă furtuna
Graph este generos cu notificările. O singură editare simplă poate ajunge ca cinci sau șase apeluri de webhook, iar schimbările de participanți sau editările în masă înmulțesc asta. Dacă reacționezi la fiecare, faci aceeași muncă de șase ori și notifici oamenii de șase ori.
Așa că notificările nu sunt procesate pe măsură ce sosesc. Sunt strânse într-un bucket, iar bucket-ul este procesat după ce furtuna s-a încheiat.
Limitele de rată și singura dată când am atins una
Tot lucrul cu Graph trece prin cozi, cu token-uri ținute în cache per tenant. În funcționare normală nu am ajuns la throttling din partea Graph.
Singura dată când Graph ne-a limitat, cauza nu a fost volumul de cereri. Problema era pe partea de ieșire a propriei noastre rețele: porturile SNAT. Mărirea numărului de porturi de ieșire alocate a rezolvat-o. Este o lecție utilă: o eroare de limită de rată nu ține întotdeauna de rata cererilor tale.
Subscripții care se reînnoiesc singure
Subscripțiile de webhook din Graph expiră, iar o subscripție expirată cade în liniște: modificările pur și simplu nu mai sosesc. Cron-uri reînnoiesc fiecare subscripție cu o zi înainte de expirare și reîncearcă la fiecare eșec. Dacă o reînnoire tot eșuează, primim o alertă.
Acolo unde oamenii lucrează deja
Add-in-ul de Outlook, aplicația de Teams și sincronizarea de atribute din Azure AD au aceeași idee: nimeni nu ar trebui să deschidă un al doilea sistem. Dacă o echipă trăiește în Teams, rezervarea se face în Teams. Dacă trăiește în Outlook, se face în Outlook. Atributele utilizatorilor urmează Azure AD, așa că oamenii nu sunt întreținuți în două locuri.
Niciodată terminat
Integrarea este în producție de câțiva ani, cu monitorizare și alerte pe modurile de eșec care se repetă. Nu este un proiect care s-a încheiat. Există mereu o mică îmbunătățire de făcut, iar ownership-ul clar asupra întregii suprafețe face ca ea să fie făcută.