I am trying to build a rule-based chat application that will integrate with Facebook Messenger. The application will ideally have a set of flows, like registration of a customer, subscribing to a product, unsubscribing etc and the how of these flows will vary based on the country it's being deployed in, meaning there can be some sub-flows that are very local to the country.

So before I start coding, I wanted to have a high level overview of how things might be implemented keeping in mind that it could be required to scale up in about 6 months.

I have identified a few major interactions that the system will have with the persistence storage.

  1. The system needs to know that given a country, an input from the user of that country and his/her chosen language, what is to be displayed next to the user. This is the rule part of the application and this is going to be read-only. So I thought of persisting the rules in a NoSQL Database like MongoDB

  2. The system will need to capture things about the user or his subscription, like if he decides to subscribe to another product or unsubscribe or change his payment method etc. These are not going to happen very often in the flow and can be persisted directly in the DB. This part of the interaction is mostly read-heavy since very rarely will the user update his subscription.

  3. The system also needs to keep a track of the conversation with the user (the state of the conversation) and this is the part that I feel, is going to be both read-heavy and write-heavy. Because for every option the user selects, we need to capture exactly where in the flow he is and update it as he proceeds further into the flow. Sometimes, we need to show a specific menu with certain repetitions if we cannot parse his response and the number of repetitions will also need to be stored and updated. For this scenario, relying on a NoSQL DB may not scale up well as the interactions will have to happen as quickly as possible. I was thinking of going with something like Redis for this specific use case.

So I wanted the experts here to look at these choices of mine and tell me if they are good enough to scale horizontally. When the number of users grows and the flows and sub-flows get more complex, will Redis be able to handle this massive number of read-write operations? Will MongoDB scale well in this scenario?

Please do suggest improvements or changes if needed.

Thanks for your time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.