Microservices Interview Questions: Senior and Mid-Level Answers

And folks, today we are back with Bogdan and we will be going through some software architecture, microservices and interview questions. If you are a software engineer interviewing on the full stack or backend, even some front end interviews will contain at least some questions about microservices. First question, very common, it's what are some advantages and disadvantages of using microservices?

Sure, let me share my screen for this one. So basically microservices are an architecture style where you break a monolith application. So this will be our single monolith that pretty much does everything for us and we break that down into a couple of specialized independent microservice. And so basically our architecture will look something like this, where there's different services, they are independent, they can have different technologies and they deploy independently.

And they obviously can talk to each other and finally react our frontend application with maybe have an entry point here and, you know, get the data rather than having all the requests going to the monolith. And so the big advantage is the fact that number one, you can deploy independently, so they are independent and deployable, so independent deployment, which means you can deploy more frequently.

So you can release software faster if you have pipeline independent pipelines for all of those. Um, you can also kind of have isolated failure. In the sense of if only one of those, um, if only one of those services fail, it's not like the whole system is down, whereas in a monolith, if the monolith is down, if somebody breaks something, you're under risk of having the whole application out of service.

Yeah, so that will be two uh big advantages. And the other thing is you can have parallel development. So because they are independent, you can have different teams working on those and releasing updates and deploying to production independently and that you kind of don't have all that communication overhead. In a mono deployment, in a mono architecture, imagine we have five teams. somebody else has to wait for it. And so it's a lot slower sometimes to get changes to production. And in terms of disadvantages, because I think you asked me some disadvantages. At least in the past, from my experience, what I've seen is that you might have some latency in microservices because back in the monolith, you could just make a request to like you could invoke another function or a class and you'd get some data from an external module. Um whereas in the microservices, you need to make an HTTP call, which introduces a lot of latency. That has number one. Number two, so disadvantage would probably be debugging. So imagine uh debugging one of these calls, you make a request and one of them fails, it's kind of hard to understand exactly was it this service or this other one or this other one and you need some sort of distributed aggregated logging system, like I use data in the past and at least for my experience, I worked in teams where we had one request failing and we had a cascade of seven downstream microservices and I really have to go through each single log to figure out where the error was. So debugging can be very cumbersome and you need to do all this investment in the platform, in the infrastructure and how are we going to package and deploy all those? So you need a lot of upfront investment if you want to build microservices. I would say that's another advantage and if you a disadvantage. So if you do it too early, you might find yourself paying the cost of microservices, but not really ripping any of the rewards. Okay, what about scalability in the case of microservices versus the monolith? I would say an advantage of the microservices is that you can probably scale those individually. So imagine you detect that one of the services gets a bit more load, this one, well then you only have to scale that one and the other ones you don't have to. Because usually in any web application there's a symmetry in the traffic so you always have one page or one endpoint that is used a lot and the others are not, they're kind of auxiliary. So that one you can scale individually, whereas in the monolith, you really had to scale the whole thing at once. So, you would throw a lot more resources, but maybe only a class or a path or a single route of this monolith would need all those resources

services. So you then are not throwing, you then are not overspending near infrastructure. So microservices give you this granular control over how you scale the application, you can really scale a single service independently. And talking about this granular control, I feel like the microservices give you the ability to use a more diverse text stack in terms of I could use the best tool for the job depending on the purpose of the service. While, for example, I remember working with a monolith, everything was Java, so we had to use Java everywhere in the front and in the back end. Which was definitely putting a lot of constraints on our system, it got to a point where the technology wasn't the best fit, but we had to use it anyway. Yeah, that's whenever you you look for microservices, that's one of the first pro, like advantages that comes up. Well, if you get this to the practical, um, kind of environment, you will highly ever work for a company that uses more than four languages. For example, we know Google, it is a huge tech company, they only have four languages. And even if you split your application in microservices, if you guide to maintain uniformity in your tech stack, so have everybody use the same. It's very easy for you to switch developers from one service to another, and have this kind of, uh, it's a lot easier to manage that kind of team where as, imagine you have five services and somebody's using PHP and somebody else uses go and somebody else uses TypeScript. You can't really hire for that team. It's going to be extremely hard to find someone that knows all three of them, and so it's going to be very hard to to staff your teams. So I know a lot of people say, oh, yeah, we can use like different languages and different frameworks, but I think in practice, uh, that was never a good idea. Yeah, you you still want to restrain the number of technologies you use, and it comes to a price, sometimes you could find a better tool for the team. But it comes with the advantage of uniformity and people being able to contribute across services. Yeah, so the the the decision of using different text stack is not always, the constraint is not always technical, there is a team constraint. There is a, can we find this kind of developer? There's a knowledge constraint actually. It's a multi-dimensional decision. Very good point, Bugden. Um, one thing, uh, before we move on, this, uh, microservices thing out there seems very complex. I mean,

in terms of logging and monitoring, the monolith sure it can be very limiting, but it's very easy to do things when you have everything in one place, right? How do we deal with logging and monitoring in a microservices scenario? Um yeah, sure. So the cool thing about the monolith is that if you have an error, you have a stack trace and you can easily follow the function calls that led you to that error and localize the the exception.

