Durga Sai Eswar

Hi, I'm Sai Ishar. I have five years of experience in back-end development, where I develop REST APIs using Flask and FastAPI frameworks, and write integrated business logic with the APIs, ensuring the application has 95% core coverage. I create test cases, including right integration test cases and unit test cases. I also write Docker files, Kubernetes manifest files, like ingress, and manifest files for deployment, replica search, ports, and ensuring the application is accessible from the browser once deployed on the Kubernetes cluster. I create CICD pipelines for automatic deployment to the Kubernetes cluster. So, in all these areas, I have experience. That's pretty much it.

What are the best practices for structuring classes? Miss Practicing. Miss Practicing. Launching Python code is for us to always try to develop application code in an object-oriented programming manner so that when we follow design patterns while writing object-oriented programming code, it will always be our application will be flexible and open for enhancements and maintainable. And in all these areas, it would be beneficial for us when we develop a code and write a code in object-oriented programming manner. So, like that, we have solid principles already, such as single role responsibility, single responsibility, and dependency inversion, and I think there are other principles. So, when we are writing object-oriented programming, following the SOLID principles and maintaining the design, we may create a design pattern like the factory design pattern, singletons design pattern. So, when we follow this manner and write a code in this particular way, that will be the best practices to manage the large Python code base.

What strategy would you recommend for versioning the rest of the APIs when adding new features to an existing one? Usually, we can do this through blueprints. So when we're developing APIs, we always write APIs for using blueprints in Flask or anything in FastAPI or any framework. These blueprints will help us utilize the URLs for version 1 or version 2, making the URLs different for 1 and 2. In this way, we can segregate them better. Apart from that, my answer would be going with blueprints for maintaining the APIs so that both versions are available to the user, whichever version they want to utilize. They can utilize that particular API. I think that's all.

We always have data persistence and fault tolerance in a cloud-hosted Python application using vertical scaling. So, the application is deployed onto a Kubernetes cluster. We always try to create persistent volumes attached to every application port, making sure that port instances are available, with 5 instances or 10 instances depending on the use of the application. We can always try to do vertical port scaling, and the other one is attaching a volume to the port so that even if the port crashes, the data still persists in the persistent volume. And as and when the port is up and running, the data available in the volume can be used in the new instance of the application. So, my answer would be to go for horizontal scaling and also attach a persistent volume to it if the application is deployed on Kubernetes. Yeah, that's it.

To develop a system that requires transactions within Neo4j to adhere to asset properties, I would achieve it. If tasked to develop a system that requires transactions within Neo4j to adhere to asset properties, how would you achieve it? Okay. So in the Neo4j database, we always try to deploy this as a port in the Kubernetes cluster. Let it be one instance or two instances or four or how many other instances that we want. We keep running those many instances specifically for the Neo4j database so that if one goes down, the other one will be up and running to solve the request. So keeping all the asset properties in mind, like availability and consistency and durability, integrity, and all. So when we have multiple instances up and running of Neo4j, we will not be facing any problems, and it will always contain the set properties.

If the machine learning model, whatever that we are using for the inferences, if it is a bigger model or the smaller model, depends on that. We can choose the service. The smaller model, we don't have to utilize any of the machine learning services of the machine just to save the cost and the maintainability and other things. If it is a bigger machine learning model, the smaller machine learning model, we just run it within the Kubernetes cluster or any easy two instance that has the models, and then we can run it. Otherwise, we deploy this a bigger one that requires a lot of maintainability and things like that, we can go for deploying our machine learning model and keep it available in AWS SageMaker and enable those models through an API. So all these management will be available in the SageMaker services itself. Once the model is deployed in that service, we make the model enabled through the API. Our model is ready. So whenever the Python application receives data, it makes a request to the SageMaker API and then gets the inferences and does the processing and returns the output. To put it in a nutshell, when the data is coming in, someone is making a request to our API, wherein they need some predictions for their input data. Let it be an image, what does the image contain, or let it be a file that has text format, so whatever the user wants to predict. The input data will be sent through our API. We'll try to do a little cleaning and preprocessing before sending the data to the model. Once the preprocessing is done, we'll send that data to the SageMaker API within our Python application. And once we make the call to the SageMaker API, that gives a prediction using the models that we deployed, and then that output will be utilized, formatted in the necessary way, and then return the output. In a flow, that's how we'd work. If at all, if any other things that are needed for storing data or storing predictions, we'll try to store them in the S3 bucket. Or if it is a Python application deployed in a Kubernetes cluster, we can put it in the persistent volume. The API gateway and the application are in the Kubernetes cluster. The model is in SageMaker. We take the API gateway, make sure the requests are filtered, and we keep the authentication to our API wherever the API is developed, which is in Python. And once it is done, we make a call to the SageMaker API to get the predictions and then get the output from the model and then return back to the UI or user.

