diff --git a/README.md b/README.md
index 3d831d7..2a2796c 100644
--- a/README.md
+++ b/README.md
@@ -1,2 +1,7 @@
 # Dev-Journal
 This repository is essentially a conversation with myself where I am listing the topics that I want to lean and understand. Over the period of time I want to write my notes in comments and increase the knowledge bank.
+
+## Topics Covered
+
+### System Design & Reliability
+- [Handling Downstream System Failures](./downstream-failure-handling.md) - Comprehensive guide on handling failures when downstream systems are unavailable
diff --git a/downstream-failure-handling.md b/downstream-failure-handling.md
new file mode 100644
index 0000000..5b6ede4
--- /dev/null
+++ b/downstream-failure-handling.md
@@ -0,0 +1,158 @@
+# Handling Downstream System Failures
+
+## Question: How do you handle the failure when downstream system is down?
+
+This is a critical aspect of building resilient distributed systems. When a downstream service is unavailable, your system needs to handle the failure gracefully to maintain overall system stability and user experience.
+
+## Key Strategies and Patterns
+
+### 1. Circuit Breaker Pattern
+The circuit breaker pattern prevents cascading failures by stopping requests to a failing service.
+
+**States:**
+- **Closed**: Normal operation, requests pass through
+- **Open**: Service is failing, requests are immediately rejected
+- **Half-Open**: Testing if service has recovered
+
+**Benefits:**
+- Prevents resource exhaustion
+- Fails fast instead of waiting for timeouts
+- Allows system to recover
+
+### 2. Retry Mechanisms
+Implement intelligent retry logic for transient failures.
+
+**Best Practices:**
+- Use exponential backoff with jitter
+- Set maximum retry attempts
+- Distinguish between retryable and non-retryable errors
+- Implement retry budgets to prevent retry storms
+
+**Example Strategy:**
+```
+Initial delay: 100ms
+Max retries: 3
+Backoff multiplier: 2
+Max delay: 5s
+```
+
+### 3. Timeout Handling
+Set appropriate timeouts to prevent hanging requests.
+
+**Timeout Types:**
+- **Connection timeout**: Time to establish connection
+- **Read timeout**: Time to receive response
+- **Overall timeout**: Total time for entire operation
+
+### 4. Graceful Degradation
+Provide reduced functionality when downstream services are unavailable.
+
+**Approaches:**
+- Serve cached data
+- Provide default values
+- Skip non-essential features
+- Show user-friendly error messages
+
+### 5. Fallback Mechanisms
+Implement alternative paths when primary service fails.
+
+**Fallback Options:**
+- Secondary service instances
+- Cached responses
+- Static default responses
+- Alternative service providers
+
+### 6. Bulkhead Isolation
+Isolate critical resources to prevent failure propagation.
+
+**Implementation:**
+- Separate thread pools for different services
+- Resource quotas per downstream service
+- Independent connection pools
+
+### 7. Asynchronous Processing
+Use queues and async patterns to handle downstream failures.
+
+**Benefits:**
+- Decouple request processing from downstream availability
+- Enable retry logic at queue level
+- Maintain system responsiveness
+
+## Monitoring and Observability
+
+### Key Metrics to Track
+- **Error rates**: Track 4xx and 5xx responses
+- **Latency**: Monitor response times and percentiles
+- **Availability**: Measure uptime and downtime
+- **Circuit breaker state**: Monitor open/closed states
+- **Retry attempts**: Track retry patterns and success rates
+
+### Alerting Strategy
+- Set up alerts for error rate thresholds
+- Monitor circuit breaker trips
+- Alert on timeout increases
+- Track downstream service health
+
+## Implementation Considerations
+
+### Configuration Management
+- Make timeouts and retry policies configurable
+- Allow runtime adjustment of circuit breaker thresholds
+- Enable/disable features based on downstream health
+
+### Testing Strategies
+- **Chaos engineering**: Intentionally introduce failures
+- **Load testing**: Test behavior under stress
+- **Failure injection**: Simulate downstream failures
+- **Recovery testing**: Verify system recovery after failures
+
+### Documentation and Runbooks
+- Document failure scenarios and responses
+- Create runbooks for common issues
+- Maintain service dependency maps
+- Document rollback procedures
+
+## Example Architecture Pattern
+
+```
+Client Request
+    ↓
+Load Balancer
+    ↓
+API Gateway (with circuit breaker)
+    ↓
+Service A (with retry logic)
+    ↓
+Circuit Breaker → Downstream Service B
+    ↓               ↓
+Fallback Cache ← Success/Failure
+```
+
+## Best Practices Summary
+
+1. **Fail Fast**: Don't wait indefinitely for failing services
+2. **Degrade Gracefully**: Provide reduced functionality rather than complete failure
+3. **Monitor Everything**: Track metrics to understand system behavior
+4. **Test Failures**: Regularly test failure scenarios
+5. **Plan Recovery**: Have clear procedures for service recovery
+6. **Communicate**: Provide clear error messages to users
+7. **Learn and Improve**: Conduct post-mortems and improve resilience
+
+## Tools and Libraries
+
+### Popular Circuit Breaker Implementations
+- **Netflix Hystrix** (Java)
+- **Resilience4j** (Java)
+- **Polly** (.NET)
+- **PyBreaker** (Python)
+- **Opossum** (Node.js)
+
+### Monitoring Tools
+- Prometheus + Grafana
+- New Relic
+- DataDog
+- Application Performance Monitoring (APM) tools
+
+---
+
+*Note: The specific implementation details will vary based on your technology stack, but these patterns and principles apply universally across different platforms and languages.*
\ No newline at end of file