 Hi everyone, Myself Sudhir. I am senior tech lead at endurance. So today we are gonna discuss the art of decomposing a monolith So before jumping into the talk, how many of you guys actually deal with monolith on your day-to-day work? Good interesting. How many actually started transitioning to microservices? Almost 10-20 percent. Good. So this talk is for you guys So who are we? So at endurance we help small and medium businesses to come online be it a domain name Hosting website builder. See we provide you with a lot of tools that help any small business to come online in a very short time And we have like variety of popular brands Primarily you guys would have heard about host get a blue host big rock So and I hope you guys already have a domain already purchased from us Yeah, and we are like largest in the since we have we currently manage around 40 million domain names And we have 55,000 hosting servers across 25 data centers So this is the scale at which we operate globally and today we are specifically looking at our Apex story like I'm gonna take you guys through my journey over the last three years on Decomposing a monolith, which is our one of the core platform in Apex How we transitioned in the last three years from a monolith to a microservice architecture and where are we currently and in this process What are the challenges we have faced? So as you see like this platform is actually a 70 million dollar platform We which is generating like 70 million dollar revenue annually across with 10 million domain names active domains And we have around 1200 APS that are exposed from this monolith So it has 1 million lines of code so you can imagine the complexity So this platform is built over 20 years now And it is very tricky for once for someone new to even make new changes in this code base So there is a complexity we are dealing with and we receive traffic around 20,000 requests per minute on a average scale At the same time we have 500 GB live data So primarily we use Postgres for our transactional data and we have around 1.5 terabytes of historical data that is currently archived and These are the brands that primarily operate on top of this platform So big rock is a retail model wherein any of any of the individual users like you and me can go and purchase a domain name Get the hosting package from big rock at the same time We have a unique B2B model called reseller club wherein we cater to the web professional needs and they buy bulk domain names and hosting service from us And resell to their customers using our customized billing platform and other services we offer to this web pros So what are we gonna cover today? So being a happy monolith family for 20 years Why did we even start thinking of going towards microservices driven architecture? What is the need that has driven us to go to microservice? And we'll see the common mistakes we did and we don't want you guys to repeat if you are doing the same At the same time we'll actually see in detail how we transitioned and successfully pulled out one of the important microservice from this monolith And the challenges and the tools and technologies we have covered during this transition And then we'll also cover the scaling redundancy aspects of the microservice not just filling the microservice But how did we successfully manage it to get more scale? So microservices won't happen overnight, right? So before that we'll see the challenges we had with the current monolithic platform So as you are seeing right so the main limitation we have faced so when I joined the team three years back We are running out of DB connections So we have Postgres master database where it gives like 50,000 queries per second throughput So we actually spent a lot of time in tuning the connection pool We moved to Hikari CP from a legacy connection pooler on the Java side We spent a lot of time in evaluating various data sharding capabilities of Postgres itself But we are not successful We have hit our max capacity on the DB side and we have tuned the parameters such a way We get the best throughput of our production database server which is around 400 DB connections So ideally the DB connections should be like number of CPUs into two There's a max any DB server can perform to its best But we have a 80 core production server and we already like touch the max limit any database server can give the throughput So we hit the scale of the database server and the next important limitation We have came across is the Java heap size. So this platform is Java based So we initially when we joined like it is like we have allotted 4 GB max heap But we started seeing out-of-memory errors when there is spike in traffic as and when we integrate new features The heap used to get out-of-memory we used to get out-of-memory errors very frequently and we like suspected as any developer We started looking at are there any memory leaks, but in vain We are not able to figure out any potential code problem that would have caused the memory leak So it is indirectly It is indicating that as the number of services or the objects are loaded in the memory the need for the JVM heap kept on increasing And eventually like we again the max a JVM heap you can allot is 12 GB beyond 12 GB Any Java process at this point cannot perform well be it Cassandra elastic search beyond 12 GB You can never tune a Java process. So in in those aspects also We have already kind of in the middle way to touch the max limit of a JVM heap size and Other challenge with the monolith is the you cannot scale a particular functionality, right? So during a promo or a festive season our customers try to buy new domains Let's say there's a new TLD called dot tech launched. So we see more Hits for the initial lookups like I want to buy so the dot tech So similarly the customers will be primarily doing this lookup operation to further buy a Hosting package or to get their website hosted on our servers So in order to do this basically we are not able to scale just that particular functionality Because we need to deploy this monolith and then even if you put like more instances of the Java code You still have the limitation at the DB layer So we already hit the max-limited posters. We are in the middle way of hitting the max limit of any good Java process And as you see this monolith has various modules inter couple right intertwined So it does user management product management and whatnot. So you can imagine what all it does with the 1 million lines of code and Again same thing like you cannot even the other common mistake or common issues We see is when a developer intended to touch particular functionality So I want to enhance the building capability for one of my customers I cannot do it without impacting the other modules because end of the day the same code You need to go through the testing for the full monolith and then see if it not breaking any other workflows And we see many outages related to unintentional breakage of code from a developer standpoint so these are the challenges we have with this current monolith platform and Then we started thinking of Microservices, so how does a microservice help to solve this particular problem? So there is something called vertical scaling which we covered similarly horizontal scaling Which is primarily applicable or easy to achieve in no sequel databases, but in post-press world. It is very tricky to scale your Transitional DP into multiple distributed systems There are some solutions like post-press excel Citus data which we have evaluated but again they do not suit our needs because it's again a legacy system You cannot redesign the full system as per the expectations of this data sharding technologies At the same time the microservice will give you the Flexibility to choose your own technology, right? So if it is a proper transactional kind of workload you have you can choose to use post-press or my sequel database Similarly, if it if you are doing simple search functionality or you want to like get like quick lookup functionality You can use any of the no sequel databases like MongoDB Elastic search Cassandra So you as you go towards microservice architecture you get the flexibility of choosing your own tech stack At the same time you can loosely couple your teams So currently we have our own development team of 30 to 40 people working on the monolith code base And all the developers should make sure that they do not break each other's code Like when I'm committing something I should not break my peers code, right? At the same time We also have this same CI CD module like you can only deploy your code along with others changes Even though we are agile, it's always like complex to make sure you don't break someone else code So that once you go to microservice architecture You get the flexibility to choose the tech stack with smaller teams where you get more velocity and polyglot programming So wherein you can choose your own tech stack and you need not just depend on Java tech stack You have the flexibility to have a diverse team who are specialized in particular functionality and scale it to whatever extent you need At the same time, yeah, you can have this like versioning releasing Capabilities tied to that particular microservice, right? You can easily deploy the microservice without worrying about how the monolith is impacted because now you are loosely coupled Yeah, so we'll See the common mistakes which I noticed also like I think in the IT industry people do these mistakes So the first big mistake we do is sharing the database so we think okay, there is a issue at JVM layer We know there is a like we already hit the max limit of database But why don't we just rewrite some of the Java code deploy in a separate like CACD module using dedicated Git repo But underlying you are still sharing the same DB What it means when there is a downtime for the database or you want to do some kind of upgrade to the database You are actually impacting multiple services along with the Internet functionality. You are gonna break something else So this is still a monolith architecture for me with just an additional steps It's not a microservice architecture people missed some developers initial stages. They may assume It's a microservice architecture, but yeah, as long as you're sharing the DB. It's a monolith with additional steps So the other mistake we did in like in order to get this speed like we are growing like Very we are expanding our app app platforms We are building new front-end experience panels for resellers and retail customers So in this in this like in a need to grow we started building this orchestration layers Where in we try to like duplicate some of the functionalities like authentication You can do some kind of transformations like if I had to pull user details of Sudhir I'll query for users to the along with another API called get address details So you will call multiple API calls to the monolith you aggregate this responses and return it back to the front-end So these kind of transformations and some kind of caching ability so that you don't hit the max throughput of the monolith we kept on building this orchestration layers Which ultimately again it may help you temporarily, but in the long run again You have a bottleneck at the monolith layer So it's still falling in the monolith with additional steps category Underlying monolith is not scaling, but you are just building orchestration layers to get the immediate benefit of Speeding up or taking more throughput on the client side Yeah, so now we'll take one particular use case wherein we successfully pulled as a microservice And how we actually got the scale benefits out of the microservice So how like when you go back again, I think about microservices like what you should actually reflect on is Discovering your first microservice. That's the challenge. We also had like how did you choose the microservice? Okay, you are thinking microservices will help in adding more scale to the monolith But how did you choose the first microservice? So in my case, we applied this strategy called ice cream screw So what it means effectively you prioritize your business critical functionality For example during promos as I highlighted there is more traffic for look-ups registrations Compared to let's say addition of new products or integrating with more payment gateways There is more traffic coming on the look-ups and it is very important for our business for the user to look up the domain And then do further purchase of products with us Else he may choose to go to our competitor, right? If we cannot give him the ease of looking up and then purchasing on our platforms, he'll choose the competitor So that's where we identified domain look-up as one of the first potential microservice That we can pick up and we'll see immediate business growth and also like the scale that we required at The same time in your case if you have multiple critical functions say you need even to scale your payment module So you prioritize and figure out the efforts versus benefits So what is the engineering and operational efforts? You need to put in to build the microservice versus what is the monetary Monetary benefit and also other scale benefits you will get with that exercise So try to do thorough analysis so that you can easily justify to your business and also your tech lead that this is what I'm Going to pull as a microservice and it will help in scaling so and so if if required if possible if you put monetary value It will help you even to validate once you go live is it really adding value to the business and Given that I covered ice cream scoop There are other strategies to the other popular strategies Nuclear strategy wherein you rewrite the whole monolith like you build a parallel team Who does the full rewrite of this monolith and then go like a big bang launch? But most of the cases if the monolith is very old and you are like doing like more and more features every month on month It is not a feasible solution right so you cannot rewrite the full monolith by the time you rewrite Let's say you take two years to rewrite the full monolith there may be more changes happening in the monolith So it's like a race between the old monolith and you need to keep up the pace in the new team So you are never gonna go live that but it works for some companies in my initial stage We did that but again it won't be a gel model. You need to go like a big bang Launch also have a time wherein you don't make changes in the monolith in a agile model That won't work nuclear strategy may not work So this is like okay now that we identified the microservice How will you prep up this first we look at from the dev perspective what should the developer do to make this monolith future proof So what we adopted is something called modular monolith. So it's a Java platform So we applied this concept called may when modules wherein you have the flexibility to write More code in the new frameworks. Let's say we don't have historically spring and hibernate in our code base So with may when modules you can actually have multiple projects under the same get repo and properly isolated So you can choose something like we have built one common module to interact with database active MQ and also other third party Registries we built a commons package which can be shared across say modules or future microservices So that you are building this new system with the attitude that you are gonna pull it as a microservice at some time When there's a need at the same time you cannot avoid the old code, right? You have already a lot of functionality built over 15 years You cannot get rid of the code overnight or even within one two years So you may have to still interact with the legacy code to get some of the functionalities working But at the same time you have the advantage to read to write new APIs using the modern frameworks and modern Protocols for example, you want to introduce gRPC right now. I will see the rest based framework So with this approach of may when modules I can easily create a new module Let's say user management using gRPC protocol and whichever framework spring would whichever I want to use at the same time Then how are we in interacting with the legacy classes? So there is a popular design pattern called facade pattern Where in what it says you abstract your old system primarily using interfaces So you build loose coupling between the new modules and the old modules applying facade pattern Where in the new code can talk to the old code, but not the other way So never write the code like again to if you write to a again You are stuck if the old code is invoking the new code again You are stuck in the monolith intertwining and tight coupling So you need to build loosely coupled modules taking in introducing new interfaces wherever you need to interact with the legacy code add new interfaces in the legacy code and Couple them using dependency injection frameworks like spring and you can easily interact from the new modules to the legacy framework So at any moment if I have to pull a microservice out say user management as a microservice I have the new API is written. There may be some APIs still using the legacy code But again, it's lesser work compared to rewriting everything. I already put the platform Where in I can easily pull out the new microservice So using these two we applied these two particular concepts may when modules and facade pattern and we made our system Ready to be pulled as a microservice like we have put the path to get the first microservice out So as I was telling so we choose domain lookup service as our first microservice and we have chosen Cassandra as database for this particular lookup service So out of the 1200 APS actually 10 APS scattered to this particular functionality and the amount of traffic This lookup traffic receives is almost like one third of our production traffic The whole platform if at all 1100 APS are receiving a 12,000 requests per minute The domain lookup functionality itself the 10 APS constitute to 8,000 requests per minute So that's why we it's easy for us even to identify this critical functionality and start putting path to pull it out And we have chosen Cassandra because it's a read heavy API and there is no Transactional functionality that we require. So we just to we have evaluated radius versus Cassandra and this is a critical service So we want very high availability compared to consistency So eventually we have chosen Cassandra as a data store for this microservice And we start and this is called polyglot persistence rate So you you get the flexibility to write with your own technology in this case We have chosen Java because again we have traditionally developed most of the back-end in Java But at the same time you have the flexibility to build with Golang or Python whichever is relevant for this microservice and The data store also you should be very cautious What you are choosing and of the day you need better performance from the microservice compared to monolith If the old APS are performing better than the new APS definitely your users or business won't use the new code So you should make sure you choose the right technology in our case There is no transactional nature of data required So we had the luxury to choose between the popular no SQL databases and we went ahead with Cassandra At the same time there is one more interesting pattern. So this pattern is also popular architectural pattern It's called command query responsibility segregation So in the initial transition or whenever you are pulling more and more microservices if the microservice For example, this monolith also has differences to some of the tables. We have migrated from post-quest to Cassandra So you need a bridge like as and when you cut more microservices Migrate your tables or data to another data store You should also think of how does the old functionality not impacted the monolith should not break when I just pull the domain Look up out so in order to make sure so you can periodically sync the updates that are happening in the microservice Actually, it's a real-time stream either using Kafka or active MQ We can stream the real-time updates happening in your microservices to the monolith so that the functionality doesn't break in your existing system So this particular pattern helped us and it's very popular like so that when you have more microservices You need not worry about the impact on monolith You keep streaming the data so that your monolith still continue to function if there are users still on the monolith platform For the existing API they still continue to function So this is one part and then the main part is okay Now that you have a production system running happily for several years How do you actually migrate the user or the traffic to the microservice? So in our case we have introduced a new endpoint for the microservice to redirect any lookup traffic We started publicizing to our users with advanced notice Okay, this is a new endpoint which will give you better performance and also scale compared to the monolith You start advertising your new endpoint for the microservice at the same time You need to be sure that there will be users always on the old system Right coming through the load balancer that you already have on top of the monolith So make sure you like strategically migrate the traffic to the new microservice So we have adopted something like a canary deployment slash AB testing what it means so whatever traffic is coming for domain lookup on the old endpoint Make sure you do like weighted or incremental traffic migration We use it the concept in HAProxy to add weighted load balancing kind of concept Where in we send like partial traffic any traffic coming to domain lookup on the old platform You migrate 10% of traffic to the new microservice So that you can have the production testing at the same time if something goes wrong You can always roll back as an engineer. We should be ready for production issues, right? So don't just think of happy part that microservice will solve everything and it will be running without issues, right? There will be more issues that you discover only in production because in dev testing nothing comes out So yeah, so make sure you migrate the traffic incrementally at the same time These are the aspects that we've primarily focused So once we made this microservice live around December 2016 We actually made sure that it is the microservice is highly available It is giving correct response in production with various types of payload we compared okay This old micro old monolith is giving this response for this particular lookup for dot-tech It is giving this response for Sudeer the same response is coming for in the new microservice Similar response is coming when someone hits the new microservice at the same time performance like monitor Like okay is the performance as expected from your microservice. Is it performing poorly? Did you write bad code or did you improve the code quality in this migration slash refactoring and This particular screenshot I have taken from current production. This is we use ELK for the log analysis So as you can see this this is primarily like structured as per the RED principle The first graph is the rate of traffic So the traffic coming to the old endpoint at that moment of line is 700 There are 700 requests per minute coming on the old endpoint versus 900 requests coming on the new endpoint So this is primarily indicating okay There are still users coming through the old endpoint, but right now we migrated all the Traffic to the new code base. So this is indicating people are still yet to use our new endpoint that was publicized At the same time the error count So this is a non 200 response codes that both the old endpoint and the new endpoint is returning So this is to make sure that you didn't increase the error count or frustration of your users, right? You should always at least make sure it is in line You don't get a shock that there are more errors and users get frustrated So just keep an eye on the rate of errors like this is like 20 Like failures per minute kind of right in both the new and old endpoint It's similar roughly similar set of failures at the same time the response time as I was telling you When the people are hitting directly the new endpoint the response times are better compared to when they come from the monolith Why because you have a extra hop of HA proxy when we did the migration in our case But there may be other approaches that will suit you to do the migration as a AB testing model So that's where you see there is a approximately 200 to 300 milliseconds latency added by the network hop So once uses all users migrate to new endpoint they get the benefit of faster response times and no latency So this is how everyone like should monitor it We should not Just deploy the code and think everything will work magically just make sure we proactively have this Toolset to even we run periodical health checks in order to ensure the correctness is good Even with more and more versions of the microservice we periodically run automation test api test To for as a schedule health check And this is the benefit we got by pulling the lookup service, right? So as you can see the monolith platform at this moment when I took the screenshot it is receiving roughly 8000 requests per minute This is a screenshot from New Relic. We use New Relic for primarily the application monitoring and Kibana and ELK stack to check the logs and see how it is done at the load balance level and You see the domain lookup is receiving roughly 4k requests per minute the new microservice So effectively there is a one-third gain in the monolith now the monolith can take Can give you more throughput effectively because we successfully isolated the database Isolated the Java layer including the load balancer. So now you we have the breathing space in the monolith that it can take Extra load that it is serving earlier. We can use the bandwidth for new functionality So this is our journey in migrating the first microservice But we didn't stop there Then we started thinking okay now that we are excited with this benefit We wanted to see what is the next potential microservice that will help us to scale more Then we started looking at the orchestration layers. I was highlighting, right? So the redundancy or the duplication happening across engineering teams primarily is around the odd service at the same time With the growing needs of security There is a demand from our resellers and customers to have multi-factor authentication Enabling Google Earth as two-factor authentication at the same time We it's a need of the art that everyone do social login like no one likes to go and register, right? No manual registrations We want to do social login to easily sign up on any particular application. So to get these benefits We started evaluating variety of open source authentication services. We evaluated key clock odd zero octa Finally, we have chosen key clock as our solution because it suited our needs We have a detailed a matrix where we compare the features that available across the open source authentication service and And this particular key clock service works on the basis of what protocol which means user can Generate a jwt and then use that particular token to invoke any of our micro services directly from the front end So he's traditionally we do basic off which means every time you make a API call You need to pass pass your secret or API key But in this new approach, we are giving the benefit to the customers wherein you use our secret to initially generate a token Once the token is generated you can use the token directly from the browser if you are like using our APIs and Selling something on your like client client applications You can easily integrate from the client browser Set the token in a cookie or the relevant place in the browser so that the token gets passed on With every API call through authorization header it reaches to the monolith or the micro service Depending on which API you are like querying and you can get the benefit of reusing the same authentication service across different Microservices so this will be like a centralized authentication service But yeah, we need to make sure again it's very highly available and it won't impact your systems if there is an issue and Also going forward as and when you build more and more micro services You will this the need for inter micro service communication will also increase CQRS pattern as I explained will solve some particular Backward compatibility with the monolith, but what about let's say if there is a genuine need for Registration domain registration module to talk to payment module So you need some kind of security between the micro services So that also can be achieved seamlessly by JwT token the JSON web token So in in to be more secure we can use something like JwE JSON web encrypted token so this particular concept will help even when you grow with more and more micro services You can take advantage of your centralized raw service So given that we saw the first successful micro service and the next potential micro service which we are working on We also want to cover quickly our learnings with respect to scaling the micro service itself So traditionally we are a we use bare metal deployments So we do rolling upgrades wherein you deploy the you take the node out of load balancer deploy the code Put it back to the load balancer and we repeat that process on all our production web nodes So it is time-taking it takes roughly 20 minutes to deploy any code change to our production across five web nodes So and also the main Like pain point for us with the bare metal deployments is a time spent in upgrading tech stack So we are a Java tech tech tech tech tech tech right primarily We want to upgrade from Tomcat 7 to Tomrat 9 because of the sent OS limitations Which OS 6 version we are not able to move easily from Tomcat 7 to Tomcat 9 Similarly, there will be our tech stacks Which are tightly coupled to the operating system or other? Dependences that are installed on the machine itself So it makes both the dauson sysad life difficult in terms of upgrading any tech stack because you need to repeat the same activity across all your production systems, which is time consuming. Also we over provision the hardware. So as you can see, right, we have a 24 GB and around 24 CPUs on our production hardware, and we are only able to take advantage of 6 GB RAM out of the 24 GB RAM available. We are not able to utilize the full capacity. And the other reason being we are PCI compliant, so you cannot deploy more than one service on a bare metal. So that also restricts us in terms of utilizing the hardware. At the same time, CPU is definitely underutilized. It's primarily like even we have high number of cores, so we are not able to utilize all the capacity that is available on the hardware. So the solution our system architects came up with is the de facto standard is Kubernetes, and also like we started containerizing our applications. So with containerization, the benefits primarily are you can like the developer can have the Docker file ready with all the tech stack requirements he needs, and the sysad can primarily focus on primarily managing the orchestration layer and how to scale your application. So it will help you in doing faster tech stack upgrades. And other pain point I'm sure you guys also facing will be the similarity between staging and product. If you are using bare metal deployments, typically like most of the complaints I heard is, okay, my staging is not similar to prod. So whatever I tested, it's working in staging, but nothing works in prod. And we had to roll back the code. So that happens because you don't have similar tech stack. For example, you have different Tomcat versions on staging and production, or you might have compromised on the upgrading OS in your staging. So all the typical issues between to make the staging and production similar is like very challenging for any IT company, right? So this particular thing can be solved if you contain reservoir app. At the same time, we are actually using OpenShift, okay, the version of OpenShift, which helped us to segregate both staging and production hardware. Like we have a cluster of nodes wherein you can segregate easily using the namespaces and labeling them as staging and production infra, so that you can utilize this same infra for both staging and production with proper segregation. So and also Kubernetes helps in the optimized infra utilization. So it can be like, there may be, historically there is MeSource, but now I think Kubernetes is a de facto standard, no debate there. And we have deep dive sessions, if you guys already attended some of the sessions. And it helps you to autoscale. And also, primarily, it helped us to get this out of the box, canary deployment, AB testing kind of CICD capabilities without much thought process or writing customizations. So all these features are out of the box and there are many more service mesh and other interesting features in Kubernetes itself, which will help you to transition to microservices. So given that we saw what we did so far, this is what we are going to achieve in next two months. So this particular architecture, we are calling it as 2.0. So wherein we are introducing an API gateway called Kong. So primarily we evaluated AWS API gateway, Kong, Tike. So there are various API gateways available open source and also paid versions on cloud. And for our needs, we evaluated both the cost aspect and extensibles perspective. We have chosen Kong. We have written our own custom plugins to do rate limiting to interact with the centralized raw service. So the flow, it will look like the client will enter our ecosystem using a JWT, which is secure in itself. And then any request coming through the gateway will be rate limited using the Redis as a data store. We currently rate limit by IP. So if you hit more than 500 requests by IP per minute, we primarily rate limit at this layer itself. So the request won't be forwarded to the microservice. And every request after getting rate limited, after passing the rate limiting check, we forward it to the centralized raw service, in this case key clock, wherein we verify is it the token generated by our own key clock or not. So we do some kind of signing. We call it Java JSON web token signed token. So wherein you can verify is the token is the source of truth is key clock or not. Once it is verified, then we also currently building a caching layer wherein if the particular API with the relevant payload is already available in our caching layer at Kong level, we return the response directly from the caching layer. So it need not even come to your microservice. So yeah. So then once if it is not available in the caching, it will forward to the relevant microservice or the monolith platform itself. So this particular architecture we successfully deployed in staging. Right now we are going to make it live in next two months. So the key takeaways I want you guys to remember from this talk is just reflect on your current platform. See if there is a really a need for microservice. If at all you are operating at a small scale or you have only one particular functionality to scale, don't think of microservices as it only adds complexity. Just see if it makes sense for you. If at all it makes sense, then what is a microservice? Do thorough analysis with efforts versus benefits? What are the challenges or monetary benefits you will get with the microservice you are thinking of? And container is your application. Don't just go with the traditional way. Try to container is your application even if it is monolith. So that you can have identical staging prod environments at the same time, take advantage with faster tech stack upgrades and use Kubernetes or any other flavor of Kubernetes to manage the orchestration layer to get the benefit of infrastructure utilization and autoscale capabilities. And if feasible, if it makes sense to you, if you have a lot of redundancy, start using API gateway. It also helps you to abstract whenever if I have to pull a new microservice out of the monolith, I can abstract my user because earlier when we transition, we had to create a new endpoint. But if you are using an API gateway, you can easily route the traffic abstracting the user and then forward it to the relevant microservice. Thank you all.