Ecosystem Revolution with Django - Luis Roque

I'm here to talk to you and to give you more or less a uh well I would say a a less uh technical talk. So my uh goal here is really to give you a um a different perspective um on how a strategies that are developed for a company for a startup in this case uh regarding technology and we will touch base on our journey and uh how we use uh Django for that. So um Let me try to get you uh excited on that and let's see how this journey comes across and uh hopefully it gets you ideas uh on uh how to do that by on your own for your company. um as you uh wish.

So basically I will start with one topic that is uh give you a brief overview of our Portuguese technical system. So this conference uh is still in in um in Portugal in a way. So I will give I'll give you just a brief overview, then we'll go and it's it's just also a brief overview on the Django as a go-to framework and how it is established uh today. And most importantly, we will go through our uh case. So hub 's case, how we we are using uh Django, but not only so it's a little bit about our technology, uh about our strategic approaches uh to technology, I would say, and so hopefully

get you um some insights. Looking at the Portuguese ecosystem. Um first of all, uh talking a little bit about the the startup ecosystem. Um From 2000 upwards, there are two uh three main waves of of startups. Uh we have uh startups that are already unicorns like Farfetch. Um uh we have And and I'm talking about the early uh two thousands uh we until until the crisis mostly of two thousand eight Afterwards in 2011-2012 uh we have uh new startups coming in like Unbaba, like Codice. And in 2015, more or less around that uh year

we have uh a third wave where um Companies like Hub, like uh InfraSpeak uh were created. Nowadays we have a new wave coming in, not quite uh sure, and we were still lacking some examples as you know it is first years are uh hard for for startups. Uh another important aspect uh we've been hosting main tech events let's consider web summit a a tech event in a way And we uh we've been having these um tech events showing that Portugal is a hub for technology uh DjangoCon is uh is again another example and we've been having a lot of investment from big tech companies like uh Revolut like Google like different companies that

come across and uh are uh basically looking for talent here in Portugal. Some numbers also give you a better uh idea. So we have 30 companies in the 500 fastest growing companies in the MA region. One of them is us Hub uh we can see the growth in Portugal startups from uh 20 uh 15 upwards and especially we are very well um uh placed in terms of uh global innovation index, but especially concerning uh talent competitiveness. So we are a hub uh for uh talent uh and and it's recognized across uh europe already and so this is something very uh exciting for for us in the in these times where

uh technology is is clearly the enabler for a lot of business models And we have that, we have a very strong uh uh education foundations here. So it's it's uh it's great in terms of talent and the talent that we found uh that we find here in Portugal. Looking at uh Django , and just uh well probably everyone knows about it, but just to change touch base very quickly. Um Django is being used and it's getting uh popular, I would say, and I I like um uh their own description or uh the the the community own description on uh on the framework itself so it it uh it brings uh scalable solutions

but with deadlines in a way so it's really uh for innovative companies that want to give uh and to have pace sometimes compromising in in some ways some um performance standards but we will get to it but especially it's really a very uh innov innovative framework I would say for companies that are looking to uh bring new features to to the customers. uh with consistency. And we can see that well it was created around 2003 and we can see that it's getting um its own attraction in sectors like science and education, computers, electronics. And there are different companies, big companies with uh uh

giant uh data transactions using it like Pinterest Instagram Instagram not only uh Django but also Django so it's a proof that it can be uh scalable until certain uh points. And we get to the point where we uh we'll look at our case. Looking at our case, and first of all, I need you to understand a little bit better what is hub, what we do uh mostly, because uh it is uh required for me to explain afterwards um our path and our journey and why did we take uh the decisions that we that we took in the past and so Explaining a little bit and I'll I will be as brief as I can with

explanations. But mostly hub at Hub what we what what we do is manage the supply chain of uh fashion brands and so we have this platform that gives this the end-to-end visibility and and traction of all the physical flow of goods and also uh consequently uh the data flow of uh their goods and so Uh we are really working from their production sites in China, in India, in Northern Africa until the unbelievery. This end delivery could be uh around the world. We are delivering for more than uh one hundred and thirty countries already. So it's really a global uh supply chain that we are managing, and we are giving and making available the infrastructure for the brands to use.

