Lalit Kumar

Hi, my name is Lalit. I'm currently working as a software engineer 3 at Scrapoint. So, my total experience is around 8 years, which includes the internship period. If we do not consider the internship, it's 7 years and up. I'm currently working as a Java back-end engineer, working with multiple microservices. This is a product-based company that deals with commercial routers, private SIMs, private networks, and everything. I'm working on it using Java, AWS, RabbitMQ, Postgres, DynamoDB, and Python as well. We're using most of the latest intelligent technologies here. Prior to this, I worked in the reinsurance domain and worked with Blockchain architectures, the Blockchain networks, where we developed the entire reinsurance business on that. And prior to that, I worked at Infosys, which was my first company. All of my relevant experience has been in Java and Java development. Some of it involved customer support and a little bit of automation using VOTA, but mostly, it's been development.

When did you use a rebase instead of a merge in Git? So merges are used when we're doing some kind of changes, like when we merge from one of the changes to our branch. It's done when there are multiple kinds of changes, and I think when there are 2 open MRs or PRs. So if one of them goes in and then the other needs to be rebased on top of it so that the new changes which went in are also present in the other MR as well without any conflicts. So that's necessary. I just did it three ways. But merge is like when we're pushing the new changes to the master branch or any other parent branch.

What are the contact decisions to ensure data consistency using transactions in SQL, which may ensure that each transaction is atomic, consistent, isolated, and this one more. So, data consistency needs to be there. There's only one update happening at a time, and the update checks for no race conditions which may be happening. And, the data – if it's in a database that's not sharded – there are database replicas present, and all the replicas are updated eventually. So it's eventually consistent within that time frame. Unless and this, the most consistency always required. Any other outgoing or incoming calls should be kept waiting before we try to update any kind of data or any creative data. So there is no, what's the term? No collisions happening on that.

The following code snippet are the full end point is there. Can you identify the importation issues? Post mapping create a response entity. user deposited to the c would return. Response entity dot okay. I think it should be create responsibility to create user. That should be it should be, if it is Creating a new user that should be 401, not 400. Okay. Sorry. 201, not 200. So okay is 200. So we should use 201 or, for the new entities. Other than that, I think this is fine.

So the purpose of dash is to separate items in a list. And, where text is defined as valid text This is going to be a string. Okay. There's a purpose of version. So It's kind of a any kind of so value text Could be anything. But if this is this, like, it could be a list, could be a single object. That makes sense. Not really familiar with Kotlin. I'm more of a Java guy. So, I'm not sure. I need to practice it. I'm unsure about this one.

How could you secure sensitive risk for endpoints in Spring Boot applications? So sensitive endpoints could be secured in multiple ways, like where the JWT token takes effect or a bare token in that sense. Where the token specifies whether the user has access and whether the user will be provided access. It could be rule-based access control. Where if, for example, a certain set of endpoints could only be accessed by the user who has that role and has the permission to access that action. And the token contains information about the user's permissions. So before accessing the endpoint, the token would be validated to see if the particular user has permission to exit the particular endpoint with any kind of HTTP action. For example, certain users could access GET, but admin users can access all of it. So those kinds of things would be there. And that needs to be evaluated properly. Okay? That's why I think we can secure the rest of the endpoints. And the rest of the endpoints should also be directed to the security mechanism. It cannot come in indirectly; the authentication and authorization should be done properly before accessing them. So that's how we can secure the endpoints.

The coding goal business uses Spring Boot to connect to the database. My data server might not initiate the user, so the data says might not be initialized. Probably because of the Spring Boot and the configuration, it auto checks whether the following username and password are configured properly or not. So the Spring Boot auto checks for that configuration. The other configuration and the property source, we give the class, which will contain all the information. Configuration will auto-configure it in the backend. So if you provide an incorrect username and an incorrect password or any of the URLs, it will auto check whether this particular user has access for particular URLs. Whether it has access to this person's URL or not. So those kinds of configurations and checks are done behind the scenes. If those are incorrect, Spring Boot will not allow us to go to the next source, which is why the data source might not be initialized properly.

We handle versioning in the RESTful API design with Spring Boot by when at the rate components. Handling configuration is done when we give the data source over there. The URL of it, along with the host and the v one and the v three. For example, if it's an internal version, we use v one. If it's an external version, we use v three. Other than that, I think it should be auto-upgraded. For example, if there's any change in the endpoint, we increase it, like 1.1.1.1.2. In that sense, we have to define it. Some applications do not allow backward compatibility. So we need to handle that. And if we upgrade, we need to depreciate the old endpoints along with the time. For example, we could let users know how we're going to depreciate them and when we're going to release the newer version. And given the time, we can use it slowly or have complete support for the old version for a while before removing the backward versioning.

I use advanced gate features to manage a hot fix on a production branch while working on a feature branch by using cherry pick, which allows us to cherry pick a particular commit. We can then test that hotfix on the feature branch, see that everything is working, do all kinds of testing, and then cherry pick that particular commit onto the production branch. This way, we can manage it without moving the entire thing from a feature branch to production, but only that particular commit.

What strategy would you apply to ensure zero downtime deployments for a Spring Boot-powered service? So here, what we use is Docker and Kubernetes. We have different ports for each service. When we need to deploy a Spring Boot-powered service to AWS, which is in the cloud, we can create a new service or new port with the latest version. And while the old version is still running, we continue to serve on it. Once it's deployed, we bring down the older version and redirect all the connections to the newer port. That's one of the approaches we use.

Benefits to coding support we provide for back-end development. I'm not sure about that. Sorry.

Has been used in a Spring Boot application for smoother feature rollouts. Well, there's one approach where I think we could use feature bindings over here. Like, so we could ensure that the feature bindings are there. For example, we don't want to test out a new feature in beta version, but we want to test it out on a larger live customer base. So, if we introduce a new feature, we could introduce a feature toggle, or a summation of feature toggles over there. And that could be opened up to a particular selected group of customers to test it out. So if the feature bindings are enabled for those groups of customers, they can use the features, and we can live test on them. And based on their response, their feedback, and any issues, we could test and fix everything before rolling out to the larger audience. So that's how we can control each and every new feature over there. Also, for example, if there's a beta with a lease, we could use a subscription model, like whether the new selected group of customers are interested in those, and so we can enable it for only a group of them. That's how.