In my last story, I spoke in depth about the pace of technology change in the communication sphere, the prevailing trends as well as some predictions of what is to come over the next decade.
To prepare for the changes on the horizon, at Beem, we’ve been working on revamping our customer facing communication platform, for the last year. This hasn’t been just a new user interface or new features, but a complete rebuild from the ground up. This post attempts to explain the reasoning behind the revamp and goes into some detail about how we built it.
Why would you bring down a building to rebuild it again?
The original Beem sms platform was built almost 10 years ago with frameworks and technologies that were advanced at that time. This platform was incrementally improved, optimized, augmented multiple times since then and has served us well, but had reached its peak and was showing many limitations. The only option remaining was to rebuild it. So why did we bring down the building? Because we can’t build a skyscraper on the same foundation as a residential building.
The Goal Our aim has always been to enable our enterprise customers to deliver great mobile experiences for their customers. We had a foundation for a communication platform that had worked till date, but just wasn’t cut out for the next decade. We wanted to build a world-class communication platform that would continue to provide a great user experience, perform under high transaction volumes, would be very easy to integrate with and be extensible to evolve over time. A turbo-charged communication platform. Keeping in mind that we already had existing users on the old platform, we also needed to migrate existing customers seamlessly to the new platform and retain their existing data, settings, features etc. Below are some of the major decisions that we had to make in developing the platform as well as some more detail on the architecture.
Monolithic vs Micro-services One of the key design decisions that were made early on was to structure our platform as micro-services. This is very different to a traditional ‘monolithic’ software architecture that has everything incorporated into one program/service.
Micro-services is a recent ‘cloud-era’ architecture pattern that breaks down different modules of a system into micro-services that talk to each other via APIs. The advantage of this structure is that individual micro-service can be scaled based on demand / throughput, put on separate server instances and much more.
We employed the micro-services approach to developer reusable modules that would be launched as separate services but still be able to talk to each other and scaled on demand.
Choice of technology When we started analyzing the various technology stacks that we could or should use for this rebuild, we had to consider multiple factors. Primarily these included, ability to handle high performance requirements and scale, support for frontend and backend, availability of local talent and the learning curve for any new developer. We also did a lot of research on current trends, capabilities of various technologies to weigh up pros and cons. We had four major options:
- PHP
- Python
- Java
- Javascript (JS)
After extensive research and consultation, we made the decision to go with Javascript because it offered the best balance across multiple factors we had to consider.
While PHP was in our comfort zone, it would have failed to provide scalability. Python & Java were dropped because of their steep learning curve and a lack of local programmers with experience.
Javascript offered the most flexibility in terms of use for both frontend and backend services, availability of resources and the ability to handle large transaction volumes.
Leveraging Javascript and its inherent ability to execute operations asynchronously, we could build our micro-services architecture and support all the API calls to external and internal services with ease.
The Architecture
This diagram gives a birds-eye view of the overall platform architecture. The architecture is organized into separate layers based on functions and talk to each other via APIs. The micro-service approach as well as using cloud hosting technologies allows scaling across individual layers.
Customer Transition & Experience While startup businesses can do all this easily with little to no disruption to services, as a running business with hundreds of customers transacting millions of times on our systems — ensuring smooth customer transition was paramount.
There were a multitude of challenges that this smooth transitioning required. Maintaining existing data schemas, tweaks to logical flows and on-boarding processes, ensuring hosting infrastructure compatibility and much more. A lot of detailed planning was required to foresee the issues that customers might face and how to mitigate each one. On many occasions work had to be redone because we had overlooked something in the planning. As an additional mitigation strategy we also decided to run both the new and old platforms in parallel during the transition period as a complete fallback in case of any issues and to give customers flexibility in case they were not comfortable with the new interface.
While rebuilding the technology was central aim, the team also had to brainstorm new strategies and marketing plans that would educate our customers on the new platform and help them maximize the benefits and thus increase our ROI. This included creation of brand new guides, new engaging content assets.
What to expect in the future Now that we’ve setup our core foundation, we’re looking forward to building exciting solutions on top of this that leverage our internal and external APIs. Some of the solutions that customers can look forward to in the coming months.
- Adding more features for customers to track and analyze campaign performance
- Continuing to grow our reach for communication and payment channels to more countries.
- A more seamless way for developers to verify identify.
Recent Comments