And this infrastructure is not ours. It's a partner -based infrastructure. So we use uh partners like uh 3PL so third-party logistics that own warehouses like Mersk, like Agility. We use transportation companies like uh EOPS, THL, FedEx, and we also um integrate with other uh solutions like uh online stores, marketplaces, and the goal is really to be able to give the full digital experience to the brand from their production sites from the moment that the production is ready. in their factories or in their suppliers' factories until one of you buys in uh a store or in uh

online um or e-commerce shop. So it's really this end-to-end solution and omni-channel solution too because we are uh managing all the sales channels of the brands Another positive aspect to it is that as we are so um uh as we integrate so much uh vertically all of these processes, we control the data. So we are not ingesting a lot of data from outside sources that we don't control when we need these outside sources is in very controlled processes that we are managing actively. So we get all the data basically from the the the supply chain of a brand. We use a global partner network, so as I was uh referring to, we have a lot of uh

a lot of different partners that we use uh today and another important aspect to it is really we use this uh logistics as a service business model and uh you have to uh I have to give you that context that in logistics um it is everything is very transactional based. And we are bringing this logistics as a service business model, a proxy for the software as a service. And let me give you a proxy for you to understand it better. is uh well logistics is really well i i pick up the product in point a i deliver it in point b uh what we want to bring to the table is really okay but we don't need to think uh that way anymore

we can think in the in a management perspective in a in a more complex and in a holistic perspective of the supply chain. And so give you an example is exactly as hub we use um a platform like uh Amazon Web Services where uh we have um most of our uh servers our machines uh and so we don't we get we don't have that much physical machines anymore, physical servers. We are using this uh this platform to really have this digital access to uh to this infrastructure. And the same way we are building these to the brands. Instead of using uh like data warehouses, we are using in physical warehouses, but the idea is the same.

So they have access to an infrastructure and they have a full uh 100% digital solution for them. to overcome uh the obstacles of uh of the physical flow of goods across the world that is something that is quite complex and so In the end, we get to this proxy where we are the platform for that provides all of this infrastructure to the brand and the brand focus itself. in their product uh development and in their sales and we will be managing all the rest. Well, we have the overview, so uh uh hopefully you get um a clear picture of uh what we do. Um And now let me try to introduce you a little bit

the path and the decision making process. uh a lot of dimensions that are require that um yeah that are related with uh with technology so starting with it and uh i have here uh uh before uh django but mm it's not just before it's really the beginning for us of uh using django internally so before django we we had um uh a monolith solution really it was uh uh for quick prototyping MVP development and as All the startups uh really in the in the beginning, you want to get your product as soon as possible to the market. Um And we use different

solutions there, but mainly we get we get to a point where we have a monolith uh but with a lot of constraints in terms of performance. And so in that sense and then in that moment we we start to uh wondering what uh can we do? Uh should we start breaking it down already and how and what decision, what bounded context should we uh look at? And so before doing that, our decision was to build um one m new monolith in a way. but a more structured one and that was basically extending uh the one that we had already. So we we call we call this Our core API and was built uh with Django.

And um the idea was, and uh and and because at that moment we were thinking about service-oriented architectures, we were not yet in uh in like uh microservices because we didn't have a clear picture of uh this context and the complexity to manage all the flow of information and so we started to to really uh with this monolith again, but instead of being just a monolith, what we did was uh Start with a Django project with several apps internally that were more or less our approach to a service-oriented uh architecture in a way. Because what we did was we break it down to

the order management system that has all the information about the the orders, about the purchase orders to the suppliers. We had the um the delivery management system that had all the information about uh the deliveries to the young customers. We have inventory management systems, all the information about stock levels, about the management of the stock itself. We had an app for uh the what we call the master data there was uh product catalog was customers was uh all the inform more statical information let's let's say it And so in some way we were starting to break uh things up a bit, but still it was the same project, same code base, so it wasn't uh

