Software Architecture: The Hard Parts — Episode 1
Episode participants
The complete participant roster has not yet been confirmed by the available sources.
What we discussed on the recording
The first episode frames architecture as decisions that are costly to change and require trade-off analysis. Data outlives applications, so its context matters. ADRs capture decisions and consequences, while fitness functions automatically check architectural commitments.
An architectural quantum is an independently deployable artifact with high functional cohesion, static coupling, and synchronous dynamic coupling. A shared database or synchronous call chain binds services into one quantum. Separate databases, asynchronous links, and microfrontends help split it.
Dynamic coupling is described through communication, consistency, and coordination. Synchrony depends not on transport but on whether the caller must wait. Kafka during startup, fallbacks, and local caches therefore complicate a quantum's boundary. It resembles a bounded context but adds operational properties to domain cohesion.
Modularity responds to business and technical drivers. Time to market depends on testability and deployability, while scalability differs from elasticity: one handles growth, the other load swings. Smaller quanta reduce the scope of changes and tests, release risk, and failure blast radius; domain-aligned slices usually outperform technical layers.