AWS for Industries
iFood modernizes its financial middleware to event-driven architecture
The iFood finance department originally used a monolithic application, which was slow to develop new functionalities. Switching to an event-oriented architecture not only accelerated development but also added resilience and performance to its financial middleware.
The iFood finance department has a platform called Digital by You (DBY) that helps food lovers (approximately 100,000 iFood employees) to simplify financial processes and facilitate decision-making. The Finance Team had intentions to enhance the platform. This included connecting with new business units and integrating with other financial platforms. Alongside the plans to expand the DBY application, they were also experiencing a growing demand and a consistent requirement to add fresh features.
Since the platform was initially built with a monolithic architecture, its components were tightly interconnected. This resulted in a higher rate of failures and longer mean time to recover (MTTR). Here tight coupling also contributed to more significant performance declines during the development and support stages. This created challenges for support teams to promptly detect and address production bugs in a timely manner.
iFood saw the need to modernize the DBY platform, in a way that would make it easier to expand the platform with the inclusion of new functionalities. They also wanted to increase its resilience, performance, and scalability.
Based on benchmark data obtained after the implementation of the new architecture, there was an increase in the availability of the platform by 30%, a reduction in the MTTR of 90% and a decrease in the delivery time of new functionalities of 50%.
Proposed Solution
To address the prior problems, iFood had the support of an Amazon Web Services (AWS) Professional Services team. By applying a process called working backwards, the team gained insights into the genuine requirements of the finance department—guiding the path ahead. Working backwards is a mechanism employed by AWS, aiming to comprehend the authentic needs of the customer and devise a solution tailored precisely to those needs.
After this assessment, iFood and AWS understood that in order to address platform problems, a paradigm shift would be necessary. They needed to move away from monolithic architecture to an event-oriented microservices architecture, also known as event-driven architecture.
The initial phase involved conducting immersive workshops and event storming sessions. These sessions brought the engineering and product teams together to construct the domain-driven design (DDD) for the platform. The main goal was to ensure alignment among all stakeholders, establishing a unified communication channel using a common language. By delving into the details, the teams unearthed the core aspects of each business domain, allowing for the precise definition of bounded contexts. Within these workshops, critical business processes, entities, and aggregations were identified, and the complete sequence of events was mapped out. This comprehensive approach enhanced communication and collaboration between the teams.
With the insights discovered in the event storming sessions, it was possible to identify three main business domains within the existing monolith. Once these domains were identified, a decision was taken to decompose the monolith into three different microservices:
- Master Data Management
- Provision
- Requisition
Each service has unique responsibilities for its business domain, communicating with each other through an event-oriented architecture.
Apart from the mentioned microservices, there emerged a requirement to introduce an extra architectural layer known as a backend-for-frontend (BFF) pattern. This BFF pattern played the role of bridging the legacy system, gathering data from various microservices and presenting a cohesive view for API consumers. Additionally, it facilitated the conversion of synchronous requests into asynchronous ones.
To enable this new form of communication between the BFF pattern and the microservices, Amazon EventBridge Event Bus was adopted. With its scalability, high availability and resilience it has become the main piece in the communication structure. Connecting the microservices in Amazon EventBridge creates a choreography between the microservices in a straightforward way:
- Sending events from one domain to another
- Abstracting producers from consumers
- Giving autonomy to the domains
To ensure complete autonomy and scalability for each microservice, it was also decided to decompose the database, so each microservice has its own database. This approach, in addition to preventing bottlenecks from occurring when many services access the same database, also ensures that each microservice can scale independently. They can also be managed and evolved by a team in an autonomous way.
The transition from a monolithic architecture to an event-oriented microservices architecture brings numerous advantages:
- Reduced dynamic coupling
- Increased resilience
- Increased performance with the use of asynchronous communication
- Each microservice can scale independently according to its capacity
- In case of failure, the other services are not impacted
- Improved maintainability by allowing each microservice to be evolved and deployed independently
Figure 1 – New DBY event-oriented architecture
Amazon EventBridge Event Bus
Let’s take a moment to explore the benefits of Amazon EventBridge Event Bus and understand why it was chosen to be the DBY platform’s main event bus.
First and foremost, iFood needed an event bus that was capable of filtering and routing events in a performative way. In addition, EventBridge Event Bus is a serverless, regional service with native, scalable high availability that can handle a large number of requests per second with very low latency.
Second, the billing model is pay-as-you-go, that is, iFood pays only for the events sent, which allows them to optimize costs since it is not necessary to pay for inactive resources.
EventBridge Event Bus has the following features that add even more value:
- Rules and Targets: EventBridge allows you to define rules based on standards. These rules can be applied to any event field so that each event is filtered and directed to different destinations individually, decoupling producers from consumers.
- Amazon CloudWatch Integration: Enables all events to be logged in full, enabling active monitoring and efficient routing.
- Amazon EventBridge Pipes: enables you to consume events directly from services such as Amazon Simple Queue Service (Amazon SQS), Amazon DynamoDB, Amazon Kinesis, and Amazon Managed Streaming for Apache Kafka (Amazon MSK). It also allows you to filter and transform events before delivering them to the destination.
- Amazon EventBridge Archive and Replay: transforms EventBridge Event Bus into an event store, storing all the events that pass through the bus, or creating filters to store a specific event pattern. You can also reprocess all the events that were stored, with specific replay rules, allowing you to reprocess events in the event of failures, incidents, or even a specific business need.
A use case example of using EventBridge Event Bus on the new DBY platform is where the frontend queries a bill of materials for the provisions microservice. Following is the execution sequence for transforming a synchronous request into an asynchronous request and then returning the initial request synchronously:
- The frontend does a synchronous request to the BFF pattern
- BFF pattern sends an asynchronous event to EventBridge Event Bus
- The EventBridge Event Bus routes the event to the responsible backend according to the eventType field
- The backend processes the request asynchronously
- BFF pattern polls the backend to get the updated response
- BFF pattern returns the initial synchronous request to the frontend
It is important to remember that the new DBY platform needed to maintain compatibility with other legacy systems, so the BFF pattern was included to exchange synchronous requests to asynchronous and the other way around.
Figure 2 – Sequence diagram of the request flow for the provisioning microservice
Migration and deployment strategy
To ensure uninterrupted service and data integrity, the decision was made to conduct a complete data migration from the monolithic system to the new DBY platform during a period of platform inactivity. When determining the migration approach, several factors were taken into account, including platform usage patterns, the volume of data to be migrated, and the database technology used both before and after the migration.
Regarding the DBY platform, a maintenance window was identified during which the platform remained inactive. This timeframe accommodated the migration of the data within its limits. An equally significant aspect was the matching database technology between the monolith and the new platform, both utilizing PostgreSQL. This alignment eliminated the need for schema conversions. The migration process focused on segregating data from a single database into distinct databases, each aligned with specific microservices.
The canary deployment strategy was chosen. This strategy allows the new version of the platform to be released to a small percentage of users, so it can be monitored and quickly identify any problems that occur. It also enables quick rollback actions if needed.
After a certain period of time without any incidents, the implementation was completed—taking 100% of the new version to the production environment. It is important to emphasize that in order to have a canary deployment strategy, it is necessary to have a well-structured and automated continuous integration and delivery (CI/CD) process. Metrics should be established to measure the success of the deployment, as well as automated actions for completion or rollback.
With the data migration and canary deployment strategies, a secure platform version exchange was guaranteed for moving from the monolith to the event-driven microservices architecture.
Benefits obtained by iFood
The process of modernizing the platform involved breaking down the monolithic structure into microservices through an event-driven design. This transformation yielded notable advantages for iFood’s finance team.
Previously, the team faced challenges in swiftly introducing new features, which affected their time-to-market. However, following the migration, the time required to develop new features decreased significantly, from one month to the conclusion of each sprint cycle spanning two weeks. By organizing microservices based on specific domains, the teams gained increased autonomy and speed. This arrangement allowed them to focus on their respective microservices without the burden of concerning themselves with other aspects of the platform.
The transition to asynchronous requests has allowed various teams to improve the end-user experience. With the elimination of many synchronous calls that increased the dynamic coupling between components, a significant improvement in performance and resiliency was noticed. Failures in a given service no longer impact other services, allowing for an uninterrupted experience for the end customer. Additionally, the adoption of Amazon EventBridge Event Bus allowed the inclusion of new capabilities.
The use of dead letter queues (DLQs) and retry policies ensure that no event is lost if any microservice is down.
It’s worth noting that employing domain-driven design played a significant role in effectively identifying distinct business domains, thereby granting them autonomy. By establishing clear and defined boundaries between these domains, teams can now operate autonomously, concentrating on their specialized areas of expertise.
Conclusion
The process of modernization is a continuous path, and iFood’s teams leverage the capabilities of AWS services along with best practices to continually enhance application workload performance. By embracing innovation and adopting contemporary architectural strategies, they are prepared to effectively address rising demand and align with future business requirements. The modernization of the DBY platform serves as a testament to the significance of being receptive to change and capitalizing on services that streamline and expedite the realization of modern and resilient solutions.
Contact an AWS Representative to know how we can help accelerate your business.