Are You Clear About When to Use Sync vs Async APIs?¶
Type: Structure, DeepDive
Category: API
Audience: Engineers defining API contracts, frontend/backend flows, or task orchestration
🔍 What This Perspective Covers¶
The problem isn't just how to implement async.
It's where to draw the line—and why.
⚠️ Common Confusions¶
- Sync endpoints that take 5+ seconds → client timeouts
- Async endpoints with no status feedback → user uncertainty
- APIs trigger long workflows but respond instantly without confirming outcome
- Event queues treated as invisible black boxes
âś… Clearer Boundaries¶
- Sync APIs: when immediate feedback or result is required
- Async APIs: for delegated, long-running, or retry-prone actions
- Always offer a follow-up API to check async job status
- Make contract-level expectations clear (e.g. SLAs, response time, finality)
- Document side effects and propagation timelines for async calls
đź§ Core Insight¶
The difference isn’t latency.
It’s contract shape and system responsibility.
âť“ FAQ¶
-
Q: Can we just make everything async?
A: Only if you design for it: status, feedback, and monitoring included. -
Q: Should we let clients poll for results?
A: Yes, but offer smart strategies: callbacks, webhooks, push if needed.