Comunicação Síncrona E Assíncrona

Patterns I actually use for communication síncrona e assíncrona

I spent years building backend systems where teams kept choosing synchronous calls for everything, and then complaining about cascading failures, high p99 latency, and on-call pages at 3 AM. The fix wasn't a framework swap. It was understanding when to push requests through queues and when to wait for an immediate response.

What everyone gets wrong about comunicação síncrona e assíncrona

Synchronous communication means the caller blocks until it gets a response. Asynchronous means the caller sends a message and continues without waiting. That's the definition, but it's also where most people stop and build the wrong thing. The real decision isn't "sync or async?" It's "does this call need a guaranteed response, and what happens to the caller's thread pool when that response takes 2 seconds instead of 200 milliseconds?" I learned this after a production incident where every endpoint in our API was a synchronous HTTP call chained together. A downstream dependency started returning 500s at 4x normal latency, and our connection pool exhausted in under three minutes. Twenty thousand requests piled up. The whole service became unreachable.

The workaround was to convert all read-heavy cross-service calls to fire-and-forget patterns using a Kafka topic with exactly-once delivery semantics, and move the critical write paths to a RabbitMQ setup with manual acknowledgment. Response times for batch endpoints dropped from an average of 1.8 seconds to around 200 milliseconds. P99 latency followed the same trajectory. Not zero, just manageable.

When to pick each pattern

Sync makes sense when you need immediate confirmation. Payment processing, user authentication, anything where the next step is invalid without the result. The overhead of queuing a message and handling callbacks is unnecessary if you're already waiting for that answer anyway. Async makes sense when the work is independent and the result can be processed later. Order status updates, analytics aggregation, notification dispatch. These operations don't block the user's request cycle. They can wait in a queue and be processed when capacity allows.

The edge case that trips people up is idempotency. When you switch from sync to async, you're no longer getting a clear success or failure in the same thread. If the message gets processed twice, you might create duplicate records, send double payments, or corrupt state. I solved this by implementing idempotency keys on every async producer. Each message carries a unique key derived from the request ID, and the consumer checks a Redis set with a 24-hour TTL before processing. This reduced duplicate writes from about 3% of all async operations to near zero.

Implementation patterns I rely on

The message-driven pattern is the most common async approach. You publish events to a broker and consumers process them independently. Apache Kafka handles high-throughput scenarios where you need retention and replayability. RabbitMQ works better for task distribution where you need complex routing and dead-letter handling. Polling is another option, though I use it less now. A service checks a database or API at intervals for new data. It's simple but wasteful. Under low load it barely matters, but at scale you're burning resources on requests that return nothing.

Webhooks represent the push side of async. Your service registers a callback URL, and the remote system notifies you when something happens. This is how Stripe handles payment confirmations and how GitHub triggers CI/CD pipelines. The risk is failed deliveries. If your endpoint goes down during a webhook burst, you lose events unless the provider supports retries with exponential backoff, which most do, but not all guarantee delivery order.

Common pitfalls

The biggest mistake I see is treating async as a silver bullet. Queue depth isn't free. Every message sitting in a broker consumes memory, and if your consumers can't keep up, latency compounds. In one project, we set up an async pipeline for order processing and forgot to size the consumer groups properly. During a Black Friday traffic spike, the queue grew to over 400,000 messages. Processing time per message stayed the same, but the backlog took four hours to clear. Orders were shipping hours late. We had to add auto-scaling consumer groups and implement a circuit breaker that routed traffic back to synchronous processing when queue depth exceeded a threshold. Another issue is timeout configuration. When callers do sync requests, they need a timeout. When they do async, they need a different mechanism to know whether their request was accepted or dropped. I use a combination of correlation IDs and a status endpoint so callers can check the state of their request without polling the queue directly.

Trade-offs that matter

Synchronous systems are easier to debug. You have a clear request-response chain in your logs. Asynchronous systems fragment that chain across multiple consumers, brokers, and sometimes databases. Distributed tracing helps, but it requires instrumentation upfront. OpenTelemetry covers this well if you adopt it from day one rather than retrofitting it later. Consistency is another trade-off. Sync gives you strong consistency naturally. Async gives you eventual consistency, which means your system will briefly show stale data. For most applications this is acceptable, but if you're building something like a banking ledger, you need to think about whether eventual consistency is a bug or a feature.

The hybrid approach is often the right answer. Use sync for critical paths that need immediate answers, and async for everything else. Route order creation synchronously to confirm the purchase, then fire async events for inventory allocation, payment notification, and shipping label generation. This cut our average response time by 60% while keeping the user experience intact.

Tools worth knowing

Kafka for event streaming at scale. RabbitMQ for traditional message queuing with rich routing options. Redis Streams for lightweight in-memory queuing when you don't need persistence guarantees. AWS SQS for managed queuing in cloud environments. gRPC for synchronous calls between services when you need low-latency RPC with streaming support. None of these are universally better. Kafka will overwhelm a small team that needs simple task distribution. RabbitMQ adds operational complexity that a two-developer startup doesn't need. Match the tool to the problem, not the other way around.