Micro-Services Design Patterns

24.SCHEDULER AGENT SUPERVISOR المراجع الدوري

Coordinate a set of actions across a distributed set of services and other remote resources, attempt to transparently handle faults if any of these actions fail, or undo the effects of the work performed if the system cannot recover from a fault.

This pattern can add resiliency to a distributed system by enabling it to recover and retry actions that fail due to transient exceptions, long-lasting faults, and process failures.

Sample of the Scheduler reviews:

• Transactions to be compensated: since you make rules for the delay, and you customer can't wait, also if some transaction s failed, and you need to discover it.

• Data governance: Some times, your data model violate the data governance rules, like zero and null values, invalid references, wrong data entry.

• Periodic checks upon absence of EDA, mainly with third parties integration, so you should incrementally check the expected responses to complete scenarios, and update data models.

How Can We implement it:

1. Application schedule

2. DB Jobs

The opposite graph show the four pillar resiliency and stability patterns, that should be applied to improve the solution stability:

• Retry Pattern: the existing pattern, how may times to try the same behavior, to prevent failure

• Circuit Breaker: how to stop the unlimited trials for the same requests/jobs to prevent stuck and locks.

• Scheduler Job: to compensate failed, and incomplete transactions due to the retry failure and circuit breaker

• Leader election: at infrastructure level

Collaboration between all mentioned design patterns should take place, specially at the large scale solution.

25. Periority Queue

Prioritize requests sent to services so that requests with a higher priority are received and processed more quickly than those of a lower priority. This pattern is useful in applications that offer different service level guarantees to individual types of client.

Applications can delegate specific tasks to other services, for example, to perform background processing or to integrate with other applications or services. In the cloud, a message queue is typically used to delegate tasks to background processing. In many cases, the order requests are received in by a service isn't important. In some cases, though, it's necessary to prioritize specific requests. These requests should be processed earlier than lower priority requests that were sent previously by the application.

A queue is usually a first-in, first-out (FIFO) structure, and consumers typically receive messages in the same order that they were posted to the queue. However, some message queues support priority messaging. The application posting a message can assign a priority and the messages in the queue are automatically reordered so that those with a higher priority will be received before those with a lower priority. The figure illustrates a queue with priority messaging.

As We see in the opposite image, the solution is to use the reorder pattern, to move according to the priority, so till having the higher priority, We should pay attention till end, Which is applicable is cases like the OTP authentication, which should be expired as example 2 minutes, or in money transfer, like 30 Seconds.

How to implement it?

In systems that don't support priority-based message queues, an alternative solution is to maintain a separate queue for each priority. The application is responsible for posting messages to the appropriate queue. Each queue can have a separate pool of consumers. Higher priority queues can have a larger pool of consumers that run on faster hardware than lower priority queues. 

You can do the following;

1. Create application jobs (Platinum jobs) with lower intervals and large data sets for executing high priority tasks, as example (each 10 seconds, take 1000 records)

2. Create application jobs (Gold jobs) with lower intervals and large data sets for executing high priority tasks, as example (each 30 seconds, take 30 records)

3. Create application jobs (Silver jobs) with lower intervals and large data sets for executing high priority tasks, as example (each 50 seconds, take 20 records)

Another approach with Kafka

1. Create multiple partitions for Kafka topic according to topic importance

2. Partitions enable parallelism, which enable multiple agents for increasing the performance

Using a priority-queuing mechanism can provide the following advantages:

• It allows applications to meet business requirements that require the prioritization of availability or performance, such as offering different levels of service to different groups of customers.

• It can help to minimize operational costs. If you use the single-queue approach, you can scale back the number of consumers if you need to. High priority messages are still processed first (although possibly more slowly), and lower priority messages might be delayed for longer. If you implement the multiple message queue approach with separate pools of consumers for each queue, you can reduce the pool of consumers for lower priority queues. You can even suspend processing for some very low priority queues by stopping all the consumers that listen for messages on those queues.

• The multiple message queue approach can help maximize application performance and scalability by partitioning messages based on processing requirements. For example, you can prioritize critical tasks so that they're handled by receivers that run immediately, and less important background tasks can be handled by receivers that are scheduled to run at times that are less busy.

When to use this pattern?

This pattern is useful in scenarios where:

• The system must handle multiple tasks that have different priorities, like OTP, and VIP customers

• Different users or tenants should be served with different priorities.