12/19/2023 0 Comments Jms message queue![]() ![]() You can find a sample project with a front-end and backend application connected to JSM at learnk8s/spring-boot-k8s-hpa. The backend is a worker consuming messages from a queue.Īnd since Spring Boot has excellent integration with JSM, you could use that to send and receive asynchronous messages. The front-end is a simple Spring Boot web app with the Thymeleaf templating engine. The service has three components: the front-end, the backend, and a message broker. How do you design a service that can handle hundreds of thousands of requests? And how do you deploy an application that scales dynamically?īefore diving into the details of deployment and scaling, let’s focus on the application. Great, but how do you build such application? you could have hundreds of front-end services and a single instance of the backend you can scale the backend independently of the front-end - i.e.if the front-end is producing more messages than what the backend can handle, those messages are buffered in the queue.if the backend is unavailable, the queue acts as a buffer.The new architecture has some obvious benefits: The front-end posts messages to the queue, while the backend processes the pending messages one at the time. You could redesign your architecture to decouple the front-end and the backend with a queue. if the backend is unavailable, you can’t process incoming transactions.the front-end and backend have to scale in concert - if there aren’t enough backends, you could drown in traffic.the front-end and the backend are tightly coupled - in fact it can’t process applications without the backend.Your application is not designed to be robust and highly available: You just lost a ton of money, and your customers are unhappy. Your backend can’t cope with it, and it drops plenty of connections. Angry customers get in touch with your customer service. Some of the services start dropping connections. You’re receiving even more traffic, and the backend can’t cope with it. No worries, you can scale the number of replicas to 8 for the backend. But you notice that the backend that is connected to the database is struggling to keep up with the number of transactions. The front-end services are handling the traffic fine. You start receiving more and more traffic. You decide to scale the application to four instances for the front-end and four instances for the backend, because you predict that the website to be busier than usual. Today turned out to be the big day, and your store goes live. You want the two components to be separated, because with the same REST API you could serve the website and mobile apps. ![]() You also build a backend REST API to process the incoming requests. You build a microservice to render the web pages and serve the static assets. You’re building a store where users can buy their favourite items. Now imagine you’re tasked with the challenge of building such application. ![]() ![]() If you were to picture the Apple store’s traffic as requests per second over time, this is what the graph could look like: That’s millions of people all buying an item at the same time. You should design your service so that even if it is subject to intermittent heavy loads, it continues to operate reliably.Įvery year millions of Apple customers preregister to buy a new iPhone. When you design and build applications at scale, you deal with two significant challenges: scalability and robustness. By Daniele Polencic How to scale Microservices with Message Queues, Spring Boot, and Kubernetes ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |