Tejas Gowda

so basically my core technology remains Java and mostly I have worked on Spring Boot microservices architecture and even driven that too in it apart from this I have been a core backend developer since the inception, something around 7.4 years. So mostly I have worked on startup and also product-based startups ranging from media to fintechs and mostly I spent 4 to 5 years in the media domain and worked on content syncing, user registrations, and gathering user journeys in mobile apps. These are my development spaces where I spent most of the time. Apart from this, in the fintech domain, I used to develop mathematical models using Java and R language. So over there, all the regulatory tech startups need to be converted to software. So basically, all the financial reforms or, you can say, the frameworks which are defined by big institutions for lending money have to go through proper rules and regulations and all other calculations. And those rules and calculations need to be converted to software. So basically, it was a replacement of consultants with software. That's it from my end. And apart from that, recently I worked in Zee5 in the payments and subscription team where I integrated third-party payment APIs from Pay or from deducting the amount from the customer's bank account to the refunding flow. And everything was being developed by me and my team. Apart from that, I also worked on the renewals part of Zee5 where subscriptions and renewals happen regularly on a monthly basis or as per the plan expiration period. That's it from the latest.

So, basically, whenever the radius, there is a certain time interval that needs to be fixed, so that the cache can be cleared first, and it has to be revalidated. You know, what so it may be we should have specific time intervals like, grouping all the plan IDs, and then while we're getting the tentative dates where the plan ends. So before that, it needs to be flushed out. So in the code itself, we have done that flushing thing. We have scheduled a time. At that time, it will be flushed and the data needs to be reloaded into the release. So that's what we have done here. And we have used release in fetching the brand details as well as in work for validating rules and everything before the plan has to be attached to whatever before the black bag has to be attached to the z five. We have used radius to validate rules and plans while fetching the plan details and everything.

So, basically, whenever the data moves from one service to another service and the state to be maintained, it can be maintained by using a saga patterns, where the state has to be maintained in a conductor. And, whenever it moves, when the data state changes, the conductor gets updated as a finally, it persists in the databases. So that's a one strategy pattern. We have one pattern where we used to maintain the payment state in the Ziff ecosystem. So Saga's pattern can be really helpful in maintaining the data consistency across the microservices. Also, apart from if there is no saga, we have to use the normal retry mechanisms, but we cannot rely on it mostly, because it is difficult to achieve data consistency, even 80 to 20% can be achieved where the database is attached. But when the orchestrator is used, with a design pattern of orchestrator, it will delegate the call from one service to another. In that particular thing, if there is any network failure or any failure other than the abrupt failure. So, data consistency can become certainly more difficult. So it's better to use Sagas patterns, because it has a separate conductor, a separate service. You can call that, whether the state of the data changes, and it just maintains the latest updated state and updates the database. If anything goes wrong, we can have a chance to roll back the transitions or process the transition as per our requirement.

Circuit breaker pattern is something which is of, which we call a callback mechanism or fallback mechanism. So, basically, it happens in our ecosystems, and it's hardly happened, but still, since it's an internal, these things since all the services are internal, the callback failure rate was very low. But still, in case of failure, we can just redirect to a separate web page where we can either tell the customer that there are some changes, there are some errors, or we can just notify them that they need to be updated. So, that's it from my overview of the circuit breaker pattern. The implementation of a circuit breaker pattern is like it will be up. In the core, there has to be a direct callback mechanism. And also in dependency, we should have the open Netflix dependencies over there, and you know, to validate the method. And also, to handle whether there's any failure in the call, it has to fall back to a certain fallback mechanism. Over there, we can redirect towards a dedicated web page or any other fallback mechanism.

So, basically, I have not used RabbitMQ. I've used Kafka for this. So if I receive data in Kafka, the item potency is handled based, implicitly via Spring Boot. And, also, if I want to handle the data consistency, item potency, I'll just make sure that whether incoming data is already present in DB or not. So if it is present, I won't update it. If it is not present, I'll end up purchasing the data.

I bet it's I'm not used. I have no idea about this particular issue.

So, basically, this seems to be a... So, basically, we should have a dedicated exception handler, exception controller. We have to first make sure what type of exception it is, whether it's a help-only exception. We have to handle it accordingly, and if there's any other type of exceptions, like a database is not present or data not found exceptions, or something like that, we have to first write a dedicated exception handler inside that exception controller, and annotate it with a dedicated exception class, okay. There is an exception handler something, and the class name, sorry, this thing, what type of exception it is, and what type of error message needs to be thrown, and how to fix this, like, whatever exception it has, what exceptions it has thrown, and apart from this, we should also print, what was our incoming ID. We have to log the incoming ID. We should log the error using log.error, not log.info, because it will delay the responses, because it will take, the execution time will increase. So, it's better to log.error inside the catch blocks, because we require, whenever we require, we need to see the data, whatever data, the incoming data it was, and also we have to log the message, why it is, why the exception has occurred.

It's a singleton design pattern. So, basically, the purpose of this design pattern is to create a single object across the application. Okay. So, the update may not be shared with any other threads. It has to be shared only once, only once in a life cycle. So that's it. But the object will be created by only one thread in the life cycle. So that is the thing.

First of all, we need to go through what type of application it is, whether it depends on what type of application, whether it's an event driver or something like an execution-type application. If we import it will give the output, and then the output goes into the processor. What type of application that is, we need to go through it first, and integration means what exactly the integration process goes on, whether the monolithic application needs to use Kafka or many message brokers or any other microservices patents need to be implemented. So, we need to first analyze it properly. Apart from that, we should also identify if we are trying to break the monolithic, we should identify the separation of concerns. Separation of concerns means where the state gets changed, where the data gets persisted, or where the flow is. For example, in a suppose e-commerce application, designed in a monolithic architecture, we should ensure what is in the cart, then ensure whether the payment is done. We should also ensure whether the products are in the inventory or not before the payment is done. We have to make a separation clear about the separation of concerns. We should also be able to analyze how much user traffic there would be and whether any load balancers are to be used. We have to ensure that particular part. Apart from that, whether any database changes need to be done, we should also make sure whether we have to convert it to MySQL or NoSQL, depending on the requirement or the type of application we should do. We should also do the caching if any is required to implement.

I'm not a frontend guy, so I have no idea about it.