In our last article about Microprofile Fault Tolerance we explained the motivation for this project and the need to provide a few design patterns under the microservice friendly Microprofile spec, namely:

• Bulkhead – isolate failures in part of the system.
• Circuit breaker – offer a way to fail fast.
• Retry – define criteria on when to retry.
• Fallback – provide an alternative solution for a failed execution.

Read the rest at Tomitribe’s blog.

Understanding Fault Tolerance and the strategies of resilience and eventual consistency are extremely important to microservices. This article an update and expansion of an article written in April of this year. It’s the first part in a series of articles explaining how the MicroProfile Fault Tolerance specification is used in microservices.

Read the rest at Tomitribe’s blog.

With the rise of microservices or large scale distributed systems and communicating through HTTP and NoSql databases, we also see the rise of eventual consistency. The focus on reliability or the perfect operation at all times had to shift to resilience; the ability of an application to recover from certain types of failure and yet remain functional. All-or-nothing and reliable transactions were paramount, data had to be safely stored above all, sacrificing the user experience and cost. The objects on those transactions could also be very complex, frequently using multiple tables and even different databases. Typically, if a transaction failed, the user would receive an error requiring his action; usually to resubmit the request or contact support. To keep response times low, vertical scaling with costly “big iron” was common.

Read the rest on Tomitribe’s blog.