really uh separated in that in that sense. And another important thing was we were using the same data infrastructure. So basically the persistency was still completely coupled And so we were not getting too much of um I would say of benefit in terms of uh development cycle and speed. But at least we have a more performant uh framework to for our main processes. And that was really the the goal at that moment was really to guarantee that we had a framework that could help us uh getting more performance because the uh the data was uh growing and growing substantially at uh at this moment

Another example that I want to give you at this moment we started to integrate a lot of different partners, and as I stated earlier. The most complex ones were definitely the warehouses. So there's a lot of complexity, a lot of specific processes that we needed to integrate with our partners, and especially The integration layer they are uh quite complex when we are looking at uh this detailed uh view of uh of the data. And so we needed to ensure that a good mapping and a solid integration layer. We needed to handle authentication. We needed to guarantee all the business logic for these operational procedures

and also everything that was related to data validations. And so to do this, uh we created a new uh Django project and we started to build what we call our 3PL third party logistics uh API. It was a new project with uh a new uh data structure. So we were finally separating some context but still this was something uh newer Uh and so it wasn't really a breakdown of what we had so far. Uh it was uh uh a new development on top of it. of we what we had but it was a new project indeed and uh an extension of of of of our business model

with uh an orientation for a specific service And so uh the the main idea and what I want you to get uh as uh as a high-level picture at this moment is is really this before Django or beginning of uh our usage of Django is and I think for everyone it happens uh a bit like this. It's not Um a clear path is really a bumpy road where you are testing out, you are taking decisions, you are making a lot of things happening. but you are not completely confident of the way and uh and that's all right you need to get a lot of insight and a lot of knowledge before taking decisions like

Well, this is my uh architecture that I should choose. This is my the the framework, the go-to framework for me, or uh this is the way that I should shape my architecture. So there's a lot of complexity in that decision making. But the idea was well we get to a point where we could really integrate our partners uh using this uh new service and guaranteeing that we had our core systems they have their own and there was uh this uh this uh layer in the middle that has also uh a lot of uh business logic to to perform the processes and there were Different processes. We had the fulfillment in the warehousing, the shipping process in the warehousing.

We have uh stock transfer from our warehouses to their warehouses, stock visibility and management. But the main idea here is that you get to a point where the complexity starts to increase. And so uh we needed more services, we started to build more services, and so and you start to get a lot of uh limitations from this solution in a way because with the usage of more services you actually start to need uh uh an API gateway and uh with that you get to To some problems like the increased complexity on the routing, data translation, aggregation. So there's a lot of complexity that started to arise at this moment

And we needed to take care of that. So this is the before and the beginning of uh of uh Django for us. And the advantage that I see and putting myself at that moment uh was really the the community the very active community that uh our um developers could uh use for our benefit and uh and uh and contribute in their way too so that's that's that's a great thing for for a framework The support for uh API development in terms of uh uh the usage, and we use a lot uh obviously the Jen of REST framework. The very, very good documentation. So Cheng was born from a newspaper. I don't know if

if that's why, but the documentation is very good, very clear. uh and a good ORM um also that is uh that was uh critical for us especially in the beginning where we had this massive database um to to really uh work on so the the or m uh the or m is very intuitive in that sense and the easy to tweak common features. What we used as a company mostly was the framework, but also the ORM, I was saying with Postgres and the REST framework because we were very focused on API development. And now we get to another point in our journey. So we were uh

mostly working uh with this um with this framework and the challenges that we were having uh uh were based on the complexity of everything that was around and so we needed to to adopt uh I would say a different perspective. And in terms of that different perspective, we um we started to look at uh and understanding What are our bounded contexts? Can we break down more than just this service, high-level service perspective? Can we go deeper than that? And how can we do that? And how can we understand what is a bounding context for us and how can we use it? And so we started to look at this distribution event-driven architecture, and this was the point where we started to