Whereas in the microservices, you will need to put a lot more effort in building that tracing yourself, because an error would propagate over different calls. So imagine we're making a call to service A, which will be this one, and then, you know, it will end up calling service B and C, and at some point the call will fail indeed. You'll kind of have to backtrace all this and isolate failure in service D.

And sometimes this can happen across different teams, so maybe you don't really touch this service, right? It's somebody's else team. So you need to uh set up some centralized logging. Uh basically, in the past I use tools like Datadog, which is kind of in the standard at this point. I know they're not cheap, but we're talking about enterprise architecture here. So it's usually worth it. And basically you have all the services pushing the logs to Datadog.

And so, um you set up something called tracing where you'd get a trace, let me see. So this would be kind of a trace. And in the trace, you know that, you know, there was a call to service A, but actually as a subsequent, there was a call to service B. Let me use these in colors. So we had kind of service B and then we had C. and in the middle of that, right? And then we have D. right? And then D returns, right? So D returns and then they get your answer.

So if there's a failure, you localize it very easily. But again, you need someone that knows Devops and make sure that all the services are pushing logs. Um you have different environments, right? You have staging and production for all of these microservices. So you need a lot more upfront work to set um the system up. And that's where microservices are something that makes sense after you have a relatively big system.

Oh big. How would you design a backend service to make sure it is scalable? Okay, so we need to design a backend service. Let me pick this example so I have um service A and let's hypothetically say it's getting more traffic. Probably the easiest way to make sure that this is scalable, it's like the easiest way to scale it is by having kind of horizontal scalability where we have an elastic algorithm that will spawn more instances of the service if that traffic increase.

So, whenever you have more traffic, we we add a new instance. So, how would I design this to make it scalable? Well, probably you want the you're better off if you use something like rest, which is stateless. That means requests they don't really care about like what's the state in the memory of this. They just, you know, they do some processing and then they read from the database and then something comes back.

So, rest helps to make things scalable. You probably have a load balancing component around here, right to to distribute all that traffic. And if you're using sessions, so you're better off not using sessions. You're better off using something like JWT, because JWTs um like if you get a JWT from your identity provider, any of those services can understand it. If you're using sessions and you create a session that stays in the memory of A, but then the same user makes a request and the load balancer redirects that user to let's call this A.3, then you kind of lost your session, right?

And so, it can become very weird. So, if you do use sessions, you want to use something called sticky sessions. Uh which means the the LB, the load balancer, will redirect users to a specific instance based on their session ID. And so you know that if a user has a certain session, they always go to A1, um and that's it kind of helps. But again, you're better off using JVT's and Owat. Um, that would be more scalable.

So, you want to use uh rest, you want to use JVT's, you want to use sticky sessions. And you do want to use a lot of functional programming because functional programming usually avoids state. So that will be the fourth things I would do. So we scale the service, but what about the database? That's a very good point. So, if we scale this, there's going to be a lot of kind of back pressure on our database or data database data store.

What I've done in the past, my past position is that we we used RDS, which is a the relational database from from AWS. And basically they provide you with a lot of functionality out of the box, you don't usually have to build this. What you want to look at, it's do they provide like, so, um, you would need some sort of system. to scale the database too, if not, all your work it's in vain. Um, sharding, it's one way where you split the database in in different, you know, independent databases based on an ID.

It's it's not easy to implement, but it can be a good solution if you have a very big table. Or you might look into no SQL because it scales a lot better, so if you don't need relational databases for certain parts of your applications, you can migrate that to like a document database, something like Mongo, and that would be a lot more scalable. Bogdan, you did mention a load balancer. Can you tell me more about how a load balancer actually works?

Yes, sure. So, a load balancer, it's it's basically a web server that is just handling the requests and then distributing them between different um downstream instances. And it's usually has an algorithm, so I think the most common use the one it's round Robin. where you go like one by one, you say, okay, first request goes to A1, second request goes to A2, um and A3 and then A4 and A5. The load balancer knows how many instances are healthy uh by doing something called service discovery.

So basically whenever we have a healthy instance, it will get registered, you can think of it as a table that the load balancer has. and they'll go one by one and say, okay, you get a request, you get a request, you get a request. So that would be round Robin, but there's different there's different algorithms, you could also use like um basically monitor the memory and CPU of those instances. or use the um the least the least used one or the least connection, so you look at A1 and ask yourself how many connections that A1 has and you'll always kind of push requests to the minimum one.

