Top 25 Microservice Interview Questions Answered - Java Brains

okay if you're attending a job interview as a back-end developer there is almost a guarantee that you will be asked questions about microservices all right so you have to prepare for microservice interview questions so in this video i'm going to look up some top microservice interview questions and try and answer them the risk of embarrassing myself um this is not live so if if it turns out bad then i'm not gonna upload the video so if you're seeing this chances are that i didn't embarrass myself that much okay so let's tackle micro service interview questions and let's see how i do would i give myself a job let's see microservice interview questions all right i'm going to pick the the very first link all right top 25 microservice interview questions and answers uh let me actually do this i'm going to open uh devtools so that i have some way of covering the screen i don't want to see the answers um i move this up here all right now i can gradually reveal this as i go so i'm going to tackle the top 25 micro service interview questions i'm going to provide my answers and um let's see how i do okay explain microservice architecture uh a micro service architecture is a way in which you architect your micro services there are different ways in which you can architect it i'm guessing this question has what what micro services are which is which is a fair question to ask is a good first question to ask well micro services itself is a way in which you build your application uh by breaking them down into smaller pieces and deploying them separately as separate processes possibly on separate machines and have them talk to each other so that they farm together work together to form your application this is supposed to the monolithic way of building applications where everything was deployed and built as one piece okay with micro services you basically separate your application out into smaller pieces which are kind of independent they're self-sufficient in a way although they need to talk to each other in order to do something valuable the key thing to remember here is that these are separate processes when deployed and when they are running as opposed to the code base itself it's not tied to the code base you can have multiple separate code bases and still build a monolith okay and you can have a big code base and still deploy several micro services from that single code base there is this thing called the mono repo which basically means all your applications go into one repos it's not associated with code base okay it's associated with the form that it takes when you're deploying it okay so that's micro services essentially the key factors here are smaller pieces smaller units of deployment and runtime they run on separate processes and they're fairly independent you basically chunk them down based on kind of like the business value you have smaller teams working on smaller problems they tackle those smaller problems and build micro services which which solves those smaller problems but they don't form an application itself they work with other microservices to farm your application and then the communication happens via apis a common choice is rest apis and the common payload is json so that's kind of like an overview of all the different important characteristics of micro services uh let's see what do these guys say microservice architecture is an architectural development style which builds an application as a collection of small autonomous services developed for a business domain fair enough fair enough i'd be happy if somebody gave me this answer in an interview that's fine all right moving on come on come on come on come on name three commonly used tools for microservices tools for micro services not not exactly sure what they mean by tools um do they mean like libraries for doing certain stuff with microsoft so for example service discovery uh uses eureka okay so you use eureka as a library for doing service discovery is that a tool for microservices i don't know um you have zipkin you have histrix all these are libraries i'd probably go there uh i honestly don't know what these guys are talking about wiremock docker and histrix are important microservices tool okay so um historics is what i was talking about it's it's a library which allows you to do uh it it belongs to the class of things where you're you're addressing cross-cutting concerns right uh docker yes i give you that it is it is used in commonly in the microservice context wiremock seriously i don't know if you think about tools probably the most commonly used tool when you're working with micro services is a rest api client something like postman right no matter what you use you're guaranteed to use postman or a similar tool when you're building micro services so that would be a good answer for like what is it what is the tool you use this is an odd question all right moving on what is monolithic architecture uh this is the um the opposite of what i was talking about with microservices right with monolithic architecture what you have is your application deployed as a single unit okay it goes as one thing that gets deployed and then it runs as one thing so you don't have all these smaller services which talk to each other it's just one application right it's just one thing which which executes and does its thing all right so that's monolithic architecture it's uh they say it's a big container of all the software components in an application clubbed inside a single package and again the key here is it's not about the code base okay it's about what gets deployed what gets built and what gets applied if it's built and deployed as a single package then it's a monolith what are the advantages of micro services right this is a common interview question it's not just to see if you're kind of listed all those things i would imagine somebody asking you this would test your knowledge like do they really understand what what is an advantage and what is a disadvantage so let's see what are some advantages of micro services um they have a smaller surface area per change and i think it's critical uh because uh think of a monolith right you're building a monolith you make a small code change uh the affected surface area of that change can be pretty big right you want to push the change of production for example what do you do you have to deploy the whole application you have to test this change what do you do you have to test the whole application right so any change has a big surface area in case of a monolith but in the case of micro services you have all these small small units and then you make a change you're making a change to this one micro service so you're going to test that one micro service you're going to deploy that one micro service as long as the external contract of that micro service isn't changing you're good to go you don't have to change the whole application you don't have to test or deploy the whole application all right so that's a good thing about microsoft that's one advantage smaller surface area for change for impact um the other thing that it's usually faster to do this because it's a smaller surface area it's faster than we deploy changes it's faster to test changes faster to make changes and code them you have you have different technologies for these things because these are individual units which communicate via rest which is language agnostic you can build one micro service in in python you can build one micro service in java another microservice in javascript it's all perfectly fine so you can use the right technology for building the right thing so usually you pick these individual micro services based on domain business domain so you have teams working on solving a certain problem in a business domain and building microservices for that and those teams kind of choose what technology you need and all that stuff it's normally not that free like have a team choose anything but you can have teams choose different technologies because of microservices which is an advantage all right so let's see what are some advantages technology diversity yeah this is what i was talking about right you have different you can build microservices and different technologies which is cool fault isolation a process failure should not bring the whole system down i don't know if it's a benefit advantage of micro services you can build micro services which are not fault tolerant so a single micro service can basically bring the whole system down and you can build monoliths which are fault tolerant so i don't i don't believe this i don't think it's an advantage of microservice itself but you can do that with both but i guess with microservices there are patterns which allow you to build fault tolerant micro services maybe that's what they're talking about yeah i don't necessarily agree with this uh greater support for smaller and parallel team um i guess this is referring to smaller teams you know iterating rapidly on smaller micro services which makes sense independent deployment we covered this independent testing independent uh deployment and independent monitoring and all that deployment time reduce i guess it is reduced if your you're deploying individual microservices as opposed to the whole microservice um here's the thing though if you're deploying everything from the scratch right deploying a microservice as a micro set of microservices from scratch deploying a monolith from scratch it's probably faster to deploy a monolith than to deploy like a gazillion micro services but typically that's not what you're doing you're deploying a small change so that's that's why microservices wins in this in this context all right moving on next question what is spring cloud okay spring cloud it's like it's a it's a bunch of um libraries and solutions which allow you to tackle some of these cross-cutting concerns so there are there are all these patterns that have been developed with micro services right you have service discovery which is a pattern fault tolerance which is a pattern uh configuration of micro services there are certain patterns for it so what this what spring cloud does is it provides all these different uh libraries under this umbrella called the spring cloud which allow you to kind of like implement those patterns on your microsoft system right you can build uh service discovery using the eureka framework you can pull in your account into your system and then like yeah you can now you have service discovery following standardized patterns right so spring cloud is kind of like a set of those um those libraries those technologies which allow you to uh both build as well as manage your micro services on the cloud and this comes with uh it's kind of like under the spring umbrella you don't have to use spring cloud when you're working on spring micro services but again you can choose to use it if you want all right so what is spring cloud spring cloud is an integration software that integrates with external systems it allows microservices framework to build applications which perform restricted amounts of data processing what no no no no no no hang on hang on wait that is it no this is this is not right that's not what spring cloud is okay so don't don't provide this answer i guess spring cloud started out with the integration system i think it was called spring integration or something like that so if at all this is an old definition okay this is not what spring cloud is so don't answer this spring cloud is again like i said it's a family of solutions which uh which implement which allow you to implement standard patterns in micro services right so you look up a bunch of spring cloud solutions so that you can you can kind of tell them and say yeah these are the part of spring cloud all right this is a yeah this is a bad answer i'm surprised okay discuss uses of reports and dashboards in the environment of microservices reports and dashboards i don't know if they mean like monitoring of micro services you do need to monitor uh your micro services when you have like so many of them running at the same time right you need to make sure they're all running fine they're on not consuming a lot of resources you know something runs out of memory you need to know that so you need you need a robust monitoring solution and an alerting solution so that your your support team knows when some instance goes down or something like that of course you you would have a system which actually spins up new instances when an instance goes down but in spite of that if it's still a problem then you alert support so there are various levels to it i don't know if that's what they're talking about reports and dashboards maybe some kind of a managerial dashboard for people to see how how they're doing and all that i don't know uh reports and dashboards have been monitoring an upkeep of micro services tons of application monitoring tools assist in this yeah i guess i guess that's what they're talking about this is an art question again this is the top hit for micro service interview questions hopefully people aren't looking this up and asking questions in interviews this is bad this is bad stuff okay what's the main difference is between microservices and monolithic architecture i'm not gonna go there we already covered this you basically gonna say the same things you define microservice and you define monolith there you go those are your differences all right i'm going to keep moving on um so the startup is fast so startup takes time well again depends on if you're doing uh from scratch or not we covered this loosely coupled architecture tightly coupled architecture yeah yeah change is done in a single data model does not affect other micro services changes done in the data model fx entire database what no changes done to a micro service does not affect other micro services as long as the external contract of the micro service hasn't changed okay that's what this is and it's not a not just about the data model uh micro services focuses on products not projects micros monolith puts emphasize over the whole project uh i don't i don't understand that this is uh this is crazy stuff don't know i don't know what that means uh maybe they're talking about the domain driven approach of microservices you know i talked about that earlier right you you basically have problem domains that you kind of carve out and build micro services from uh monolith puts emphasis over the whole project i don't know what that means um all right i'm going to move on to the next question what are the challenges faced while using microservices well there are a lot one is that it's it's more complex okay the deployment is more complex monitoring is more complex managing a product release is more complex uh there are certain things which you simplify but there are certain things which end up becoming more complex as well okay uh for example let's say you want to build a a system which affects multiple different teams right you're building a feature which affects multiple different teams uh you need to make sure that you're communicating it also to those different teams properly and you need to make sure that they all deploy at the same time so for example i have a feature a that team microservice team one wants to build a feature micro service team two is also needs to build the feature because they have to work together right so now we need to coordinate the deployment and make sure that okay after this goes then this goes then you release the feature otherwise the feature is not ready yet right so all the necessary microservices have to coordinate the the feature and get that released out okay and typically the way this happens is using feature flags okay so you have a feature flag which says okay this feature is not ready yet so micro service team a pushes out a feature behind a feature flag and says okay turn it off and when team two is ready then you turn this thing on you see it becomes a little complex but with the monolith that's not the case you basically have all the changes accumulating in like a parallel branch and then once all of them are ready then you push it out right that's simple but with microservices it's not that simple okay that's first thing second thing again multiple different instances so you need to coordinate them you need to manage them you need to monitor them all right you have more things to worry about more things to track more things to monitor that's another disadvantage so there are there are a bunch of them um let's take a look at what they say um microservices always rely on each other therefore they need to communicate with each other no why is it a disadvantage well yeah as long as again as long as you have the contract right you're fine it's only when you change the contract that it's a problem as it's a distributed system it's a heavily involved model i wouldn't put it this way but again i think what they're talking about is what i just mentioned right it's it takes a lot because there are more systems in place so more monitoring more tracking and all that if you're using microservice architecture you need to be ready for operations overhead i think this is true there's more operational overhead uh especially if you're not using the tools properly okay so there are uh tools again spring cloud has a bunch of stuff which allows you to track you know distributed tracing and all that stuff but if you're not using it well yeah your operations is going to be very very painful you need skilled professionals to support heterogeneously distributed micro services i guess you need skilled professionals to build monoliths as well i've been building monoliths for 10 years you're telling me that i'm not skilled how dare you i don't know you need you need skilled professionals for e for both um microsoft and monolith okay in which cases microservice architecture best suited microservice architecture is best suited when you have a large application with multiple teams working on it and you have a need for scaling okay you need to scale up and down quickly and you there are portions of your application that needs to be scaled up or down okay so now we have a large code base a large application and then portions need to be scaled up or down but that's a perfect fit for micro services because you can kind of take that as a micro service and scale that up or down rather than scaling the whole thing up or down okay and smaller teams makes a rapid iteration faster because the larger the code base the slower it is to roll out something new okay because there are more things to check more things to worry about test and all that so with micro services you're basically kind of reducing that problem and looking at smaller units so you can iterate faster okay so that's a huge advantage of micro services and the other thing is it makes going to the cloud a little easier because uh you can deploy these micro services to the cloud and if you have a cloud strategy you want to go cloud native well microservices is like you have to use it so those are some of the situations where microservice architecture is best suited uh let's see microservice architecture is best suited for desktop web mobile devices smart tvs variable etc i'm just gonna move on tell me some famous companies that are using microservice architecture well all of the big guys are using microservice architecture like all of the guys who need to scale right certain you know uh facebook google uh netflix twitter uh uber and uh what else amazon like everybody uses microsoft architecture these days uh the there are a bunch of uh you know industries which are still trying to catch up finance is trying to catch up there and there yet because finance is usually very conservative so banks and investment those domains they are pretty slow medical is pretty slow uh medical slow has been slow throughout um i guess the tech industry the tech side of things is it's all micro services right now like everybody's everybody's jumping into micro services uh most large scale websites like twitter netflix amazon yep that's that's fair uh advanced from monolithic to microsoft's architecture what are the characteristics of microservices we covered it i'm gonna move on it's the same thing um i'm not even gonna look at the answer what is restful restful is a way to build your apis that follows the rest specification and the risk specification involves treating an individual resource and having an end point that maps to a resource and then having certain verbs in terms of what you operate on that resource so for example you have a domain you identify resources and say okay these are like i have a user entity entity becomes a resource right you have uh an account entity account becomes a resource and then you do operations on that resource using http verbs right you have apis for for you want to get information you use a git api for it you want to update it you use push or sorry post output you know you want to remove it you use delete so there are verbs associated with it so you have resource mapping to urls the action that you need to perform is the verbs http verbs on it and then you have ways to manage a bunch of things like you know how do you handle query parameters how do you handle like uh a nesting right you have a parent resource in a challenge so so you handle it so it has specifications about how the url is formed how the api is formed how the interaction is so that is what is restful all right so let's see representatives yeah it stands rest stands for representational state transfer that's fair is an architectural style that helps computer systems to communicate over the internet these web services make microservices easier to understand and implement no no no no no this is not true it's an architectural style yes that helps computer systems to communicate over the internet well microservices use rest to talk to each other but they could use anything else it's just one of one of the one of the ways to do this these web services make microsoft these web services make micro services easier to understand and implement that's just totally wrong uh no no no no no no that's not that's not true explain the three types of tests for microservices well unit test integration test acceptance test you have contract testing which is which is kind of integration test with with microservices basically look at the external contract and make sure that's tested fine uh yeah i would say those are those are the three uh tests for microservices at the bottom level test we can perform a general test like performance in unit tests these tests are entirely automated middle level we can perform extra exploratory tests like stressed as youtube usability test top level we conduct acceptance tests which are mostly if you're a number i guess it's kind of right but um i would say focus on um unit tests which are like you're testing the courier methods right now the unit level and then you have the integration test contract testing and this is where you do like you know you can do performance tests and all that and then you have uh the acceptance test some people do performance in like the cross cutting test during the acceptance test phase you can you can kind of put it wherever you want but if you if the interviewer asks you three i would say those three right unit integration acceptance uh what are client certificates client certificates are you basically those are things that you set up for a client if you're making like a secure request to an endpoint right microservices are basically your services itself is a client and a server right you have a microservice client and a microsoft server so client certificate is something you install on the thing that's making a request so that it has the the certificate that's necessary to make the secure request okay um yeah i don't know i probably wouldn't be able to answer this question well it's a digital certificate used to make authenticated requests to a remote server it's termed as client server yeah that's true it doesn't have to be authenticated though it can be non-authenticated but it is it is it has to be digitally signed it's a secure certificate um all right explain the use of pact in microservice architecture well that is um is one of the things you can use you remember i was talking about contract testing it's a very important thing with microservices you can you can change your internals of the micro services as much as you want as long as the external api hasn't changed right the external contract hasn't changed so pack is a tool which some people use it's not used everywhere uh some people use it as a way to test that contract there are several tools which allow you to test uh do contract testing for uh your micro services so uh pact is like you know you make a pack right you have you have two people like we made a pact what is it it's an agreement so that's that's where the term pact comes from so it's packed as a tool which allows you to say okay this is my micro service this is my external facing api all right this is the agreement that a client would make with me and now this tool tests your external api to make sure it hasn't broken when you when you push changes right it makes it easier for you to push changes more confidently knowing that your api your external api is being tested so packed is like it's an open source tool which allows you to do it there are several tools it doesn't have to you don't have to use packed um it's an open source tool which allows testing interactions between service providers and consumers however it is separated from the contract made this increases the reliability of microservice applications yeah the the phrasing is very odd in these answers i would recommend not using those understand what what the question is understand what you'd need to say and then say it in your own words that's probably going to do uh you're probably going to do a better job than what i'm saying over here okay what's the meaning of oat excuse me so oat is is an open protocol uh open authorization um odds stands for authorization i haven't made a full video about this you can check it out if you want to know uh oauth is a way for you to have uh two systems uh authorize against each other you have multiple services and then they need to authorize with each other well you can use oauth as a way for them to interact with each other as opposed to a client like a user physical user interacting with a service a typical example is when you use something like facebook or something like google services in another site okay they would need to use your facebook credentials to log into your facebook and you don't want to provide your facebook credentials to them right so what they do is they have this arrangement called oauth which is an open protocol and as long as both of them implement what they can trust each other and you having signed into both of them can say hey now you guys talk to each other and play nice okay so that is oauth and this is useful in a microservice context because guess what in microservices you have one user and you have all these different services right they are talking to each other you want them to trust each other and oauth is a way for you to get those services to trust each other so that each service doesn't come to you and say hey login hey lock and hey login right you do it doesn't you don't want to do that so the oauth is a way for you to have that that authorization kind of like understood among all the different uh microservices in your system uh oath means open authorization protocol protocol allows you to access client applications on http for third party providers github facebook etc it allows you to share resources stored on one site with another site without the need for the credentials that's fair that's fair um what is end to end microservice testing this is where you you want to do the complete thing right i talked about contract testing where you take a microservice in isolation contact testing is basically like unit testing where the micro service is a unit but end-to-end micro service testing is where you basically deploy the whole thing and you test the whole thing okay so it's um you're pretending to be the user and you're automating those api calls and making sure you're getting the right response and an end-to-end microservice testing involves making a request to like the gateway and the gateway sending requests to a bunch of different micro services all of them working together to give you the response and then you get the response and then you validate it right you're not testing one microservice alone you're testing the system all right uh enter invalidates every process in the workflow is functioning correctly and ensures that the system works together as a whole and satisfies all requirements okay okay why are container used in microservices containers are used in microservices like for example docker it's used in microservices because uh deployment is uh is fairly common right you need to deploy a lot in microservices you take one service you need to deploy it into 10 machines 20 machines you need to scale up and down and all that and every micro service has certain requirements right you might have a micro service which say okay i need this particular software to be installed i want this configuration to be in this particular way i want the setting to be in this particular way so when you have all those needs it becomes hard for you to scale up your deployment into various different machines because you're going to have to do all of those steps for every time you deploy microservice however if you were to use a container technology like docker you kind of bake it into your docker image so in every case when you want to deploy a microservice to a fresh like ec2 instance you just deploy a docker image and everything that's necessary for that microservice comes with it all right so that makes it easier um all right what is the meaning of semantic monitoring in microservice architecture so semantic monitoring is when you're uh i think it's testing you're testing business cases which is what this means so for example you're you're building like an e-commerce application using microservices uh one way to test your microservices is by taking a microservice and then testing it in isolation okay like the contract testing right the other is end-to-end testing which is basically testing everything but semantic monitoring what you're doing is you're monitoring a certain use case certain flow a business flow and making sure that that's working fine so for example your ecommerce site you need to make sure checkout works fine okay so check out might be one micro service it might be like two or three different micro services okay so you're taking that one business flow which is critical you're if you're amazon you want to make sure people can buy your stuff right checkout process is critical so you have test cases which that's just the checkout process right from adding something to a card to checking it out so you're looking at a business use case as opposed to either a micro service or the whole application and testing those business use cases alone all right so that's uh that's called semantics semantic is basically meaning meaning based right so here whatever has a business meaning you basically take that out and then you test that that is semantic monitoring let's see semantic monitoring combines automated tests with monitoring of the application it allows you to find out reasons why your business is not getting more profits i'll tell you why your business is not getting more profits because your interviewers ask these questions and hire people who gave these answers that's why your business is not making profits this is a really stupid answer um you understood what semantic monitoring is right it's basically monitoring individual flows making sure that's tested and that's working fine all the time okay that's semantic monitoring what is cdc cdc is contract driven uh client driven contracts all right so this is basically the idea of uh having a client specify what the contract is for a micro service and then defining it from there as opposed to you just coming up with a contract out of thin air right so it's about being aware of who the client is what they want all the time what are the changes that they would need to make and what you need to make in order to support the the client's requirements okay so it's client uh consumer driven contract is another way i don't know if it's client driven or consumer driven it's a pattern for developing microservices so that external systems can use them i don't know it's basically focusing on the client first okay starting with the client and have the client drive the contract have them come up with like talking to other teams having them say okay what is it that you really need and then building your api building your contract from that is what cdc is right customer driven contact or client driven contract what's the use of docker uh we talked about this it's container containerization right you use docker to have an image of a microservice that you can safely deploy on a fresh virtual machine so that you know that your micro service has everything it needs to work okay it allows you to scale up your deployments by codifying what a microservice needs in terms of an image okay this includes other software that it needs configuration that it needs all settings and all that stuff so that's that's why you would use docker with microservices every time i'm scrolling down i'm preparing mentally for a really stupid answer i don't mean to be so rude and uh you know do these guysguru99.com but i don't know if somebody answers these this way i would be like what are you even talking about uh let's see how they do this uh docker offers container environment which can be used to host any application this software application dependencies that support it are tightly packaged together i guess this is a fair answer i'll give them this this is like if you answer this this is fine but basically that's the idea right you're packaging your or your uh micro services exactly the way you want them deployed so you don't have to bother about configuring them every time you just apply the docker image all right so some answers are right some answers are very very weird right so be careful what are reactive extensions in microservices reactive extensions are not related to microservices reactive extensions are a way for you to write asynchronous code using reactive patterns right using the observable pattern basically you you can use reactive extensions anywhere right for even driven applications you can use reactive extensions um which is basically writing asynchronous code right it's a pattern for writing asynchronous code using the reactive model of streams and observables and uh kind of like chaining those and there's a little bit of functional programming that's involved as well and that's actually why reactive extensions became popular in java with lambdas and all that became easier to to do that kind of that kind of programming in java so it has nothing to do with um with micro services i guess you can use reactive extensions when you're building microservices if you're building asynchronous services right asynchronous if you're writing asynchronous code in your microservices you would use uh reactive extensions the active extensions is also called rx it's a design pattern which allows collecting results by calling multiple services and then compile a combined response rx is a popular tool in distributed systems which work exactly opposite to legacy flows this is not what reactive extensions are okay design pattern to collect multiple results by calling multiple services and combining them to a response which is what you do in microservices okay so you would typically it's common for a micro service to call other micro services get the data kind of combine them together and send it back it's got nothing to do with alex okay rx is a popular tool in distributed systems which work exactly opposite to legacy flows no don't say this okay that's not the right answer explain the term continuous monitoring continuous monitoring is a way for you to constantly check how your micro services are doing it's in addition to the c terms okay so there is a ci cd continuous integration continuous delivery so there is continuous monitoring as well so if you are constantly releasing stuff by using ci cd you need to constantly monitor it as well right so because you can introduce a bug at any point of time okay so continuous monitoring is a way for you to kind of constantly keep keep a check on the health of your system this includes kind of implementing some kind of a distributed tracing mechanism to make sure that if there is an error you know how to check it if this involves checking how your systems are doing like what's the processor utilization memory utilization when do you need to scale up when you need to scale down you know number of requests that are coming there's something called qps uh all those things are you know you have to constantly check you have dashboards for checking that which is what the earlier question was right what are the dashboards you would use so that's continuous monitoring constantly checking your micro service system to make sure everything is good continuous monitoring is a method of use for checking searching compliance and risk issues associated with companies operational financial environment extending human process the working system which support efficient actual operations again no no no no no no this is not right right don't say this how independent microservices communicate with each other they use rest apis well they can technically use any apis but a common common choice is use rest apis and then the the payload is a json payload the content type is json depends on the project needs however in most cases developers use http rest with json or binary they can use any communication protocol good answer all right this one's a good answer it's all over the place this thing okay i think we're done so these were 24 questions they lied i think say 25 questions and they lied and there's one question sharp but these are supposedly the top 25 24 micro service interview questions and answers i'm amazed that this is the top um ranked search for microservice interview questions do you guys see this as a top hit for your searches it's uh the answers are all over the place so hopefully my answers were helpful don't say these answers as is mentioned over here some of these answers are clearly wrong and you shouldn't be mentioning this of course you stand the risk of an interviewer looking at these and expecting the same answers uh if they expect the same answer then you don't want to work in that company anyway because that's um yeah that's not good so these were the top microservice interview questions and answers uh i have i'm going to link to the brain bites playlist which has some of these concepts explained in more detail so go check that out you

Channel: Java Brains

Views: 286,036

Rating: 4.878952 out of 5

Keywords:

Id: o36vWQCRrp0

Length: 39min 54sec (2394 seconds)

Published: Fri Jan 29 2021