Code to Architecture

Part 1 focused on choosing between synchronous and asynchronous communication based on business contract. Part 2 focuses on what happens after that initial choice, when retries, timeouts, duplicate delivery, and ambiguous outcomes start showing up in production.

This is where many seemingly reasonable designs break. A synchronous call that was fine at low traffic beco...

Part 1 focused on where service boundaries should exist. Part 2 is about the part teams often underestimate: how to move toward those boundaries without creating a migration-era distributed monolith.

Many decompositions fail not because the target boundary is wrong, but because the extraction path creates months of dual writes, ambiguous ownership, temporary shared sc...

The most honest architecture reviews usually happen after an incident. That is when hidden coupling, poor fallback behavior, weak ownership boundaries, and noisy operational assumptions stop being theoretical. The mistake many teams make is treating the incident only as a reliability event instead of an architecture signal.

This article is about using incidents to dri...

Platform standards are supposed to reduce cognitive load. In weak microservice programs, they do the opposite: every team gets a library, a YAML file, and a checklist, but nobody can explain which standards are mandatory, which are defaults, and which still require service-specific judgment.

This article is about designing platform standards that actually improve syst...

In a microservice system, partial failure is not an edge case. It is the normal shape of trouble. One dependency slows down, one cache goes cold, one projection lags, one recommendation engine times out. The architectural question is not whether failure happens. It is whether the product still behaves in a controlled, understandable way when only part of the system is healthy...