Software Architecture & Distributed Systems

Overview

The source notes treat software architecture as the set of design decisions that matter most to a system’s long-term adaptability. The recurring message is that architecture is not ornamental documentation or detached diagramming; it is the practical discipline of preserving internal quality so teams can keep shipping without accumulating crippling complexity.

This area sits between implementation-level engineering and platform-level cloud infrastructure. It connects design choices such as service boundaries, APIs, layering, and deployment models to real-world concerns like team autonomy, operational overhead, and delivery speed.


Core Areas

Architecture as Internal Quality

A central theme in the notes is that architecture matters because poor internal quality creates cruft: complexity that slows change, increases defects, and makes systems harder to understand. In this view, architecture is less about abstract diagrams and more about maintaining the important structural decisions that keep a codebase evolvable.

Application Boundaries

Architecture decisions often begin with defining the boundary of an application:

  • what belongs inside one system
  • what should be split into services
  • what teams can own independently
  • what requires shared standards across the organization

The notes emphasize that application boundaries are partly technical and partly social: they reflect code ownership, business capabilities, and funding or product boundaries.

Distributed System Styles

The vault repeatedly references a few major distributed patterns:

  • Microservices — services aligned to business capabilities and deployed independently
  • Serverless — event-driven functions and managed services replacing traditional server ownership
  • layered and hexagonal approaches — separating domain logic from delivery and infrastructure concerns
  • BFF and API-centric integration — tailoring interfaces to clients and service boundaries

Interface Design

Distributed systems are held together by contracts. In the source notes, those contracts are often implemented as RESTful APIs with attention to versioning, documentation, authentication, errors, and consumer usability.

Operational Trade-Offs

The notes repeatedly balance architectural benefits against the cost of distribution:

Architectural moveMain upsideMain cost
Split a monolith into servicesteam autonomy, targeted scalingoperational complexity
Adopt serverlessless infra management, elastic scalevendor coupling, observability complexity
Add more layers/abstractionsclearer separation of concernsindirection and boilerplate
Standardize enterprise-wideinteroperability and reuseslower local decision-making

Recurring Principles

  • architecture should support evolution, not freeze systems prematurely
  • internal quality pays back through faster change, not just cleaner code
  • distributed systems solve some scaling and autonomy problems while creating coordination and observability problems
  • interface design is a core architectural concern, not an afterthought
  • decentralization is usually healthier than excessive central control, but total chaos is not the goal either

Relationships

  • Cloud & AWS Infrastructure — cloud services provide the runtime environment for many distributed architectures
  • Microservices — major architectural style in the source set
  • Serverless — managed-event execution model for modern architectures
  • RESTful API — common interface style connecting components and clients
  • Backend for Frontend — boundary pattern for shaping APIs around specific clients
  • System Design — interview-oriented framing of many of the same trade-offs
  • System Thinking — useful lens for reasoning about boundaries, interactions, and trade-offs
  • Designing to a Latency Budget — when a response time is a requirement it removes options: Suica’s 200ms and on-card state

References

  • Software Architecture Guide
  • _architect notes
  • _Best Practice of Software Engineering and Architecture
  • about micro service