uh really break down the monolith. And this is, I think for all companies uh uh uh hard journey, a very uh uh time consuming uh journey but it's really what gives us the power to to scale and so we started to break it and specially guarantee that these are completely decoupled services that we are bringing to the table. And so uh organize the solutions around these bounded contexts is absolutely Important guaranteeing that we have the data segregation that we, as I told you, we didn't have at this moment just for like new services, but mostly the data was still absolutely coupled. And the main goals were really to improve uh scalability, performance, manageability, because every time we needed to

maintain uh some of these code bases the complexity was extremely high and extensibility so we needed more features new features new uh things to come up and uh and we needed uh capacity to do that. And there was a lot of complexity for us to achieve that. And so for the new services when we decided to start breaking down this uh this monolith uh we finally had uh the the ability and the capacity to work uh Really, this full stack approach is really from the data to the business logic to the application layer. And so we um start with uh and it was our first um

approach like this. It was like a code first approach with Django migrations. We wanted to and we could finally define everything from start. Uh we could and we start to use uh signals too, really to start decoupling our API actions from everything that was related with domain, with the data layer, with the events, with the commands that were being generated and these events and commands uh were being generated by uh our message broker that we started to use back then that was Kafka to guarantee that uh all the different bounded contexts were communicating uh asynchronously between them. And um And so we started to uh be

much more, I would say, pragmatic in terms of the approach, especially we start to have much smaller um scopes to to to to develop things. So we did we start to have smaller scopes in terms of requirements, in terms of what we wanted to to to develop what features we want to bring to the product and the development itself gets uh got much easier and much faster. And again, I think that is one of the advantages of the the the Django framework here is really uh the the reliability with uh speed and for development so uh you can bring innovation to to the product without compromising that much uh real

about reliability and efficiency. And so Obviously, all the the companies need to understand within this triangle how are you positioning yourself yourself? but we want to bring innovation so we need something that we can act upon uh quickly and Django brought that uh to us. We also started at this moment to build our own packages, our own wrappers, uh on top of the the DRF things like HTTP helpers. uh authentication handlings we start to build uh on top of uh Kafka tool for producing consuming uh events a ball a boilerplate for that and we will see that we use that in

more than just the software um development we will get to it uh and event logging a lot of uh different things and so we start to extend a lot of um a lot of features and we Created our own environment, I would say. You see here that the journey now continues with this product-driven perspective, and then we have the data-driven, the AI-driven. And I will try to give you this perspective and somehow somehow uh correlate with uh how we think about architecture, about technology, about the the frameworks that we use. In terms of the product driven, we get to a point

then after all of this change, our product and especially our architecture changed completely. And we got to this point. So we got to the point where we have a bounded context clearly defined like the event remanagement, delivery management, tracking experience, order management, all of these um Clearly define bounded context, and inside of each bounded context, you have a lot of different microservices. And obviously, inside of each bounded context, they can um communicate with the rest outside everything has to pass uh through Kafka so basically with commands or events everything has to go through

our message broker. And that's the definition for at least for us of a well-defined microservice architecture and a distributed uh one on the and that perspective and so you can see that it's much more organized we now know uh much better what are our contexts where is the complexity because these contexts are highly correlated with the business complexity or at least the entities, business entities that are being managed inside of each founded context And so we get to this point where we have a much, much uh clearer picture of what we were building. In terms of our uh tech

stack, as you can see, we are pretty straightforward. So we use Kafka for the messaging, we use as for databases uh Postgres manually uh we also use uh MongoDB for small uh smaller um Uh services we use for the back end Django and Nest, most mostly for our um gateways, and in the front end we use Angle. So pretty straightforward. And I don't think that you need to be very um You you you need to be very agnostic in a way, so to be able to not get too stuck uh inside of uh a framework or a language, but You need also some sort of specialization to guarantee that you are and you have