because again, even if you distribute traffic with the round robin. Maybe part of that traffic takes more CPU than, you know, one request can take more CPU than the other. So you might still have a lot of asymmetry. So there's different ways I do recall list collection, list connections as an algorithm or one based on memory and CPU usage or round robin. And then the load balancer you can build it with NGINX or um you know, there's there's a lot of load balancing software out there. I used AWS a lot for I use their application load balancer. And yeah, it basically distributes the the traffic downstream instances based on the load balancing algorithm you you you need. Awesome, folks. For the people watching us, if you are interviewing right now and you are interested in finding your technical gaps, understanding what you could be doing better for you to pass the technical interview, but also to level up overall as a software engineer, then you might want to check our free technical assessment. It takes you about 10 to 15 minutes to make it and you will get back a full report with the detailed technical gaps and some recommendations and how to fill them for you to level up towards a senior level engineering. Make sure you check out the link in the comments and now we are going to move on with the next question. Bogdan, have you heard about the API Gateway pattern? What is it and when would you use one? So usually you have all these services that are being consumed by some front end or many front end clients and so a lot of the problems come in microservices when you kind of have the front end developers needing different data, so they start kind of making a request here and then they need to make another one, um say they need to make another one service A directly, maybe another one to whatever. I mean, I worked in companies that had 300 services, so imagine as a front end developer, it's it's even hard to like have the documentation of all these services and understand who can you call, um when and what a API gateway does is that it's a bit like the gate to your castle, so rather than having the front end, every time they make a request to a service, dealing with https, dealing with authentication, dealing with caching, you implement all those things

and then whenever somebody wants to make a request to your services, they go first to the API gateway. That will check, you know, is the user authenticated and handle what we call the edge functions, the generic functions, like https, caching, and then it will forward the request, right, to any downstream service. Basically, that's a reverse proxy. And yeah, so basically it will save you up a lot of implementation cost because the service developers, like the team building D, like service D, doesn't need to worry too much about authentication, and the front end only has to worry about once, right? They only authenticate with the API gateway and then they go to slash whatever slash payments.

Uh so it all is the same. It gives you a lot of uniformity at this point and it allows you to save up some costs of not having to implement this functionality in every single service and having the front end, you know, coding also, you know, what headers do they need to send authentication, they only do that once with the API gateway. What would be a disadvantage of using an API gateway? There's some added latency, so we're adding a new component, so that's, you know, latency because we have two HTTP calls now instead of one, you first call the API gateway and then you you forward that request.

The advantage, however, is that this service is like the API gateway sits very close to this this other service. And usually you can do it over HTTP, it doesn't have to be https after the API gateway. So once you are inside your VPC, so once you are kind of inside, inside the service, you don't really need HTTP anymore because the API gateway kind of yes, the API gateway handles that. So you can handle the latency. The only problem would be the single point of failure here.

So if everything goes wrong here, the whole system is kind of down. So you go back to this kind of monolith disadvantage that we have. Uh, can you clarify this HTTP, no need for HTTP or what do you mean by that? Yeah, sure. So to keep things secure, you probably want to implement https in all your services, so you have https here. But one of the disadvantages of HTTPS is latency because um I think it takes around five round trip calls to actually establish the https handshake.

Whereas an HTTP it only takes three. far away your users are, you have more round trips. So of course, as developers, we don't really care, it happens under the hood. What you do have to know, it takes a bit longer. And so what you can do to avoid the latency of the API gateway is that you still use HTTPS between the front and clients and the API gateway. But inside this virtual private cloud, inside this group I have here, where you have your services.

They are kind of in the safe zone because the API gateway already handle HTTPS, so this zone is downstream request can happen over HTTP. And that will make things a bit faster inside here. They're also geographically very close, so that request will be almost instantaneous, even if it's an HTTP. Question. Final question, imagine you are building a service in a microservices architecture, right? From the security point of view, you were already touching upon that.

But from the security point of view, name three things that you would add to that service to make it secure. So back to this example, I would say security, we probably want what I mentioned, so we definitely want HTTPS. That's number one. Probably number two would be something like O, I mentioned uh GVTs, uh JSON web tokens, basically setting up the O framework for authentication. So each service can receive a token and verify the token with the identity provider and after that they proceed with the token.

Um and then you would definitely want to protect against DDoS attacks. So you probably want to implement a rate limiter, so if you have someone basically trying to bring your service out of um bring your service out of service by launching a lot of requests, you can limit them based on IP. So you say I can only accept, you know, blows many requests from a single IP over five minutes. Or you can throttle them.

I've seen a lot of companies doing that where every request that single IP makes. You you intentionally add latency to the request. You handle it a bit slower. Um, so that would protect you against DDoS, HTTPS would protect you against uh the man in the middle attack. An O would protect you against many attacks when you do authentication. Um, yeah, so those are three of them. I think there's uh there's at least two more that we could add.

frontend. You could have cores in the API gateway level. So only specific frontends from a browser client can make a request. And probably some content uh security policy, basically looking at our headers and making sure they can do like big jacking. That kind of things. But yeah, this would be three things, four things that I'll add to any service to make sure it's secure. Awesome, Bogdan. Well, I guess that's enough for this video.

If for the folks watching us, if you want Bogdan and I to make a second edition and answer more microservices interview questions, then let us know in the comments and we will release another version. If you have any specific question you want us to mention in that video, then also let us know in the comments. Bogdan, thank you so much for this. For the folks watching us, I wish you the best of success in your next backend, full stack or front engineering interview.

Without being said, we'll see you folks in the next one. Thank you, Bogdan, once again.