Monolith-or-microservices and synchronous-or-asynchronous are NOT the same question. Click each cell of the 2×2 and see why a monolith can be async and microservices can be sync.
Monolithone codebase
Microservicesseparate services
Syncblocking
Asyncnon-blocking
Monolith · Synchronous
One deployable; functions call each other and block in sequence. The simplest place to start.
🧩 One application
Save order
→
Send email
→
Make invoice
Real-world example
Classic Django / Spring MVC app
User waited
0.0s
Sync = the user blocks until every step finishes.
Two axes, picked independently
Where your code lives (monolith ↔ microservices) and how it communicates (sync ↔ async) are separate dials. A LangGraph monolith can be event-driven; agent microservices can be synchronous. “Monolith” does not mean “sequential.”
What just happened
▹“Monolith vs microservices” is about WHERE your code lives and deploys. “Synchronous vs asynchronous” is about HOW the parts talk. They are two completely separate choices.
▹A monolith can be asynchronous (internal queue + background worker), and microservices can be synchronous (blocking REST calls). All four combinations are real and used in production.
▹Same for AI agents: a single LangGraph app can be event-driven, and separate agent microservices can still call each other synchronously. Don’t equate “monolith” with “sequential.”