Wobe Infrastructure

I have always felt that the best way to really learn a technology is to get it to do what you want it to do. Decide on the features of a mini project and make the technology do what you decided without any compromises. This is often a painful process and I wouldn’t recommend it for the weak of mind.

Its been 2 months since I joined Wobe and I recently shipped my first feature - a reward system for our users. In doing this mini project I was able to get my hands dirty with almost every part of the system, which gave me what I needed for this Blog post.

At a high level

The most unique facet of our Infrastructure is the way messages flow in the system. A major design constraint has been the unreliability of mobile communication.

In the mobile world, signals come and go and connections break and make. To carry on reliable communication over this kind of medium requires retries, acknowledgements etc. Instead of reinventing the wheel here we decided to hand this off to Firebase. Firebase gives us reliable communication to end user devices.

In our infrastructure the backend receives a well-formed https request from the client and immediately returns a 200 if all is well with the message. The message is then processed by the backend and the response is handed over to Firebase which reliably sends the response to the device.

The Backend

We have adopted the microservices route for our backend, using RabbitMQ message queue as the communication medium. This allows us to horizontally scale each microservice independently.

The HTTP-MQ Bridge listens for PUT requests from the Wobe mobile App and converts the request to a Message for a message queue on RabbitMQ based on the headers. The other microservices (which provide the backend functionality) subscribe to specific queues and handle the requests posted there.

Inter-microservice communication is also handled via RabbitMQ.

Once done with the message the response is posted to a queue subscribed to by the Notification Microservice. This service is responsible for converting the response messages into either Push notifications or Data messages in Firebase.

Data messages are for internal consumption by the Wobe mobile App and Push notifications will appear as messages from Wobe to the user on the system tray.

Each microservice logs events to Amazon Cloudwatch, Sentry or Datadog depending on what kind of data is being sent. Microservices talk to their own database if they want to. The databases we use presently are Postgres on Amazon RDS.

We also use Metabase to provide visualization of the transaction data to the rest of the company.

The Mobile Client

Finally, our mobile client is written in such a way to be able to handle this flow of messages.

React native + Redux + Sagas give us the ability to write manageable code in-spite of this weird message flow while maintaining responsiveness in the app.

Codepush allows us to upgrade our users fast and also gives us valuable information of the number of our users yet to upgrade. In rare cases where we are making a breaking change Codepush allows us to force-upgrade our users.

Conclusion

And that covers our infrastructure to a fairly decent depth. There are still some parts of the infrastructure which I have left out which deal solely with maintenance like Terraform which we use to manage our AWS deployment. I also have not mentioned the infrastructure that we wrote. I hope to cover those in a later Blog Post unless someone else gets there first.

I hope you found this useful, and I would love to hear your comments and suggestions.