Back in 2012, Unifonic had a customer engagement system called “Resalty”, a simple web interface application that started life as a small project to help school teachers but was developed and adapted to send notifications and promotions to a much wider audience of consumers.

Although the system was simple in terms of infrastructure and design, it was very effective in allowing commercial customers to send bulk SMS messages successfully and reliably.

Resalty was developed mainly in PHP with some java code and was deployed on the Cloud. It could deliver a “traffic size” of almost 200k to 500k messages daily and operated successfully with that capacity almost for 2 years, targeting business customers whose requirements fit within those capabilities.

From Resalty to Unifonic

In 2015, the company decided to expand its business scope to target clients with a larger customer base and a more global footprint. That required a significant upgrading of the Resalty system. The new system was renamed “Unifonic” 

At this point, the team began to utilize additional Cloud services and switched to PHP only, retiring java from the system completely. The challenge was:  How can we make the system faster and reliable enough to handle much more traffic?

The engineering team was expanding rapidly and started to develop the system design to achieve the perfect solution for these expanded functional requirements. The front end was separated from the back end and  MVC pattern was applied. The codebase was also split into two different parts, enabling them to scale up the backend nodes in a flexible way under a load balancer.

They called the frontend codebase Web SMS, and backend codebase Digital. They also replaced the middleware with a new licensed project called Kannel. This separation was the solution required to scale as required.

New Capacity

As a result of our enhancement in system design and infrastructure, the system was capable of sending up to 3 million SMS messages a day, and of course, the company was ready to serve more customers. The team also introduced a new mechanism of delivering SMS via direct API calls - a move that allowed some customers to integrate directly with Unifonic directly from their own systems.

For several years, this setup was a very powerful tool and clients were very satisfied, but in 2017 the team recognized that more enhancements were required to keep the product at the top of its game and to keep pace with the market.

Increased demand from the banking and finance sector for secure, reliable, and quick sending of OTPs (one-time passwords) was the catalyst for the next generation of our product

 The team had some specific challenges to overcome:

• How can we differentiate OTP requests from campaign requests?
• How can we scale our system to include new services in the future? (Whatsapp, voice, instant messaging etc)
• How can we apply change quickly and easily with the current codebase?
• How can we automate daily tasks such as deployment and testing?

Welcome to Unifonic NextGen

For all these reasons, in 2018, it was decided for Unifonic to upgrade the architecture again, and move to the latest technology stack. Thus resolving the challenges we had, and taking advantage of extra capacity, power, and scalability. 

With this move, the company could have different products, different teams, and different technologies, all under one umbrella of Unifonic Console. This was an ambitious goal requiring new teams and policies.

Automation was also a consideration. How could we automate routine work as well as generate reports and testing processes - all in an automated and reliable way? It involved a big evolution in the company’s architecture plan.

The first question we asked ourselves was How can we differentiate OTP requests from campaign requests? This was a fundamental requirement for us in order to gain our clients’ trust. We needed a solution that would allow separation between two forms of communication: promotions and notifications.

To address this requirement we introduced a new component RabbitMQ (RMQ) and moved the deployment artifacts to be made with Kubernetes. OTPs could be then be identified and separated with help from Kubernetes deployment and tune RMQ queues via configurations attached to each node separately.

To-Be-Architect Architecture

The Unifonic goal from a technical perspective was to build cloud-agnostic systems, and to this end, the company recently decided to build Microservices’ Cloud-Agnostic Systems. Although Unifonic had built similar systems previously from a design point of view, this was seen as a more complete solution.

From Monolith to Microservices

Building microservices architecture in the right way is a challenge. For Unifonic, the top priority in building synch architecture was to be uniformly balanced to cover all business use cases within the same architecture roadmap.

Since 2006 Unifonic operated with a monolithic architecture, and growing and scaling required some adaptation. The big technical challenge at this point was to build an architecture that could be scalable, dynamic, and highly available To-Be-Arch.

Company Targets

The upgrade/migration process had specific targets the company wanted to achieve.

• Building secure systems that satisfy the company’s clients.
• Having full visibility with good observability stack.
• Providing Infrastructure as code to improve productivity.
• Providing highly available systems.

1. Security

2. Security is the highest priority at Unifonic, and the company always aims to build client trust; which is why they applied rigorous processes and methods to guard the system against attackers by using:

• Auth with JWT and OAuth.
• IP Whitelisting.
• IP Range Restrictions.
• Content Moderators.
• Admin Blocking Control. 

1. Observability

2. One of the challenges the company managed to solve was observability; the problem can be summarized in the following question: What is the status of the following request, and why is it not approved or sent?

3. It is known that tracing request life cycle is a core building block of microservices architecture, but being smart while applying such a solution to conform to your business requirements has been a huge bonus.

4. Unifonic built a powerful ELK stack and decided to add what is called a Data Tagging procedure; this allows the company to have much better visibility of every request sent.

5. Data Tagging is a business concept that allows the admin to understand the life cycle of the request with tags key/value pair. Because the systems are distributed, the engineering team could use the Zipkin tool to make it more straightforward to trace and troubleshoot.  

1.  

2. Infrastructure as Code.

3. Maintaining enterprise systems over Microservices architecture can be a huge challenge if a large volume of manual interactions is required. Tasks like adding services, code building, testing, and deploying require special attention. This is why Unifonic built its own CI/CD pipelines and formalized the process for each new project. The idea was to automate as much as possible and limit the number of manual interventions required.

4.  

1. A new company target.

2. As we will see in part 2 of this article, our architecture places a strong focus on high availability. Unifonic wanted to provide systems that can handle the huge load in a stable environment. At the same time, the systems needed to be quick enough to provide responses to OTP messages.

3.  

Following up with One Diagram

The architects' team wanted everything in one diagram enabling teams to follow the architecture.

In the next blog, we will illustrate each component of the To-Be-Arch diagram. What is the problem solved by each component? and, what benefits did the company gain from that component?