Morty Taghdisi

Series

System Architecture Field Guide

A field guide for engineers moving into system ownership, focused on the decisions that make systems safer to change, easier to understand, and less fragile under real product pressure.

Reading order

  1. 01What Architects Actually DecideArchitects make the decisions that shape how systems change, fail, recover, and get owned over time.
  2. 02Architecture Is Mostly Tradeoffs: Naming What A Decision CostsEvery architecture decision makes something easier and something else harder. The work is naming that cost before the system pays it later.
  3. 03Monoliths, Modular Monoliths, And Services Without HypeThe question is not whether services are more modern. The question is whether the system is ready to pay the cost of distribution.
  4. 04Finding Service Boundaries That Teams Can OwnA good service boundary reduces coordination. A weak one turns every change into a negotiation across teams.
  5. 05API Design As ArchitectureGood API design makes the right boundary clear. Bad API design leaks internal systems into every team that depends on it.
  6. 06Synchronous vs Asynchronous CommunicationThe question is not REST or events. The question is whether the caller needs an answer now, and what the system should do when part of the workflow cannot finish now.
  7. 07SDK Architecture For Systems Other Developers Depend OnSDK architecture is the work of designing a boundary that other developers can trust, version, observe, and live with over time.
  8. 08Mobile And Backend Architecture Are One SystemA reliable product needs architecture that treats the mobile app and backend as one system, not as separate worlds connected by HTTP.
  9. 09Database Migrations Without Breaking ProductionSafe database migrations are designed as rollouts, not one-off SQL changes.
  10. 10Timeouts, Retries, Idempotency, And BackpressureRetries are only safe when the operation can handle being repeated. Backpressure is only useful when the system knows what to slow down, reject, or shed.
  11. 11Observability That Changes Architecture DecisionsA system is not production-ready if the team cannot see how it behaves when users, dependencies, and deployments create pressure.
  12. 12Change Safety: Testing Systems You Cannot Fully StageSafe change is not only a test-suite problem. It is an architecture problem.