Wednesday, May 27, 2026 · 9:41 AM
ok can you explain choosing how services talk like i actually need to build it
service communication choices shape coupling, latency, reliability, debuggability, and how failure spreads
mental picture: phone call, text, letter, and group chat all move information, but each creates different expectations
good, now do the real thing
not the fake diagram version
REST over HTTP is simple, cacheable, human-readable, and works well for resource-oriented APIs
RPC feels like calling a function across the network, often faster and strongly typed, but can hide network cost
so the first move is making the invisible numbers visible
exactly
GraphQL lets clients request exactly the shape they need, but pushes complexity into schema design and resolver performance
what changes when this gets real traffic?
message queues and event streams decouple services when immediate answers are not required
webhooks and push channels invert polling, but require retries, signatures, and delivery tracking
wait, i thought the better answer was just adding the serious-sounding tool
that is the trap
the network is not a function call. it times out, duplicates, reorders, and lies by omission
ok so what bill shows up later?
sync calls are easier to reason about but couple availability
async messages improve resilience but make state harder to trace
strong contracts help teams move without breaking each other
where do people usually mess this up?
building a chain of synchronous calls where one slow service makes the whole product slow
if i were designing this tomorrow, what should i write down first?
the read path
the write path
the thing that is allowed to be stale
the thing that absolutely is not
that is annoyingly practical
yeah. most system design is boring on purpose
choose sync for immediate user decisions, async for side effects, and put timeouts everywhere
got it
less architecture cosplay, more pressure map
perfect
draw the pressure, then choose the machinery
Read Wed, May 27 · 9:58 AM