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.