Consume the phone. It just, whatever the return statement that is there in the code, that return has some arithmetic operations happening. So that formula is mistaken. So it should be price minus price into discount percent divided by 100. So first, the percentage will be calculated from the price, and that amount will be deducted from the price. So it's just that we have to modify the formula that we are doing to calculate the discount. So price minus, open parenthesis, price into discount percent divided by 100, close parenthesis. So first, it calculates whatever inside the parentheses, and then that output will be deducted from the price and then returns the final amount.

In the code snippet, there is a I think, single responsibility principle is missing as what my guess, wherein one class is doing engine start, and the same time, it is also playing the music. So two things are happening. My answer would be the single responsibility principle is missing here. So in the car class, only the starting or initiation part should be there, like start engine, or anything like that. And all music related functionalities should be in a separate class. So that class will be directly dedicated to play music, raise volume, decrease volume, and stop music. So all these kinds of functionalities come under the media player of the music. So those functionalities will be in a different class, and related to starting functionalities would be in one class. So the single responsibility principle is missing here. That would be my answer.

Demonstrator technique to ensure robust handling in a distributor system that leverages both API design and robust error handling. To my knowledge, we usually keep try-except blocks wherever it is needed, or wherever the developer identifies the errors. So, we'll try to catch the errors through the try-except block itself by writing customized exceptions, like if it's something unexpected, not a value error or key error, or the default error. If some other errors are coming in, we'll try putting the customized errors in a separate file and raise those errors and put them in the try-except blocks. So, we'll utilize those errors and raise them whenever it's needed. The answer would be to use try-except blocks and also use customized error handling so that you'll be handling almost all of the errors that are gonna raise and according to the developer's expectations. I think that's all from this. That should be the correct one. To my knowledge, that's my answer for this.

I'll discuss the strategy to monitor and document the scaling of Python applications in the cloud using both CloudWatch. We always use CloudWatch to monitor the application logs. So, at the same time, we also monitor the metrics of the instances that are up and running. Whenever we have a threshold for, you know, when the utilization of CPU or memory crosses 75% of it, we trigger an alarm to initiate the auto scaling process so that CPU or memory is increased according to the usage of the instance. This can be done automatically. Using CloudWatch monitoring tools, we can set a threshold of 75% or 80%. And whenever the usage crosses that threshold value, we can initiate the auto scaling services to increase the CPU or memory of the instance. That's it.

I would choose Neo4j only when a lot of data coming in is enough. I know, three or a family kind of structure away. Let's say, one data point is related to another data point, and a lot of these linked data points are available. And these linked data points are making a form of a tree or it's all, like, nested links from one point to the other point. So when the data is in that form, I would definitely go for Neo4j database because all databases, Neo4j is the best one to manage graphical structured kind of data. What else would I choose between? I haven't much worked on Neo4j, but I have just theoretical knowledge. Based on that, I'm answering, I would choose only Neo4j database if the data is in the form of graphical structure or more of a linked nature. Let's say, one point to the other point, the other point to the other point. It's a lot of linking happening. So in that manner only, I would choose Neo4j. In any other manner, I would go for a relational database.