Veeresh gutti

So I carry 13 years of experience. I mainly worked as a back-end engineer all through my career. So I started my career with Pertini Computers. I worked there for 3 years, and then I joined Ducommun Solutions where I worked for 4 years, building an analytical solution which is backed by big database technology, such as HPS, Hadoop, Apache Storm, Kafka, Zookeeper, and all those technologies. Then I joined Rakuten. With Rakuten, I was there for 4 years. I was part of building API gateways, which is used by a lot of services in Rakuten. Then, as part of building Rakuten Music and Rakuten Live Application. In Rakuten, I worked as both a senior software engineer and as a senior technical lead. So I was doing complete hands-on work, along with some entity management activities. Then, after 4 years at Rakuten, I joined Paytm. With Paytm, I was working as a senior technical lead there. And I was responsible for leading a team of 10 to 12 members, handling the merchant side of our application, which is called RTD, which includes all merchant passbooks and settlement-related details. Those things were actually built by our team. Recently, I was working as head of technology with C Ventures. Again, we were building a product called credit scoring as a service, which is used by a lot of SMEs in the SAP Pacific region.

I think irrespective of the technology that we use, it is making each and every request as a stateless system. Right? If you build an API, which is a stateless system and can be handled in a distributed environment. So, each request coming into a distributed system can be handled in a distributed service. Right? The request can be routed to any of the instances that we deploy. So making it stateless will help us in deploying and then horizontally scaling our applications. So how do we efficiently handle sessions? So make it stateless and process the state at a centralized DB level or a caching level, which is again centralized. So, your applications are distributed, but the persistent storage, be it a cache or be it a database, should be a centralized system. Again, we can scale those services also in terms of master-slave configurations, read, write, primary, secondary kind of a configuration, which is easily handled at the database and the caching level.

I think, you know, couple of things here. 1 is, we need to check the steps. Right? Whether enough whether, we check the reason and why the Jenkins pipeline is failing. It may be because it may not have received the webhook from the source control, whether from the Git or once we commit the changes into the Git repository, the changes may not be propagated and the webhook may not have been triggered so that it triggers the Jenkins. If that is the case, figure it out and fix the webhook call. Second, thing is on the build side, if our application is not properly building. You know, before the build step, there would be a static code analyzer. So if you had set some of the rules for static code analyzing, if some of those rules have a high percentage of failure, that may be the cause for the Jenkins failure. The next one is build. If the build fails, check if all the dependencies are being resolved in the build stage. It may be because of compilation issues or dependency issues. So if it is a dependency issue, look for any dependencies that are expired or unable to download from the Internet or unable to find them in local repositories. Fix them. If the build is failing, find out the compilation issues and other things if that is the reason. So if the build is successful, maybe the next stage is propagating in deployment. So, if that is also part of our chunk in shop, figure out if the required infrastructure is ready to deploy. Whether we are able to start the server, or is there any port configuration missing? The application is already running, but they're unable to start due to memory issues and all sorts of things.

I think irrespective of whatever language we use, we always build the full script and the build steps are the same across languages. For TypeScript, it's also similar. But, you know, pull all the source code from the repository as soon as the web book is triggered. Pull it into a Jenkins server. Now execute the build script there before building on all the necessary requirements for dependency resolution or static code analysis. Complete those things and, you know, build the TypeScript project. It's simple.

So, what is on the application side for Node.js, this results very much generically in the respect of the language that we use. For Node.js, obviously, being an asynchronous in nature, it should be able to handle a large quantity of asynchronous requests. Right? So if there is a large volume, you know, whether my service is scalable or have I done enough sufficient applications to handle the largest load. Right? And I just have those things in mind. And so see if there is what type of load we are getting is also important, whether it's more on memory or is on CPU consumption, memory consumption, or IO consumption. It depends on that. So Node.js really does well if there is a lot of IO consumption, which can handle a lot of asynchronous requests. If there is a memory or CPU related thing causing the load, so that probably we need to horizontally scale with these resources. We can deploy multiple instances of the Node.js application. That means containerize these applications and do horizontal scaling with some orchestrated tools. Right? So that should be able to help.