the capacity and the competencies to develop with highly innovative uh pace and at the same time with reliability and efficiency again. And now to try to correlate this and this software development with other characteristics that we believe are critical for a company. Uh the journey for a company and you know that you see that everywhere. All the companies are now or data driven or AI-driven. And uh At least I will give you mm my view, our view of of what does this mean.

I have uh article on Medium that I I um I go deeper on this, but the idea when you are uh a product driven company, you are basically solving all your problems with new features. So you are focusing on delivering new features to the customer and you need to be uh innovative to do that and also have pace on your development to to really deliver that value to the customer when you are data driven we you are absolutely um obsessed with ingesting all the data that you can to be able to take better decisions But these decisions are not easy to extract from the data. So you have these data lakes or whatever And you have a lot of uh tools on top of it,

especially a lot of people, also data analysts, uh extracting knowledge from this data and helping you take the decisions uh or uh them uh self taking the decisions on how to do uh what to do next how to uh what is the next step and so this data driven and I I want also to give you another interesting perspective of using Django and Python in this case, is that uh we can uh basically work and we have Three main tech company tech teams, that is the software development, the data engineering, and the AI team And all of them work with Python. So there's already some uh interesting matches in terms of the

the and commonplace in terms of all the teams. And I'll get to some of the uh all other interesting aspects to it. But first just to give you this idea of what does this mean, this data platform architecture that um I'm showing you here is we have on the left our source systems and when we are this data-driven company, what we want to ingest all of this information. from uh our legacy systems our monolith or whatever uh and it this is much more query-based in a way. the then we have our new services and we want to plug this architecture that we saw earlier uh here that's why you see that The orchestrator that we have in the middle is basically developed by us.

It is custom-made when we develop it with uh with Titan to guarantee that we can consume the events as another service is consuming. um the events or commands being generated by one service, we can also consume them uh here and uh using the same uh packages that we extended and I show and I talked to to you earlier about. And so there's already conjugancy in terms of what we are using again. The teams are m much more close. Um uh connected, interconnected and working together in that sense because every time a change is made in the software we need to replicate immediately here because uh it is our source of of of the data that we are ingesting

and also about all the products that we use internally uh being slack spot people google analytics whatever All these products, we are also ingesting all of this information. And this information serves the purpose of our analysts that you see on the right, this report layer. but also serves the purpose of our models, our algorithms. And so this is uh I would say the next step. And here your main focus as I was saying this uh earlier is really you want to deliver and to solve problems using as much data as you can to uh be able to rely and and get a much more fundamented answer to that problem.

And the the the the opposite effect is that you get in here we we had a lot of analysts uh extracting knowledge from the data and that is uh I would say the the reverse side of the coin is there is much data to be analyzed. And finally, we get to a point where we uh want to become, and this is a path and a long path that we are also uh doing right now and is becoming this ai driven company and the a AI-driven company uh the logic here is really that you want to solve all your problems or most of your problems uh with a model. A model of the of the world, a model of uh what's called a

small world, uh whatever, is really replicate uh this uh understanding of the world that we you can perceive uh from the data that you've been collecting, understand what is the gener gen generative process behind it and try to take the best decision possible uh about this uh and using that data. Obviously this is not easy is extremely complex and uh and I'll I will try to get you our idea of how can we do this not just at scale, but in a controlled environment. Because it's not just about deploying models and doing things with machine learning, it's about how can you really

encapsulate all of this inside of your architectures, the the things that we've been defining. until this moment and so far, how can we correlate all of this? And so this AI driven, it starts with uh a definition of what are the problems that you are facing. And for us is I I believe this is pretty straightforward. It's not one of those very comp it it is complex afterwards, but to define it is not so complex. So we have four main um let's call problems that we want to to solve here. That is We want to solve, we need to understand what will happen in the future. So this sales forecasting, uh, what will be the sales of our brands in the future?

