1
00:00:00,610 --> 00:00:07,720
In this video, we are going to see Solis pattern, which is the topic changing load balancing pattern

2
00:00:07,720 --> 00:00:09,750
with using Amazon SCS.

3
00:00:11,400 --> 00:00:17,700
So we can use a Q that acts as a buffer between the service from which it was called from the asynchronous

4
00:00:17,700 --> 00:00:18,660
invocations.

5
00:00:19,260 --> 00:00:24,900
By this way, we can avoid lost data if the service to fail or the task is timeout.

6
00:00:25,630 --> 00:00:31,120
This can help minimize the impact of peaks in demand on availability and responsiveness for the Consumer

7
00:00:31,120 --> 00:00:32,050
Micro Service.

8
00:00:33,530 --> 00:00:37,460
If you look at the subscribe button, you can see the image on the slide.

9
00:00:37,490 --> 00:00:43,040
There are three subscribers bacon service on the right hand side, interested in getting notified from

10
00:00:43,040 --> 00:00:44,660
the publisher microservices.

11
00:00:45,540 --> 00:00:52,740
So if one of these services can be done or getting exemption or taken offline for maintenance, then

12
00:00:52,740 --> 00:00:59,370
the event will be losses disappeared and cannot process after the subscriber service is up and running.

13
00:01:00,000 --> 00:01:04,080
Because publish your service, publish message with fire and forget method.

14
00:01:04,110 --> 00:01:08,640
Don't aware of which service consume this event and how to process them.

15
00:01:10,030 --> 00:01:16,120
So if you subscribe from any formal service like microservices or lambda functions, those services

16
00:01:16,120 --> 00:01:21,310
can potentially lose or miss topic messages from coming from the event pass.

17
00:01:22,230 --> 00:01:28,250
So in this phase, a good pattern to apply here, which is the topic queue chaining.

18
00:01:29,040 --> 00:01:31,660
So that means you add a queue.

19
00:01:31,680 --> 00:01:38,850
In our case, an Amazon queue between the Amazon event page and each of the subscriber services.

20
00:01:39,640 --> 00:01:47,050
In our soulless microservice architecture, we put Amazon between advantage and organic microservices

21
00:01:47,050 --> 00:01:52,720
because check out basket event published from the basket microservices and it is subscribed from the

22
00:01:52,720 --> 00:01:54,100
organic microservices.

23
00:01:55,760 --> 00:02:02,120
So if you stored this event message into Amazon asks to be durable and persistent manner, no message

24
00:02:02,120 --> 00:02:09,260
will get lost should the subscriber process run into problems for many days or exceptions happen.

25
00:02:10,260 --> 00:02:17,250
But there is more advantage to put Amazon in front of the subscriber services with putting Amazon skew

26
00:02:17,250 --> 00:02:19,640
in front of the subscriber microservices.

27
00:02:19,650 --> 00:02:25,110
We can take advantage of the fact that a queue can act as a buffering load balancer.

28
00:02:26,090 --> 00:02:33,140
Due to nature of each cue message being potentially delivered to one of many consumer processes, you

29
00:02:33,140 --> 00:02:38,540
can easily expand your subscriber services and the message load will be distributed over the existing

30
00:02:38,540 --> 00:02:39,770
consumer processes.

31
00:02:41,090 --> 00:02:44,300
Also, due to message are saved in the queue.

32
00:02:44,330 --> 00:02:47,600
A scaling event won't cause you to lose messages.

33
00:02:47,600 --> 00:02:53,330
For example, if you need to wait until an additional consumer operation, it becomes operational.

34
00:02:54,800 --> 00:03:00,350
So we will use Amazon's case for decoupling microservices and processing events asynchronously using

35
00:03:00,350 --> 00:03:00,920
to queues.