New Year Sale 2026! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions

Salesforce Certified MuleSoft Platform Architect (Mule-Arch-201) Exam - Topic 1 Question 4 Discussion

Actual exam question for Salesforce's Salesforce Certified MuleSoft Platform Architect (Mule-Arch-201) exam
Question #: 4
Topic #: 1
[All Salesforce Certified MuleSoft Platform Architect (Mule-Arch-201) 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:

0/2000 characters
Truman
3 months ago
D seems risky, what if the DR process API is down too?
upvoted 0 times
...
Renato
3 months ago
Totally agree with A, timeout and retry are key!
upvoted 0 times
...
Jackie
3 months ago
Wait, why would you even use the DR API if it has lower limits?
upvoted 0 times
...
Lynna
4 months ago
I think C could work too, but it sounds complicated.
upvoted 0 times
...
Leonora
4 months ago
A is the best choice, primary first!
upvoted 0 times
...
Thurman
4 months ago
I vaguely recall that adding retry logic is crucial, but I’m not clear on whether we should always fall back to the DR environment or if there’s a better strategy.
upvoted 0 times
...
Florinda
4 months ago
I feel like we had a question similar to this where we focused on timeout strategies. I’m leaning towards option A, but I’m unsure if the DR environment's lower rate limit would be effective.
upvoted 0 times
...
Nadine
4 months ago
I think option C sounds familiar; invoking both environments in parallel could help balance the load, but I'm not entirely confident about how to handle the combined results.
upvoted 0 times
...
Stephaine
5 months ago
I remember we discussed the importance of retry logic in our last practice session, but I'm not sure if invoking the DR environment after a failure is the best approach.
upvoted 0 times
...
Joanna
5 months ago
This is a great question that really tests our ability to apply fault tolerance principles. I'll need to make sure I fully understand the constraints before deciding on the best strategy.
upvoted 0 times
...
Jess
5 months ago
I'm feeling pretty confident about this one. The question is clearly testing our understanding of fault-tolerant API invocation strategies. I'll carefully evaluate each option and select the best approach.
upvoted 0 times
...
Zoila
5 months ago
Okay, I think I've got a good handle on this. The key is to leverage both the primary and DR environments, with appropriate retry and timeout logic to handle intermittent failures.
upvoted 0 times
...
Alayna
5 months ago
Hmm, I'm a bit confused by the different rate limiting values between the primary and DR environments. I'll need to think through how that impacts the fault tolerance strategy.
upvoted 0 times
...
Latosha
5 months ago
This looks like a tricky question. I'll need to carefully consider the different rate limiting constraints and fault tolerance strategies to come up with the best approach.
upvoted 0 times
...
Leota
5 months ago
Based on the information provided, I'd recommend the Pay-As-You-Go with Savings Plan option. That way, the company can still get the flexibility they need while potentially saving some money on the short-term usage.
upvoted 0 times
...
Farrah
5 months ago
This question seems straightforward - it's asking about the key requirements for a successful business architecture effort. I'll carefully review each option and choose the one that best fits the description.
upvoted 0 times
...
Cristal
5 months ago
I feel like it's related to levels, since those are commonly referenced in models, but I can't quite place it.
upvoted 0 times
...
Lavelle
5 months ago
Yeah, I had a similar practice question that mentioned dfa-regtex. I'm uncertain if that also applies here though.
upvoted 0 times
...
Truman
2 years 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
2 years 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
2 years 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
2 years 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
2 years 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
2 years ago
Yeah, invoking both environments in parallel with retry logic sounds like a solid plan.
upvoted 0 times
...
Deonna
2 years ago
Haha, I've been there before too. Option C seems like the best choice.
upvoted 0 times
...
Mitsue
2 years ago
Yeah, invoking both environments in parallel with retry logic sounds like a solid plan.
upvoted 0 times
...
Lanie
2 years ago
Haha, I've been there before too. Option C seems like the best choice.
upvoted 0 times
...
...
Skye
2 years 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
2 years ago
I agree, it's more efficient to try the primary environment before the DR environment.
upvoted 0 times
...
Oliva
2 years ago
Option A is better because it prioritizes the primary environment first.
upvoted 0 times
...
...
Yolando
2 years 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
2 years 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
2 years 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