Communications platform (r)evolution
By Manuel Correia, Junior Software Engineer — .NET
This post was originally published on our F-Tech Blog. Come check it out here :-)
Every day Farfetch connects millions of customers in 190 countries with more than a thousand of the world’s best brands, boutiques, and department stores. The services ecosystem has grown extremely fast, having services that trigger communications on demand spread across many different platform domains. In such a dynamic and global scenario, communication is an indispensable key to unlock all the doors that appear when we try to deliver the right message at the right time and in the right channel, such as the customer’s location, language, currency, communication channel, and legal restrictions of different countries, just to say a few.
For example, in the scenario of sending marketing information to our customers, such as notifying that we have an item he or she was looking for, most of our customers in China prefer to be informed through WeChat, while some of our customers in other countries prefer SMS or e-mail as their channel of choice.
This led us to believe we needed to develop a platform capable of handling all the communications, and this article is the story of the birth and evolution of this platform and its role in responding to increasingly complex use cases from our stakeholders. I will discuss what motivated us to create this platform, where we were when we created it, where we are today, and where we want to be, and — all in a 5 minute read.
What motivated us?
When it comes to communication channels such as e-mail or WeChat, it was standard to just let each independent domain or application decide when and how to communicate with our customers. This is a fine approach when your ecosystem is reasonably sized and there’s not a lot of specific workflows, but that started not to be our case.
When your system spans across a huge number of services, it becomes extremely hard to manage company-wide communications: client applications would just stop updating; templates would go out of date; and so on. Adaptations exceeded the need for transactional e-mails in customer language and even included different ways and different channels of communication.
We make it our priority to provide a seamless shopping experience to our customers, and we need to consider different cultures and tools to create a seamless journey, so our goal became to be able to quickly allow new communication channels to be available for all applications at Farfetch, like WeChat, SMS or e-mail, and allow the business logic to choose the best regional provider for each channel (for instance, send an SMS based on country dial code) — and this seemed like a cool challenge to us.
Where we were
Since each service decided what and how to communicate with the customer and there was no centralised communication flow, it was very difficult to maintain a consistent customer communication experience. That was because each service that sent communications needed to follow the same rules (e.g. decide which language to use) and whenever the rules change it was necessary to update all the services that send communications.
This approach turned out to be unsustainable and evolved by adding new features, like changing the language rule to send communications in the customer preferred language, or plug new communication channels such as WeChat and SMS.
Where we want to be
Before I show you where we are now, let me share our ambition with you. Our main goal is to unify all our communications in a way that enables us to scale sustainably and build a platform that can be configurable at all levels. To achieve this goal, we planned to split all the communication process into smaller components, following a microservices architecture.
We want to dynamically configure communication flows in components that are able to (according to our customer’s preference):
- decide the message type
- decide the communication channel
- decide the communication provider
- decide and apply channel related message templates
- integrate different transactional flows
Such components are going to communicate with each other using a canonical message stream, and each one of them is going to perform a different role in the communication flow by handling the message target to it and producing messages indicating the next component.
Each component is going to be categorised as:
- Triggers — starts a communication flow.
- Filters — processes a canonical communication message and delivers to the next service.
- Gateways — handles communications for a specific channel.
They are going to be configurable in order to change behaviour dynamically, like decide what event is going to read and what is the next component in the flow. In the end, all these configurations are going to be exposed via an API in order to be possible to other clients, which are not event-driven, to trigger an event via API calls.
Here is an example of a possible flow and the components involved:
Where we are today
To migrate to the new communications platform, we are currently collecting and processing transactional e-mails associated with the process of purchase and follow-up of the customer with the predefined flow, time and execution conditions.
This migration process required the identification and classification of all communications involved in the customer shopping experience to ensure that events which could trigger those communications already existed or started being developed. All these events had to have all the necessary information to, in an autonomous way, enrich and generate the communications while keeping the original message content.
This process of internal reengineering had the immediate outcome of facilitating the implementation of new communication channels, and we now have WeChat and SMS. Integrating these new communication channels has had a direct and relevant impact in the expansion of Farfetch’s presence in the Asian market, being essential to improve the shopping experience in this customer segment and, consequently, increasing the associated volume of purchases.
At the moment, we have already successfully migrated several transactional e-mails flows. Newer communication flows are being implemented exclusively in the Communications Platform. In parallel, we continued to work on the componentisation of the platform and working in the platform API.
But our work in far from finished. We have a world of communication channels to explore — and how cool is that?
This article was written with the help of Álvaro Jesus, Ana Barbosa, Carlos Moreira, Hugo Coelho, José Correia, Marcelo Melo, and Nelson Silva — thank you!
