Nrthugu

We have an application where users can sign in only with Facebook. On successful Facebook login an another http rest call is made to store the name, email and some other information from Facebook login provider. We would end up with data consistency issues if The second RESTful service fail to store the information from fb to the the Mongodb

1. User can only signup/ sign in via Facebook


2. On every successful signup Facebook sends back the some information like the users name, email and uid


3. We then store this information on our database immediately

So if the 3rd step fails, we loose the information about the user who signed up via Facebook.

loginWithFacebook() {

      const provider = new firebase.auth.FacebookAuthProvider();

      provider.addScope('user_birthday');

      provider.addScope('user_friends');

      provider.addScope('user_gender');

      return new Promise<any>((resolve, reject) => {

        this.afAuth.auth

        .signInWithPopup(provider) // a call made to sign up via fb

        .then(res => {

          if (res) {

            resolve(res);

            if (res.additionalUserInfo.isNewUser) { // creatin profile only if he is a new user

              this.createProfile(res); // a call to store the response in the db

            }

            this.setTokenSession(res.credential.accessToken);

          }

        }, err => {

          console.log(err);

          reject(err);

        })

      })

    }

Is there a neat architectural way of orchestrating this?

Buckle up, because this is not a trivial problem.

If this is a true microservice architecture, where each service has it's own dedicated database, then you obviously can't efficiently perform a transaction. You might be able to do a 2-phase commit but that has problems of it's own, especially with long-lived DB locks.

A scalable approach to your problem is the Distributed Saga Pattern:

Implement each business transaction that spans multiple services as a saga. A saga is a sequence of local transactions. Each local transaction updates the database and publishes a message or event to trigger the next local transaction in the saga. If a local transaction fails because it violates a business rule then the saga executes a series of compensating transactions that undo the changes that were made by the preceding local transactions.

I think the above covers it pretty succinctly so I'm going to intentionally veer off on a tangent:

Distributed systems are hard to manage. Make sure you aren't violating YAGNI with your system architecture. If possible, ask yourself whether you really need a distributed architecture at this point.

Ensuring data consistency in a distributed system is a relatively complex
task that in most cases requires a dedicated coordinator service, extra code to manage it all and all the complexity that comes with all this extra machinery.