Durgesh Tiwari
Author
Modern applications communicate with many services, such as databases, payment gateways, notification services, and third-party APIs. Sometimes these services become slow, unavailable, or fail because of network problems or temporary server issues.
If these failures are not handled properly, they can slow down the application or even stop some features from working.
To solve this problem, developers use Reliability Patterns.
Reliability Patterns are design techniques that help applications handle failures in a smart way. They keep the application running, reduce downtime, and prevent one failed service from affecting the entire system.
In simple words, Reliability Patterns help an application continue working even when one of its services becomes slow or unavailable.
These patterns are widely used in microservices, cloud applications, and distributed systems to build reliable and fault-tolerant applications.
In a distributed system, one request often depends on multiple services working together. If one service fails, the application should still continue working as much as possible instead of stopping completely.
Reliability Patterns help developers:
Handle temporary service failures.
Reduce application downtime.
Improve system stability.
Prevent failures from spreading to other services.
Keep important features available.
Provide a better user experience.
Imagine an e-commerce website that uses an online payment service.
If the payment service becomes temporarily unavailable, the application does not immediately display an error page. Instead, it can retry the request, stop sending repeated requests for a short time, or show a friendly message asking the customer to try again later.
This helps the application continue working smoothly and prevents a single failed service from affecting the entire system.
In a distributed system, a request may fail because of a temporary problem such as a network issue, server overload, or a short service outage. In many cases, the service becomes available again after a few seconds.
The Retry Pattern automatically sends the failed request again after a short delay instead of returning an error immediately.
In simple words, the Retry Pattern automatically tries the same request again when a temporary failure occurs.
The Retry Pattern follows these simple steps:
The application sends a request.
If the request is successful, the process ends.
If the request fails because of a temporary issue, the application waits for a short time.
The application sends the same request again.
If the request still fails after the maximum number of retries, an error is returned.
Imagine a customer making a payment on an e-commerce website.
The payment request fails because of a temporary network problem. Instead of showing an error immediately, the application waits for a few seconds and retries the request.
If the next attempt is successful, the payment is completed without asking the customer to try again.
The Retry Pattern provides several benefits:
Handles Temporary Failures – Recovers from short-term network or service issues.
Improves Success Rate – Many temporary failures are fixed automatically after a retry.
Reduces Manual Effort – Users do not need to repeat the same action.
Provides a Better User Experience – Temporary problems are handled without interrupting the user.
Follow these best practices when using the Retry Pattern:
Retry Only Temporary Failures – Do not retry permanent errors.
Add a Delay Between Retries – Avoid sending requests continuously.
Limit Retry Attempts – Stop retrying after a fixed number of attempts.
Use Exponential Backoff – Increase the waiting time after each retry to reduce server load.
In a distributed system, an application often depends on services such as payment gateways, databases, or third-party APIs. If one of these services keeps failing, sending more requests only wastes resources and can make the problem even worse.
The Circuit Breaker Pattern solves this problem by temporarily stopping requests to the failed service. After waiting for a short time, it checks whether the service has recovered. If the service is working again, normal communication starts automatically.
In simple words, the Circuit Breaker Pattern stops sending requests to a failed service until it becomes available again.
The process is simple:
The application sends requests to a service.
If the service fails repeatedly, the circuit opens.
While the circuit is open, new requests are blocked for a short time.
After the waiting period, the application sends a test request.
If the service responds successfully, the circuit closes and normal requests continue. If the service still fails, the circuit stays open.
Imagine an e-commerce website that uses an online payment gateway.
If the payment service becomes unavailable, the application does not continue sending thousands of failed payment requests. Instead, it temporarily blocks new requests and waits for the service to recover.
Once the payment service starts working again, the application automatically resumes normal communication.
The Circuit Breaker Pattern offers several benefits:
Prevents Repeated Failures – Stops sending requests to a service that is already failing.
Protects System Resources – Reduces unnecessary network traffic and server load.
Improves Application Stability – Prevents one failed service from affecting other parts of the application.
Stops Failure from Spreading – Allows healthy services to continue working normally.
A Circuit Breaker works in three states to control how requests are sent to a service. These states help prevent repeated failures and allow the service enough time to recover before accepting new requests.
The three states are:
Closed State
Open State
Half-Open State
The Closed State is the normal working state of the circuit breaker.
In this state, all requests are sent to the service. If the service responds successfully, the circuit remains closed.
If the number of failures reaches a predefined limit, the circuit changes to the Open State.
Example
An online payment service is working normally, so every payment request is processed successfully. The circuit breaker stays in the Closed State.
The Open State starts when the service fails repeatedly.
Instead of sending more requests to the failed service, the circuit breaker blocks all new requests for a fixed period. This gives the service enough time to recover and prevents unnecessary load.
Example
A payment gateway becomes unavailable. After several failed payment requests, the circuit breaker moves to the Open State and immediately blocks new requests.
After the waiting period ends, the circuit breaker moves to the Half-Open State.
In this state, only a few test requests are sent to check whether the service has recovered.
If the test requests are successful, the circuit returns to the Closed State.
If the test requests fail again, the circuit goes back to the Open State.
This prevents all traffic from reaching a service that is still unavailable.
Example
The payment service starts responding again. The circuit breaker sends a few test requests. If they succeed, normal requests continue. If they fail, the circuit blocks requests again.
Success
▲
│
+---------------+
| Closed |
+---------------+
│
Too Many Failures
▼
+---------------+
| Open |
+---------------+
│
Wait for Timeout
▼
+---------------+
| Half-Open |
+---------------+
│ │
Success Failure
│ │
▼ ▼
Closed OpenIn a distributed system, an application often communicates with services such as a database, payment gateway, or third-party API. Sometimes these services become slow or stop responding. If the application keeps waiting, it can slow down other requests and affect the overall performance.
The Timeout Pattern solves this problem by setting a maximum waiting time for every request. If the service does not respond within that time, the request is cancelled and the application can return an error or use another option.
In simple words, the Timeout Pattern stops waiting for a slow service after a fixed amount of time.
The process is simple:
The application sends a request to another service.
A timeout limit is set for the request.
If the service responds before the timeout, the request is completed successfully.
If the service does not respond within the time limit, the request is cancelled.
The application returns an error or uses an alternative response.
Imagine a weather application that gets live weather information from a third-party API.
If the API responds within 5 seconds, the latest weather information is shown to the user.
If the API does not respond within 5 seconds, the application cancels the request instead of waiting longer. It can then display an error message or show the most recently available weather data.
The Timeout Pattern provides several benefits:
Prevents Long Waiting Times – Stops requests that take too long to respond.
Improves Response Time – Keeps the application fast and responsive.
Frees System Resources – Avoids wasting memory and network connections.
Prevents Blocked Requests – Stops slow services from delaying other operations.
In a distributed system, multiple services work at the same time. If one service becomes slow or overloaded, it should not interrupt the other services.
The Bulkhead Pattern solves this problem by separating an application into independent sections. Each service uses its own resources, so a failure in one service does not affect the rest of the application.
In simple words, the Bulkhead Pattern keeps one service failure from affecting the entire application.
The process is simple:
The application is divided into separate sections.
Each service gets its own resources, such as threads or connection pools.
If one service becomes overloaded or fails, only that section is affected.
The remaining services continue working normally.
Imagine an e-commerce application with separate resources for different services:
Product Search
Payment Service
Order Processing
If the Product Search service receives a large number of requests and becomes overloaded, customers can still make payments and place orders because those services use their own resources.
The Bulkhead Pattern provides several benefits:
Isolates Failures – A problem in one service does not affect other services.
Prevents System-Wide Outages – The rest of the application continues working during failures.
Improves Fault Tolerance – Services can continue running independently.
Keeps the Application Available – Important features remain accessible even if one service fails.
In a distributed system, a service may become unavailable because of a network issue, server failure, or temporary outage. Instead of showing an error to users, the application can return an alternative response so they can continue using the application.
The Fallback Pattern provides cached data, default values, or a backup response when the main service is unavailable.
In simple words, the Fallback Pattern returns an alternative response instead of an error when a service is unavailable.
The process is simple:
The application sends a request to a service.
If the service responds successfully, the latest data is returned.
If the service is unavailable, the application switches to a fallback response.
The user receives cached data, default information, or another available response instead of an error.
Imagine a news application that displays the latest headlines.
If the news service becomes temporarily unavailable, the application does not show an error page. Instead, it displays recently cached news articles until the service starts working again.
This allows users to continue reading the news without interruption.
The Fallback Pattern provides several benefits:
Improves User Experience – Users receive useful information instead of an error.
Reduces Service Interruptions – The application continues working during temporary failures.
Keeps the Application Usable – Important features remain available.
Supports Graceful Degradation – The application continues serving users with an alternative response.
Each Reliability Pattern is designed to handle a different type of failure in a distributed system. Choosing the right pattern depends on the problem your application needs to solve.
The failure is temporary.
Network issues happen occasionally.
The request is likely to succeed after another attempt.
Examples:
Payment requests
API calls
Database connections
A service fails repeatedly.
Repeated requests would increase the load.
You want to protect other services from failures.
Examples:
Payment gateways
Third-party APIs
Microservices
A service takes too long to respond.
Fast response times are important.
Long waiting times should be avoided.
Examples:
Weather APIs
Currency exchange services
Authentication services
Services should work independently.
A failure in one service should not affect other services.
Critical services need separate resources.
Examples:
Banking applications
E-commerce platforms
Video streaming services
A backup response is available.
Cached data can be shown temporarily.
The application should continue working even if a service is unavailable.
Examples:
News websites
Product catalog pages
Weather applications
Reliability Pattern | Purpose | Best Use Case |
|---|---|---|
Retry Pattern | Automatically retries a request after a temporary failure. | Network issues, API calls, database connections |
Circuit Breaker Pattern | Stops sending requests to a service that is repeatedly failing. | Payment gateways, third-party APIs, microservices |
Timeout Pattern | Cancels a request if it takes too long to respond. | External APIs, authentication services, remote services |
Bulkhead Pattern | Isolates services so that a failure in one service does not affect others. | Large distributed systems, e-commerce platforms, banking applications |
Fallback Pattern | Returns cached data, default values, or a backup response when the main service is unavailable. | News websites, product catalogs, weather applications |
Imagine an e-commerce application that receives thousands of customer requests every minute.
When a customer makes a payment, the application first uses the Retry Pattern to recover from temporary network or service issues. If the payment service continues to fail, the Circuit Breaker Pattern temporarily stops sending new requests until the service becomes available again.
To avoid long waiting times, the Timeout Pattern cancels the payment request if the service does not respond within the configured time limit. At the same time, the Bulkhead Pattern keeps the payment service separate from features like product search and order tracking, so a problem in one service does not interrupt the others.
If the Product Recommendation Service is unavailable, the Fallback Pattern displays popular or recently viewed products from the cache instead of showing an error.
By using these Reliability Patterns, the application can handle temporary failures, keep important features available, and provide a smooth shopping experience even when some services are facing issues.
Reliability Patterns help applications handle service failures without affecting the overall user experience. They reduce downtime, improve system stability, and keep important features available even when some services become slow or unavailable.
Retry Pattern retries requests that fail because of temporary issues.
Circuit Breaker Pattern stops sending requests to a service that is repeatedly failing until it recovers.
Timeout Pattern cancels requests that take longer than the allowed time to respond.
Bulkhead Pattern isolates services so that a failure in one service does not affect the rest of the application.
Fallback Pattern returns cached data, default values, or another backup response when the main service is unavailable.