Sudhanshu Rajendra Bawane

Yeah. So this is Sudanshu. I have been working for six years now. It's more of a core and backend. I would say, sometimes the requirements and

Well, to have a rate limiting algorithm, you can use multiple functionalities and methods. The one I had used in one of my previous projects was with the least connection approach. So the way this works is: if you have two servers, one server has already 10 request processing, and another has nine request processing. Your rate limit algorithm does this: once something comes in, it blocks that number of API entries. In layman terms, you can say it uses a bucket and other things. Let's just say there was a bucket, and you configure that bucket in such a way that it would only accept around 5 balls. As soon as the 5th ball comes in, it will just get spilled out. These are certain ways you can rate limit things. The reason one basically uses a rate limit is to control API responses and make sure there isn't an overload of things, so the API performs well.

If you have to implement polymorphism in a Go line without modifying the existing functionality, to me, I think, only thing I can think of with, would be use of empty interfaces with struct embedding.

If your service is really heavy, one design aspect in Golang would have put priorities to ensure optimal performance. K. So if the service is read-heavy, that means, first thing that's clear to me is that my DB transactions, whatever they might be, will have to be itemized and independent of one another. That means some read calls will be going on, and I don't have to worry about write operations. So if it's such a case, then I would usually go for a structured database design, which will be our SQL one, as it's easy to retrieve and search from a structured database compared to your document study database, which would be NoSQL ones, like MongoDB and things like that. But for this exact requirement, I would usually prefer a structured database, a normal, like traditional SQL one. This will give me optimal performance because if I have to search in a very segregated manner or for a very particular 1 or 2 bits of data, it's easier, and it's also easier to formulate a query for that. Not to mention, I can pass certain exact parent results, which is not doable with unstructured ones. So, yeah, that would be it.

In your Go applications, if you need to ensure that each and every transaction or operation with your DB follows the asset properties, there are certain ways to make that happen. So let's say you have a microservice architecture, and everything is happening. In such cases, we have assets, and first would be atomicity, then consistency, isolation, and durability. To make sure each and every one of those things gets properly validated, the way I would start constructing things is by using Microsoft's design approach. I would take a first approach using ACID (atomicity, consistency, isolation, and durability) in calls, because whenever you have asynchronous calls, you don't have to wait for acknowledgment. And then at the end of the day, you can run a lookup or something like that, which will synchronize your entire DB transaction that has happened. If there's any mismatch in your transactions, you'll be able to detect it. That's one way of doing it. But if you want an atomic transaction with consistency at the same time, then an async model is not the right approach. You need a model with request-response acknowledgment, and DB transactions are usually preferred in standard structured databases like SQL and all. So, this is how I would usually think of it.

Well, in terms of SQL injections, I don't have exposure to it. However, later I have used SQL, so I'm not sure how to prevent an SQL injection attack when my goal is having user-generated database queries.

So it shouldn't be there. It should be all. Well, the for loop is perfectly fine, I would say, as it's assorted code, and the smaller one is will be getting upended every time things are happening. Same goes for your equal scenarios. I would say the logic error would be in the forward statement, the conditional. An operation will fail in so many corner cases because it has never been specified that both slices are of the same length. So in such cases, the standard approach should be to check for the smaller slice length. So how would that be? Let's just say if slice a is the first one, it would be of a smaller length. So I would have, like, 4 I is less than the length of a. And then I will do my everything, result and all. There would be something else, and it would be a pending based on things. As soon as this loop gets over, whatever counter for the j would be, I would take that counter and the remaining element for the j array and directly append it to the result. So that's a better way to do this. I can even put, let's just say for a I can even put an or statement there because and would fail in a major case. So or would be a better approach instead of logical and. Or the first approach is always good. You just have things there. Or what you can do is you can do a reverse append. Like, the append shall be from the back of the array. That's also one of the ways you can do it.

Interface area. Okay. Floor 64. Shape.area. Well, one thing I can think of is that the way we're using interface here, if I need to use other shapes, then I have to create more area methods, meaning more area functions instead of just using one and then getting done with it. What we can do is have my interface as a kind of template. So, if I need to use a square structure, also, which in that case, I will have other things like diameter and radius. My area or whatever, that would be called, like, circle, semicircle. It would be according to this code. Yeah. So, it will create some independent mode functions, which is not usually encouraged as the reason we use interface is to make sure to keep the length span of the entire code small and to have reusability of whatever function that has been defined in it. So, that's the only thing I can think of it. Otherwise, it seems kind of okay with me.