K. It's a rectangle with a number construct with the number. It's its width and height. So it's a big class square, extends a rectangle. Okay. Construct size, set to width, no width, and that is equal to same. Yeah. I think so this one would be single responsibility inwards and move. Open, close. I think so this cross substitution is the one which is you know, we can't substitute our square class with, you know, rectangle objects. Right? So that's one thing, and it's not an extendable one as well because it violates the open close principle as well because the square class cannot be extended from the rectangle because rectangle is a different shape and a square is a different shape. Right? So open, close, and this goes substitution. It should be two of the principles, I would think. Yeah.

What's wrong with that is the hedge block is being used. How do you rewrite this correctly? And the other G, I. Let data what is it? What's the block? See what else? Try catch block. Used. It is. Okay. So look at the JavaScript function. What's wrong with the cache block is being used? How do you rewrite this correctly to handle the errors in a more synchronous context? I think since we had put it as an await, you know, we, the external system, will be waiting. It makes it a synchronous call. So, you know, no idea on this.

Handling database schema migration in the continuous delivery system. It's very difficult because if it's in the live environment with the live production, traffic coming in, migrating those systems is one of the critical tasks in the industry. So, to handle that, I think we need to build a two-step solution. One is we build our migration script, which migrates the data from the older system to the newer system, which we call a migration script. Right? So we can build our own script or use industry-based tools to migrate those databases. If it's a different database migration within the schema migration, we need to know what type of migration is required. So that's the schema development, which will put the data in place. While running this schema, a delta will be created because of the live traffic coming in. Within the application, we need to deploy a redeploy code with some switch logic, where it deploys the code to a newer service. Right? So, the live traffic, whatever the live traffic request coming, will be based on a flag, which will send it to the newer databases or the old database. This depends on the timestamp of those requests or based on the users, how we decide the migration strategy. So, we have that flag and deploy our application, which will run and do proper traffic redirection. So, in this process, at the end of the larger data migration, most of the data will be migrated to the newer system, and the traffic will also be redirected to the newer databases. In the end, if there is still any data left, we can handle it with database-level or application-level handling. If there are still requests which are not committed and all those things from the database, we can get it from the commit logs and try to create those migrations from there. This involves multilevel database migration scripts, database and application traffic redirection, and some strategy based on the location, users, or time-based ones. And then, finally, the last delta will be updated directly from the database update logs.

How do you pursue the trade-offs between using Java and Python for microservice deployment and respect to ecosystem advantages? I think, so, very good question. So, one is, you know, Java is mainly we can write a proper enterprise-level application. It has got a lot of support for that, in terms of frameworks, in terms of industry use cases, in terms of representing our problem into our domain to win solutions, you know, representing them into an object-oriented solution. Right? That is, really good with Java. So, we can build a very high, very low-latency system, and we can scale it up to millions of requests per second. Right? So, that is in terms of Java. In terms of Python is really meant for analytical purposes, in terms of text processing, in terms of AML applications, right, in terms of building analytic data analytics kind of an application. Right? So, it has put a different use case, which is why I'm building a restful API or something like that. Python has got some good frameworks, but it's difficult to containerize and deploy it. It has short of some of those frameworks that are required for building these types and in terms of authentication, in terms of building a large-scale enterprise application. Right? So, that's where it's a little bit difficult with Python. So, Java would be for the applications with an enterprise scale. Right? So, Java would be the better one. If I'm building any text processing-related activities, if I'm doing some data processing or data analytics kind of a thing, number formatting kind of a thing, you know. So, all those things are because of a lot of library support for Python, so which is very much helpful. Right? So, that is the thing of both have different use cases. So, I would prefer to have both if I'm building up in a larger application. Right? So, I prefer to have both, and I would be in the current scenario I would build a lot of applications in data analytics kind of applications using Python, and a lot of APIs can be built with Java and related technologies.

What technique would you use to reduce complexity of a large Spring Boot application? I left with one more question. I'm okay. What techniques would you use to reduce the complexity of large Spring Boot applications? Right? I think the largest Spring Boot application can be split into smaller chunks because a larger application with many interdependencies and instance creations would be a very complex process. It would take a lot of ramp-up time to boot up our applications. So one simple logic is to break this into smaller services or smaller modules based on the use case or business logic, so that instead of a large monolithic Spring Boot application, we can divide it into smaller chunks, or microservices. Define the communication strategy between these microservices, if required, and use Kafka, or use HTTP REST-based, or use blocking or asynchronous. Right? So these things can be implemented. Yeah. I left with one more question. I submitted the third question without any recording of the session. So I hope it would be an option to record that third question. Right? So I really cannot go back to that particular question. So I would really appreciate your help in answering the third question.