Because we need that information to take actions earlier in time. And then we have this supply chain optimization model that's nothing more. Then using all the nodes on our network and understand: well, I have a package that will pass, that needs to pass through all of these nodes. Uh, what is the best path? For that package specifically. And so we need to define that. And to define that, we need to estimate its capacity. Node one, what is the capacity for that node? For node two, for node three. And also we need to understand that there are always disruptions in our case. Uh could be because a package is stuck.

in customs in the US uh and it happened several times and can we do something about it and can we uh earlier in time do something about it And so it it's really about all of these uh problems and how to solve all of these problems. And again, we get to the same point where we were. We have uh Different problems, different contexts in a way, and in using um in this type of film where uh Focusing now in terms of optimization or prediction or whatever, these kind of models, there are even more complexity to have to add here because if I solve These problems with, and you see here that we are looking at a

solution that is oriented with microservices too. Also for machine learning. That's something strange, but It is the way for us to do the same that we did earlier. We need some, we have some logic, some logic of the world. Can we break it down to simpler logics? We can The hard part here is that when you start to break them down, uh probably will you will suboptimize the the main problem that you are facing. So If I'm breaking down one problem and trying to solve it in four different steps, if I guarantee that I'm 100% optimal in step one, three, four, uh one, two, three, four.

Probably I'm not being optimal in the problem overall. I'm being suboptimal on those problems. And so one of the things is really to be To have this end-to-end visibility and optimization. We need to understand in the end of each overall process What are our results? It's not just about the specific model, it's about the overall uh problem that we are solving. We need to be agnostic in terms of technology and field of approach because you can see that we use deep learning, machine learning, metheuristics, uh, whatever, because these are Different problems need different uh engines to solve it, and we need it to be scalable. Another thing that is very important

to us regarding uh these models is really We want them to take actions. These are not just decision-making support systems. These are actually models that take actions. And this means, and you can see that that uh that will and the the executing word there is because we want them to explicitly take actions on our product that is spoken on this different services And let's see how can we uh do this. First of all, we will get to a point where these four main topics Will become uh I don't know uh tens of different micro services too, in a way, micro

models, if you want. And so we get to the same place. Okay, we have a lot of different models. How can we guarantee that all of this makes sense? And how can we guarantee that these are in the where they are needed at each uh time step. And so one thing that we did was basically okay we already have the bounded context defined. Can we use this bounded context as the bounded context for each of these micro models that we are defining? Well we can. And so what you see here is that we are basically adding these micro models to each bounded context that we have. So for the inventory management, for the delivery

management. those blue and green squares are actually micro models that are being used and they are uh interconnected with the microservices, the software microservices, and giving and taking actions for themselves. I will show you an example. But the clear picture here is they are very very close to what is a microservice. Obviously there's uh absolutely different logic internally. Another thing that is different, they don't persist data, they just receive data, they compute data, and then they will trigger results, and these results will

impact the state of uh a microservice that will receive that uh that result and that that is the the overall idea and so if we look at an example here For instance, let's imagine a new event that came came in, a new sales error was created. You see those brown uh the square is there uh vertically is this this new sales uh order is uh going downwards And you see that at each time step we probably need some kind of decision that uh could be taken by uh the uh analyst or whatever. But right now it is taken in that specific bounded context

by each of one of these services. So if you see The delivery management is asking the that specific service, the O2FC, for the fulfillment center, the best node in the network for that order. Afterwards, we need to the get to get the estimation on the product levels, um sorry, volumes and weights And what is the best pack set? So what is the best um what are the best uh packs for me to pack that order? Best box is box combinations to pack that order. Why? Because we want the best pack set that optimizes our pricing. So our cost. So we will look

at all of our options with our different transport companies and we want the best one. And as you can see we are again using the the data platform to uh for the models to to get their information and they are not persisting any information but they are answering back to these services with their decision making that they uh got to in the fi after their computation. And so This will basically trigger a state change inside of a microservice and potentially uh it will impact the overall decision. So the if we could use UPS, but in this order it makes more sense to use FedEx

