Principles

A set of database transaction properties: Atomicity, Consistency, Isolation, Durability. Guarantees reliable processing of database transactions.

A mechanism that allows a consumer to signal to a producer that it cannot keep up. Prevents systems from being overwhelmed by controlling data flow.

A consistency model used in distributed systems: Basically Available, Soft State, Eventual Consistency. Contrasts with ACID for highly available, partition-tolerant systems.

Isolate components into separate pools so that a failure in one does not cascade to others. Prevents resource exhaustion from affecting the entire system.

Store frequently accessed data in a high-speed storage layer to reduce latency and load on backend systems. A fundamental performance optimization pattern.

In a distributed system, you can only guarantee two out of three: Consistency, Availability, and Partition Tolerance. A fundamental trade-off in distributed data stores.

Prevents repeated attempts to call a failing service by opening the circuit and failing fast. Allows the system to recover by periodically testing the service.

Strategies for managing data consistency in distributed systems: strong consistency, eventual consistency, and causal consistency. Each offers different trade-offs.

Reduce the number of decisions developers need to make by providing sensible defaults. Frameworks like Rails and Spring use this to simplify setup.

Every method should be either a command that performs an action or a query that returns data, but not both. Improves clarity and predictability of code.

Design code to handle unexpected inputs and states gracefully. Assume inputs will be invalid and protect against potential errors preemptively.

Depend upon abstractions, not concretions. High-level modules should not depend on low-level modules; both should depend on abstractions.

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. Eliminates duplication to reduce maintenance costs.

A consistency model where updates propagate to all nodes eventually, but not immediately. Provides high availability at the cost of temporary inconsistency.

Report errors immediately and halt execution when an unexpected condition occurs. Prevents cascading failures and makes bugs easier to detect.

When part of a system fails, the system continues to operate at a reduced capacity rather than failing completely. Essential for resilient distributed systems.

An operation that can be applied multiple times without changing the result beyond the first application. Critical for safe retries in distributed systems.

Hide internal implementation details of a module from its consumers. Expose only what is necessary through a well-defined interface.

No client should be forced to depend on methods it does not use. Prefer small, focused interfaces over large, general-purpose ones.

Systems work best when they are kept simple rather than made complex. Avoid unnecessary complexity in design and implementation.

A distributed algorithm for selecting a single node as the coordinator among a group of nodes. Essential for consensus and coordination in distributed systems.

Objects of a superclass should be replaceable with objects of its subclasses without breaking the system. Subtypes must be substitutable for their base types.

Drops lower-priority requests when the system is under heavy load to ensure critical requests are processed. A key resilience pattern for high-traffic services.

Software entities should be open for extension but closed for modification. Design modules that can be extended without modifying their source code.

Assumes multiple transactions can complete without conflict and only checks for conflicts at commit time. Uses version numbers to detect stale updates.

Assumes conflicts will occur and locks data at the start of a transaction to prevent concurrent modifications. Ensures data integrity at the cost of throughput.

Every program and user should operate with the minimum set of permissions necessary to complete their task. Reduces the attack surface and blast radius.

A consensus mechanism requiring a minimum number of nodes to agree on a decision. Used in distributed systems for reads/writes and leader election.

Controls the rate of requests a service can process within a time window. Prevents resource exhaustion and ensures fair usage across clients.

Divide a system into distinct sections where each section addresses a separate concern. Reduces complexity by modularizing functionality.

A class should have only one reason to change, meaning it should have only one job or responsibility. Promotes high cohesion and reduces coupling between components.

Five object-oriented design principles: Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. The foundation of maintainable OOP.

Slows down the processing of requests to prevent system overload. Often used with rate limiting to gracefully handle traffic spikes.

Always implement things when you actually need them, never when you merely foresee that you might need them. Prevents over-engineering and code bloat.