06 Quiz: Software Architecture

Twitter’s Fail Whale illustrated what happens when a system’s architecture can’t support its success. Their monolithic Ruby on Rails application couldn’t be scaled to handle the rapid growth in users. The problem wasn’t the developers, the number of servers, or Ruby itself — it was the architectural decision to build everything as one tightly-coupled application that couldn’t be scaled independently.

Software architecture describes how a system is organized as a set of communicating components and how those components behave and interact. It answers questions like: How are responsibilities divided? How do components communicate? How is the system deployed? What happens when a component fails?

Architectural design is fundamentally creative because it involves trade-offs that depend on the type of system being developed, the background and experience of the architect, and the specific requirements of the project. Unlike algorithms with provably optimal solutions, architecture has no “correct” answer — it’s about making informed decisions given constraints and goals.

The lecture identifies 8 key architectural questions: templates, hardware distribution, patterns, fundamental structuring, component decomposition, operation control, NFR organization, and documentation. Individual developer language preferences are personal choices, not architectural decisions. Architecture is about system-level concerns, not individual coding preferences.

At 100 km/h, a car travels approximately 2.8 meters in 100ms. For safety-critical functions like steering and braking, the control system must respond fast enough that delays are imperceptible and safe. Running at 1 kHz (1ms cycles) means the car travels only 2.8 centimeters between control updates, enabling smooth and safe operation.

Defense in depth uses a layered architecture where each layer provides additional security. For example: WAF (Web Application Firewall) → API Gateway → Business Logic → Data Access → Database. If an attacker breaches one layer, they face additional barriers. This is more resilient than relying on a single security measure.

99.99% availability (“four nines”) allows for approximately 52.6 minutes of downtime per year. Compare this to: 99% = 3.65 days, 99.9% = 8.76 hours, 99.999% = 5.26 minutes. Each additional “nine” requires exponentially more sophisticated architecture — multiple data centers, no single points of failure, and active-active replication.

Netflix achieves 99.99% availability through multiple strategies: deploying across multiple AWS regions in active-active configuration, using Chaos Engineering (Chaos Monkey) to deliberately inject failures and verify resilience, and building stateless services where no single service holds critical state. This means any instance can handle any request, making failover seamless.

Separation of concerns means isolating different responsibilities so that changes to one area don’t ripple through the entire system. When you change how data is stored, you shouldn’t need to modify the UI. When you fix a calculation, you shouldn’t break authentication. This isolation makes the system easier to understand, test, and modify — critical because 80% of software cost is maintenance.

Performance-optimized architectures often sacrifice modularity and testability. Tightly coupled, monolithic components minimize communication overhead and are fast, but they’re hard to understand, test, and change. The lecture emphasizes choosing performance optimization only when requirements truly demand it, not as a default.

The Development View shows how code is organized into packages and modules. It answers questions like “Where does this functionality live in the codebase?” and helps coordinate development (“Anna works on services/, Ben works on presentation/”). The Logical View shows domain abstractions, Process View shows runtime behavior, and Physical View shows hardware deployment.

Each view in the 4+1 model serves different stakeholders: Logical View → developers, domain experts. Process View → performance engineers, integrators. Development View → programmers, project managers. Physical View → system engineers, operations. Scenarios (+1) → all stakeholders. The Physical View addresses deployment concerns like hardware, networks, and scaling.