Strategia per garantire la coerenza durante l'integrazione utilizzando un'API?

0

Come posso garantire la coerenza tra due sistemi separati che memorizzano e mantengono lo stesso insieme di dati, quando il metodo di comunicazione tra loro è API REST e webhook? È possibile?

Mi trovo a riscontrare questo problema quando lavoro con API come MailChimp o eBay, dove il sistema di terze parti agisce come un sistema complementare per un CRM interno o un negozio online. (Anche se sto menzionando servizi specifici qui, quello che sto ottenendo è un modo generale per ottenere coerenza usando API e webhook, motivo per cui penso che la domanda appartenga qui.)

Esempio

Diciamo che chiamo la mia applicazione MyApp e l'applicazione ThirdApp di terze parti. Entrambi memorizzano le informazioni sui miei clienti. Un ID univoco, un indirizzo email e alcune preferenze.

Quando un client viene aggiornato su MyApp, posso fare una chiamata API a ThirdApp per informarli delle modifiche, in modo che possano aggiornare la loro versione dei dati.

Allo stesso modo, se qualcuno apporta una modifica a un'entità client su ThirdApp, posso impostare un webhook in modo che ThirdApp possa informare MyApp della modifica.

Non voglio aspettare che le chiamate API vengano completate ogni volta che aggiorno un client su MyApp - se l'API di ThirdApp smette di rispondere, MyApp non sarebbe in grado di apportare modifiche, il che è indesiderabile.

Allo stesso modo, ThirdApp presume che MyApp sia a posto con qualsiasi modifica si applichi, comunque. Non aspetta di impegnarsi con le modifiche: la richiesta di webhook che invia per avvisare MyApp del cambiamento è in realtà solo un messaggio di cortesia.

È possibile garantire coerenza (forse finale?) in questa situazione?

Forse un sistema di accodamento delle modifiche?

Ho pensato di utilizzare una sorta di sistema di accodamento intermedio sul lato MyApp, con modifiche in entrata e in uscita, ma mi sembra sempre di poter pensare a modi in cui le cose potrebbero finire incoerenti. Ad esempio, immagina se il client 123 ha un indirizzo di [email protected] e la coda in attesa è simile a questa (nessuna delle voci della coda è stata ancora elaborata):

  1. OUTGOING MyApp dice che l'ID cliente% l'indirizzo email di123 è cambiato in [email protected]
  2. ...
  3. INCOMING ThirdApp afferma che l'ID cliente% l'indirizzo email di123 è cambiato in [email protected]

Se la coda è stata elaborata o meno, ThirdApp è corretta nella memorizzazione di [email protected] come indirizzo email del client. Tuttavia, mentre elaboriamo in sequenza la coda:

  1. La modifica in uscita invia una chiamata API a ThirdApp, "il nuovo indirizzo email per 123 è [email protected] .
  2. ... succede qualche altra cosa, durante la quale entrambi gli indirizzi email sono sbagliati ...
  3. La modifica in entrata significa che MyApp aggiorna la sua 123 entità in modo che l'indirizzo email sia [email protected] . MyApp ora è corretto, ma ThirdApp è sbagliato.

Probabilmente per risolvere il problema potrei implementare una sorta di logica look-ahead nel processore di coda, che proverà a determinare quale dovrebbe essere l'azione "corretta", in base a quali altre voci successive influenzano il record dato più in basso nella coda . Questo sembra che potrebbe essere molto complicato però.

Forse una terza, unica fonte di verità?

Forse la soluzione è di avere una terza copia delle informazioni, gestita da un terzo sistema, che sia MyApp che ThirdApp inviino le informazioni di aggiornamento e ne riceve gli aggiornamenti. Quindi qualsiasi modifica, sia da MyApp che da ThirdApp, è una modifica in entrata, e le chiamate API in uscita vengono effettuate per aggiornare di conseguenza altri custodi dei dati.

A questo punto sto iniziando a lottare davvero per tenere traccia della coerenza nella mia testa. Inoltre, sono scettico sul fatto che l'aggiunta di un'altra copia dei dati nel mix risolverà il problema - sembra probabile che lo renderebbe più complesso e, quindi, peggio.

Mi ritrovo anche a chiedermi se posso fidarmi di una richiesta di webhook da parte di ThirdApp per essere tempestiva o meno. Cosa succede se la modifica è stata apportata 20 minuti fa, ma la richiesta di webhook è stata appena inviata? Cambiamenti negli ultimi 20 minuti quindi dovrebbe sostituirli.

    
posta Alex 30.07.2018 - 20:25
fonte

1 risposta

0

Solo una prima impressione qui, penso che aggiungere un ulteriore livello di complessità sia una cattiva idea.

Eventualmente, Aggiunta di una convalida da parte tua che controlla l'altra posizione entro un certo periodo di tempo (dopo aver elaborato una richiesta in coda) per confermare che entrambi hanno le stesse informazioni 5 minuti dopo che una modifica sarebbe probabilmente un buon punto di arresto sei davvero preoccupato per più cambiamenti.

Oppure, apportare modifiche basate su un timestamp. Se un timestamp è precedente alla modifica più recente, rifiuta la modifica e conferma a ThirdApp che la tua versione è più importante.

    
risposta data 30.07.2018 - 20:40
fonte

Leggi altre domande sui tag