Foundational Principles

Foundational architecture principles are not abstract ideals — they are distilled lessons from decades of building systems that succeeded or failed at scale. Understanding them is the difference between a system that remains maintainable for ten years and one that becomes a rewrite candidate after two.

Separation of Concerns (SoC) is perhaps the most consequential principle. It states that a software component should have one clearly bounded responsibility. In practice, this means a service that handles payment processing should not also manage user notifications. When concerns are separated, changes to one area don't cascade unexpectedly into others. Google's internal platform engineering famously describes SoC as their "first line of defense against unintended coupling" — a system where concerns bleed into each other creates hidden dependencies that surface as outages during the worst possible moments.

The Dependency Inversion Principle (DIP) shifts the conventional dependency direction: instead of high-level business logic depending on low-level database code, both depend on an abstraction (an interface). The practical impact is enormous — swapping the database from PostgreSQL to Aurora, or from REST to gRPC, becomes a localized adapter change rather than a system-wide refactoring. Netflix's internal service framework enforces DIP at every service boundary, enabling them to run thousands of A/B experiments simultaneously without service-to-service interference.

Design for Failure is the principle that AWS codified into its Well-Architected Framework's Reliability pillar. The question is not "will this component fail?" but "when it fails, how does the system behave?" Every external call needs a timeout. Every downstream dependency needs a circuit breaker. Every queue needs a dead letter queue. Amazon's 2004 outage — caused by a cascade failure from a single unhealthy host — directly drove the adoption of this principle across their entire platform. The lesson: optimism in architecture is a liability.

Least Privilege transcends security into a general design principle: every component, process, and user should have access to exactly what it needs and nothing more. This is not just about preventing breaches — it's about containing blast radius. When a microservice's credentials are scoped to only its own database schema, a compromised service cannot exfiltrate data from adjacent systems. The Philippine banking sector's BSP Circular 982 explicitly mandates this principle at the infrastructure level for all regulated financial institutions.

Explicit over Implicit (also framed as the "Principle of Least Astonishment") demands that system behavior be discoverable without requiring deep knowledge of hidden conventions. Configuration should be declared, not inferred. Dependencies should be injected, not reached for globally. Side effects should be documented, not discovered in production. Jeff Dean's internal Google engineering guidelines describe this as "making the invisible visible" — surfacing assumptions that are otherwise silent failure modes.

These principles are not independent — they reinforce each other. A system that honors SoC naturally makes DIP easier to implement. A system built with explicit dependencies is far easier to harden with least privilege. Together, they form a self-reinforcing architecture immune system.