BlackFriday 2024! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions

Salesforce Exam MuleSoft Platform Architect I Topic 1 Question 4 Discussion

Actual exam question for Salesforce's MuleSoft Platform Architect I exam
Question #: 4
Topic #: 1
[All MuleSoft Platform Architect I Questions]

A system API is deployed to a primary environment as well as to a disaster recovery (DR) environment, with different DNS names in each environment. A process API is a client to the system API and is being rate limited by the system API, with different limits in each of the environments. The system API's DR environment provides only 20% of the rate limiting offered by the primary environment. What is the best API fault-tolerant invocation strategy to reduce overall errors in the process API, given these conditions and constraints?

Show Suggested Answer Hide Answer
Suggested Answer: A

Correct Answer : Invoke the system API deployed to the primary environment; add timeout and retry logic to the process API to avoid intermittent failures; if it still fails, invoke the system API deployed to the DR environment

*****************************************

There is one important consideration to be noted in the question which is - System API in DR environment provides only 20% of the rate limiting offered by the primary environment. So, comparitively, very less calls will be allowed into the DR environment API opposed to its primary environment. With this in mind, lets analyse what is the right and best fault-tolerant invocation strategy.

1. Invoking both the system APIs in parallel is definitely NOT a feasible approach because of the 20% limitation we have on DR environment. Calling in parallel every time would easily and quickly exhaust the rate limits on DR environment and may not give chance to genuine intermittent error scenarios to let in during the time of need.

2. Another option given is suggesting to add timeout and retry logic to process API while invoking primary environment's system API. This is good so far. However, when all retries failed, the option is suggesting to invoke the copy of process API on DR environment which is not right or recommended. Only system API is the one to be considered for fallback and not the whole process API. Process APIs usually have lot of heavy orchestration calling many other APIs which we do not want to repeat again by calling DR's process API. So this option is NOT right.

3. One more option given is suggesting to add the retry (no timeout) logic to process API to directly retry on DR environment's system API instead of retrying the primary environment system API first. This is not at all a proper fallback. A proper fallback should occur only after all retries are performed and exhausted on Primary environment first. But here, the option is suggesting to directly retry fallback API on first failure itself without trying main API. So, this option is NOT right too.

This leaves us one option which is right and best fit.

- Invoke the system API deployed to the primary environment

- Add Timeout and Retry logic on it in process API

- If it fails even after all retries, then invoke the system API deployed to the DR environment.


Contribute your Thoughts:

Truman
5 months ago
Option D is the most interesting to me. Deploying a copy of the process API to the DR environment is a creative solution that could work well in this scenario.
upvoted 0 times
Jovita
5 months ago
I agree, Option A sounds like a solid strategy. It's important to handle intermittent failures gracefully to reduce overall errors in the process API.
upvoted 0 times
...
Rodrigo
5 months ago
I think Option A could also be effective. Adding timeout and retry logic to the process API when invoking the system API deployed to the primary environment seems like a good approach.
upvoted 0 times
...
Joni
5 months ago
Option D is the most interesting to me. Deploying a copy of the process API to the DR environment is a creative solution that could work well in this scenario.
upvoted 0 times
...
...
Alise
6 months ago
Haha, this reminds me of that time I accidentally deployed my API to the wrong environment and had to figure out why my rate limits were so low. Option C is definitely the way to go here.
upvoted 0 times
Ashlyn
4 months ago
Yeah, invoking both environments in parallel with retry logic sounds like a solid plan.
upvoted 0 times
...
Deonna
4 months ago
Haha, I've been there before too. Option C seems like the best choice.
upvoted 0 times
...
Mitsue
5 months ago
Yeah, invoking both environments in parallel with retry logic sounds like a solid plan.
upvoted 0 times
...
Lanie
5 months ago
Haha, I've been there before too. Option C seems like the best choice.
upvoted 0 times
...
...
Skye
6 months ago
I disagree, I think option A is better. Trying the primary environment first and only falling back to the DR environment if necessary is a more efficient approach than always invoking both in parallel.
upvoted 0 times
Brigette
5 months ago
I agree, it's more efficient to try the primary environment before the DR environment.
upvoted 0 times
...
Oliva
5 months ago
Option A is better because it prioritizes the primary environment first.
upvoted 0 times
...
...
Yolando
6 months ago
Option C seems like the best approach here. Invoking both the primary and DR environments in parallel, with timeout and retry logic, will provide the most fault-tolerant solution given the differences in rate limiting between the two environments.
upvoted 0 times
German
5 months ago
Yeah, I agree. It's important to have a strategy that can handle the differences in rate limiting between the environments.
upvoted 0 times
...
Georgiann
5 months ago
I think option C is the way to go. It covers all the bases with parallel invocation and retry logic.
upvoted 0 times
...
...

Save Cancel