Well, I don't know how I would have it in AWS. But for usual adherence, for a go service being highly valuable and they're having other things, certain things you can do. First of all, it's usually encouraged to have a profiler. So in Go, you can create a profiler and things like that. One more thing that I usually follow is create a watcher. So it watches who are on the APIs, and it has a connection to an HCT manager. So as soon as there is something or there is any modification or let's just say my API has 3 calls, create, delete, update. Whichever call is getting performed, my entity manager informs me continuously. And as soon as something goes wrong, there is usually some recovery management code written behind it based on the scenarios. So that would be profiler voucher. What you can do is that whenever you write a service, so to make sure that service is up to the mark from the start itself, it's a good habit to create some benchmarks in your project. So service is created. So to test that service, keep some benchmarks and things like that. That will give you a proper running service. In terms of AWS, I don't know. My work experience with Go wasn't like that in a way that I would have to deploy my service on AWS. But the way I think I can think of certain things. Highly available. I'm not sure about AWS, but I can think of it in a Kubernetes scenario. What you can do is that you can make sure your selectors in your services, let's just say if you have cluster IP and things like that, you can configure them in a way that your resource management is properly handled. You can have your load balancer to make sure your services are highly available. Let's just say you can configure it in such a way that whatever ports they are running on, as you say, you had 10 ports and they were communicating with their local host, and every communication was going on. You can implement certain Kubelet services in a way that utilization, once it goes beyond 60% or 70%, just shift remaining load that is coming to the load balancer to those ports which are identical or ideal, basically. So let's just say you had 4 ports and you had 4 replica sets of them, and those replica sets were ideal. So as soon as utilization goes beyond 60% or 65%, a replica set port will be used. So that's one way you can do it. I think we call it something like weighted round robin load balancing approach. So you can do that. For this question, in terms of AWS, I'm not sure. I haven't used my Go services with AWS yet. But with Kubernetes, yes, you can do it.

I would say that instead of choosing a singular service, you can create a family of multiple services. Have a Kubernetes setup, have Redis, and both of them in conjunction. They will provide you with so many options and services in such a way that your services, or whatever you would be running in your Go applications, will always be available. They will have many disaster scenarios covered. Once that is done, you can take that entire family and deploy it on your AWS SDK. So it was highly available, highly scalable, and now you have fault tolerance because it was only a premise setup. Now it's on the cloud, and you have more range to scale it horizontally. You have more replica availability. In such cases, plus on top of that, AWS itself provides certain fault tolerance features. And because of that, I would say it's good to create a family of components instead of just choosing a singular one. You can do it with a singular one; there's no issue. But in terms of cost and effectiveness, I usually suggest creating a convention of multiple families. I take good from Kubernetes, I take good from Redis, and I take good from AWS, and I combine them to make a better, you know, better-performing product. So, yeah, that would be my thinking on this.

How would you manage human rights, deploying, scaling, and operations on the whole and the API on AWS? See, in terms of Kubernetes, management and deployment, now what you can do from the start, you can enable your horizontal scaling. So, irrespective of the service that you choose, maybe cluster IP, node port, anything like that, it will always be having some horizontal scaling. So, your scaling is done. In terms of deployment, it's good to have replica sets so that if one port goes down, you already have another port to take its place. And, you know, things are always highly available and going on. So, your service won't go down. Because, in terms of pause, one thing people forget that they are item protected. That means those pods are constantly getting destroyed one after another, and new ones are getting cleared. So, it's good to have some replicas, you know, as a backup. No. If there are multiple, you know, go back and APIs are running, what you can do is that you can configure your selector in cluster IP that will give you a highly scalable API request response or you can say performance. And now when you put that on AWS, things will be a little bit different. Because what happens is that under AWS, you have more scale. Your resource-absorbing capability has increased drastically. On AWS, now you don't have to worry about your on-premise setup. You don't have to worry about how to scale it now going forward because horizontal and vertical scaling both are available to you at a higher degree now. Plus, there are ways in which you can configure your load balance. Let's just say if you are using a weighted round robin approach on Go, you can do it in a way that lets just say your API service or your entire Kubernetes were running on some buckets and things like that. You had some Lambda to support it and maybe some current scenarios, current training, you had some ML models going on. So, based on such architecture and complex system, what will happen is that your back-end API will always be running irrespective of what's happening. You will have fault tolerance. You are going to have your services, you know, always in a scaled manner. What you can also do is you can create a profiler, have a dashboard assigned to it, maybe graph on a dashboard or Prometheus for simpler things, and keep consuming the metrics. So, as soon as something happens and that metrics produces some kind of alert, configure your AWS in such a way that it will do your on-time load balancing. AWS has that functionality, so you know, just make a use of it. So, yeah. That is how I would usually utilize, I mean, that's what I think, that's what I can think of in terms of utilizing micro.