Learning · Software Engineering Manifesto
Sync when you must, async when you can
Request/response only when the caller needs the answer now — otherwise publish facts and decouple.
Principle
Synchronous calls couple latency and availability. Use them when the caller cannot continue without the result. Use asynchronous facts when others should react without blocking the writer.
Therefore we practice
- Ask: must the caller wait for an answer before responding or committing?
- Keep sync chains short and intentional
- Publish domain facts for fan-out (notifications, projections, downstream workflows)
- Do not implement RPC over message topics as a lifestyle
- Document the consistency users should expect (immediate vs eventual)
Smells
- Chatty service meshes of sync calls that recreate a monolith on the network
- “Event-driven” request/reply spaghetti with no ownership
- User-facing latency dominated by optional downstream work
- Blocking a write path on email, analytics, or search indexing