Mo Nuaimat

On October 20, AWS went down. But this isn't just another tech story. It's a reminder that every operation — from factory floors to control rooms — relies on backbones that can quietly fail. When one link breaks, everything that depends on it slows, stops, or scrambles. Sometimes it’s a server. Sometimes it’s a supplier. Sometimes it’s the one person who knows how the system actually works. This week’s post isn’t about the cloud. It’s about fragility — and the invisible dependencies that make or break performance when pressure hits. 👇 Swipe to see how one outage mirrors every kind of ops failure.

5

Boom! This is the second big launch of the year…. Amazon MQ just shipped another important upgrade for RabbitMQ customers: support for certificate-based authentication with mutual TLS (mTLS) using X.509 client certificates on RabbitMQ 4.2 brokers. For teams standardizing on zero-trust patterns and strong workload identity, this is a big step forward. With the RabbitMQ `auth_mechanism_ssl` plugin now available on Amazon MQ RabbitMQ 4.2 and above, you can have the broker authenticate who can log in using client certificates instead of (or in addition to) traditional username/password credentials. https://lnkd.in/ggdARABD #MessageBrokers #RabbitMQ #AmazonMQ #AWS

63

2 Comments

HTTP 202 Accepted✂️ Your API doesn't have to be as slow as your dependencies The Problem: Your API needs to call a downstream service that takes 2-10 seconds to respond. Could be payment processing, document generation, third-party data enrichment, or ML model inference. The Synchronous API (what everyone builds): POST /process • Save initial state to database • Call downstream service (wait 2-5 seconds) • Update database with result • Return 200 OK with result What just broke: • Downstream timeout → User waits 30 seconds, sees error • Downstream degraded → Your P99 latency goes from 100ms to 8 seconds • Downstream down → Your entire feature is down • 100 concurrent requests → 100 API workers blocked for 5 seconds each Your monitoring says "API healthy" but users are rage-clicking refresh buttons. ━━━━━━━━━━━━━━━━━━━━ The 202 Accepted Pattern: POST /process • Save job request to database with status = QUEUED • Queue job_id for background processing • Return 202 Accepted with job_id and status_url • Response time: 10-20ms GET /jobs/{job_id} • Return current status: QUEUED, PROCESSING, COMPLETED, FAILED • Return result when completed Background Worker: • Picks up job from queue • Updates status to PROCESSING • Calls downstream service with retries • Updates status to COMPLETED or FAILED • Saves result ━━━━━━━━━━━━━━━━━━━━ What You Just Gained: Decoupled Reliability: Downstream service down? Your API keeps accepting requests. Jobs process when service recovers. Users never see 503 errors. Predictable Latency: • Synchronous: P99 = 8 seconds (users waiting, timing out) • 202 pattern: P99 = 30-50ms (users see "Processing...") Better Resource Utilization: • Synchronous: 100 requests = 100 blocked workers for 5 seconds = 500 worker-seconds • 202 pattern: 100 requests = 1 worker-second + 10 background workers processing queue Your API capacity is independent of downstream latency. Graceful Degradation: Downstream slow? Queue builds up, but API stays responsive. Show users: "5 jobs ahead, estimated 30 seconds." Better than timeouts. Built-in Retries: Background job fails? Retry with exponential backoff. Synchronous fails? User manually retries. ━━━━━━━━━━━━━━━━━━━━ When to Use 202: ✓ Operations taking more than 2 seconds ✓ Dependent on external services ✓ Downstream reliability poor When NOT to Use: ✗ Sub-second operations ✗ Internal admin tools with low traffic ✗ Synchronous failure is acceptable ━━━━━━━━━━━━━━━━━━━━ Real-World Examples: - Stripe Payouts API - GitHub Merges API - Twilio Message Status - AWS Batch Operations ━━━━━━━━━━━━━━━━━━━━ The Bottom Line: Fast APIs don't wait for slow services. They accept work, return immediately, process asynchronously. Synchronous is simpler to build. Asynchronous is reliable at scale. Above 50 req/sec with external dependencies taking more than 2 seconds, HTTP 202 isn't optional—it's survival. #APIDesign #DistributedSystems #BackendEngineering #SoftwareArchitecture

28