because of this peg set combination. And the idea is really that we have this environment that is built, that it has this end-to-end scope. It is domain-driven in a way, so we are not trying to solve problems here and uh we have the the software here and uh everything is disconnected. We are trying to combine things and We all know what what are we solving at each new uh feature that we bring to the customer or to the product. This is dynamic data and it's agnostic again in terms of technology and in terms of field of approach. And uh to start

uh wrapping up with uh some of the ideas, we get to this uh uh microservice architecture and I am just giving you a brief overview of uh what uh this means in a different perspective but the main idea is Loosely coupled, isolated, a persistency. So now we have all the the data specific that we need at each bounded context in each microservice. A shared source of the truth, it's event driven, so it's really asynchronous and we can uh rely on that to get performance and uh it's domain driven and follows a domain driven design what uh which is for us absolutely critical because of the complexity of

all these entities that we can find in logistics that is very very very very detail driven and so there's a lot of small things that interact with other small things and it's really easy for you to lose yourself In the middle of all of this. Before finishing, I want also to give you an idea of um what what what is the impact of all of this in the in the in the in the final uh customer in the in the final user of the product And I have here um an example. So we have this tracking system and the tracking system is nothing more then the the same approach that for instance

DHL has and so when you buy online and you receive those email stating that uh well your order will arrive soon or has arrived or whatever it is that tracking system of uh of orders and that specific Perspective. But the difference here is that first of all we are using several different carriers, so tens of different carriers. So we need to unify uh all of the all of their approaches uh and standardize all of those approaches. We are using some carriers that don't have this service. And they are probably uh cheaper, they they have different uh uh tech infrastructure, whatever.

And um and so we deploy this service to that uses deep learning to classify uh this tracking status based on everything that was uh communicated and mostly in a standardized way so we have to control what are the different classifications possible different classes uh possible and based on that uh we don't want to solve this problem with just a new feature to the brand, as I was saying. So we want to solve it with our model. And so what our model triggers in the end. is not uh just uh uh an inside of uh well it does it wasn't delivered uh it was it has uh had a disruption of somehow.

But we get uh a notification sent or for the final customer or for the brand or for us. With the detail of what has to be done next to guarantee that this order is delivered And in red, you can see an example for uh end customer like you, if you buy on uh one of our brands. Uh and if the order has some missing information, for instance, the address on your side And we need you to contact the carrier. This is a message that you will receive. On the other hand, you uh if it is on our site, for instance, we were the ones notified saying it is on hold Uh we will take care of this uh for you

and we on our end will receive this. It is on hold. Please uh take this action, send this documentation or whatever. And the idea here is that the model is basically taking the heavy decision making of the process, the heavy tree-based decision making of the process, and in the end. uh it doesn't matter if it's us the customer or the brand everyone is basically being notified of exactly what to do next and and so there's a lot of uh features that we could bring to the product here that we don't need to because uh they are already um sorted out they are already decided at this moment in time and so in the end uh

this is how on our perspective you start to solve problems using um machine learning, deep learning, whatever is really taking the decisions out of uh the way uh and avoiding ha having to build features for someone to take the decisions or for someone to take actions. It's really about notifying when we need really need to be notified and with what we need to do, basically. To close, um in our uh our next steps, we obviously we need to continue our re architecture process as uh I would say every company in the world

we are always reinventing ourselves uh in a way. Again we need to keep breaking this monolith and splitting these uh microservice event-driven architecture continue to do this splitting and we need to invest more in um asynchronous like approaches And here this is and this will be important for more performant services. And you you also need to always be aware of that and understand what are your core services that will need definitely a different approach because of their size, because of the the it and and in on that perspective perspective could be because of the number of actions taken or could be because of the the query consumption of the data for for that

service specifically. and you start using different approaches like CQRS or whatever. And so there's always a need to evolve, but especially you need to define very well what are your core services and what will you do about those core services in the future while you keep the pace of innovation bringing more services, more features, more ideas to the table and to uh your end customer. Thank you.