DEV Community: The Architect

SOLID Principles Cheat Sheet

The Architect — Tue, 28 Jul 2026 06:19:00 +0000

Writing software that scales from a small monolith into a multi-team distributed system requires strict architectural discipline. The SOLID principles—coined by Robert C. Martin ("Uncle Bob")—serve as fundamental guidelines for object-oriented design and system architecture.

When improperly understood, developers often fall into two extreme traps: creating monolithic "God objects" that break with every change, or over-engineering systems into hyper-fragmented, unmaintainable micro-services.

In this deep-dive guide, we will break down each of the 5 SOLID principles from low-level class design up to high-level distributed systems design, complete with bad vs. refactored Java examples, system architecture diagrams, trade-off analyses, and a comprehensive cheat sheet.

SOLID Principles Cheat Sheet

Principle	Core Concept	Anti-Pattern / Code Smell	Refactoring Solution
Single Responsibility (SRP)	A class or module should have one, and only one, reason to change (serving one business actor/domain).	God Class / Micro-Fragmentation: Classes handling payment, DB, and notifications, OR over-fragmented single-function classes.	Split by domain responsibility. Use orchestrator/coordinator components for workflows.
Open/Closed (OCP)	Software entities should be open for extension, but closed for modification.	Conditional Bloat: Cascading `if-else` or `switch` statements checking object types or channels.	Strategy Pattern, Dependency Injection, and Event-Driven Pub/Sub messaging (e.g., Kafka).
Liskov Substitution (LSP)	Subtypes must be completely substitutable for their base types without breaking client behavior.	Runtime Exceptions: Subclasses throwing `UnsupportedOperationException` or silently breaking logic.	Split fat inheritance hierarchies into granular, capability-specific interfaces.
Interface Segregation (ISP)	No client should be forced to depend on methods it does not use.	Fat Interfaces: Monolithic interfaces forcing callers to mock or implement irrelevant methods.	Role-focused, lean interfaces broken down by client requirements.
Dependency Inversion (DIP)	High-level business logic must depend on abstractions, not low-level infrastructure details.	Direct Instantiation: Hardcoding `new ConcreteRepository()` or `new ThirdPartySdk()` inside core logic.	Pass interface dependencies via Constructor Injection (Inversion of Control).

1. Single Responsibility Principle (SRP)

"A class or module should have one, and only one, reason to change."

SRP is often misunderstood as "a class should only have one function". That is incorrect. The core idea is that a module or class should solve one business need and serve one business actor (e.g., Finance, Fulfillment, or Marketing).

   +-------------------------------------------------------------+
   |                       OrderProcessor                        |
   |-------------------------------------------------------------|
   | 1. Business Logic & Validation (Domain)                    |
   | 2. Payment API Calls          (Finance Actor)                |
   | 3. Database SQL Operations    (Fulfillment Actor)           |
   | 4. SMTP Email Delivery        (Marketing Actor)             |
   +-------------------------------------------------------------+
                                  |
                                  v  VIOLATES SRP!
   (Any change across 4 different domains forces editing this file)

Consequences of Violating SRP

Hard to Debug: Cross-domain logic leads to unexpected side effects during runtime.
Modification Bottlenecks: Simple feature changes require navigating massive, fragile files.
Merge Conflicts: Multiple engineers working on different domain requirements touch the exact same file, slowing down deployments.

SRP Across Architectural Boundaries

SRP applies at three distinct levels:

Class Level: Defining clear boundaries and single responsibility per class.
Module Level: Grouping cohesive classes into tightly bounded packages.
Microservice Level: Defining domain boundaries around single business domains.

SRP Anti-Patterns

Class-Level Anti-Pattern: Hyper-Fragmentation

The Mistake: Developers create separate classes like EmailValidator, AgeValidator, PhoneNumberValidator, etc.
Why it Hurts: It confuses "one responsibility" with "one function." It destroys readability, inflates the class count, and increases CPU in-cache misses during execution.
Correct Approach: A single UserValidator class that validates all parameters related to the User entity is sufficient, as all these validation rules belong to the exact same business domain.

Microservice-Level Anti-Pattern: Over-Servicicing

The Mistake: Creating separate microservices for EmailNotificationService, SMSNotificationService, and PushNotificationService.
Why it Hurts: Adds unnecessary network hop latency. In scenarios like Amazon order deliveries, where all three notifications may need to be triggered together, this creates distributed transaction overhead.
Correct Approach: A unified NotificationService microservice is optimal unless separate scaling requirements or distinct async guarantees demand isolation.

Code Example: SRP Refactoring

❌ BAD DESIGN: Monolithic `OrderProcessor`

public class OrderProcessor {
    public void processOrder(Order order) {
        // 1. Business Logic & Validation
        if (order.getItems().isEmpty()) {
            throw new IllegalArgumentException("Order cannot be empty");
        }

        // 2. Payment Processing (Finance Actor)
        System.out.println("Connecting to payment API...");
        boolean paymentSuccess = paymentService.makePayment(); // Simulated HTTP Call
        if (!paymentSuccess) {
            throw new RuntimeException("Payment failed");
        }
        order.setStatus("PAID");

        // 3. Database Operations (Fulfillment Actor)
        order.save();

        // 4. Notification Engine (Marketing Actor)
        String emailBody = "Thank you for your order #" + order.getId();
        System.out.println("Sending SMTP email to " + order.getCustomerEmail() + ": " + emailBody);
    }
}

✅ REFACTORED CODE: Domain-Separated Architecture

// --- Component 1: Payment Domain (Finance) ---
public interface PaymentGateway {
    boolean charge(String orderId, double amount);
}

public class StripePaymentGateway implements PaymentGateway {
    @Override
    public boolean charge(String orderId, double amount) {
        // Handles Stripe API calls exclusively
        return true;
    }
}

// --- Component 2: Persistence Domain (Fulfillment) ---
public class OrderRepository {
    public void save(Order order) {
        // Handles Database SQL operations exclusively
    }
}

// --- Component 3: Notification Domain (Marketing) ---
public class NotificationService {
    public void sendOrderConfirmation(Order order) {
        // Handles Email/SMS template rendering & delivery exclusively
    }
}

// --- Coordinator: Orchestrates flow without executing underlying implementation ---
public class OrderProcessor {
    private final PaymentGateway paymentGateway;
    private final OrderRepository orderRepository;
    private final NotificationService notificationService;

    public OrderProcessor(PaymentGateway paymentGateway,
                          OrderRepository orderRepository,
                          NotificationService notificationService) {
        this.paymentGateway = paymentGateway;
        this.orderRepository = orderRepository;
        this.notificationService = notificationService;
    }

    public void processOrder(Order order) {
        if (order.getItems().isEmpty()) {
            throw new IllegalArgumentException("Order cannot be empty");
        }

        if (!paymentGateway.charge(order.getId(), order.getTotalAmount())) {
            throw new RuntimeException("Payment failed");
        }

        order.setStatus("PAID");
        orderRepository.save(order);
        notificationService.sendOrderConfirmation(order);
    }
}

2. Open/Closed Principle (OCP)

"Software entities (classes, modules, functions) should be open for extension, but closed for modification."

Adding a new feature should mean writing new code, not editing existing tested code.

Real-World Scenario

Imagine a payment engine that supports Credit Card and PayPal. The business expands to support Bank Transfers via Stripe. Stripe isn't supported in all regions. A developer modifies the core PaymentProcessor file with a massive if-else statement to handle Stripe validations.

During this modification, an edge case in Credit Card validation is accidentally modified and broken in production. OCP protects systems from this regression risk.

Code Example: OCP Refactoring

❌ BAD DESIGN: Rigid Conditional Checks

public class PaymentProcessor {
    public void processPayment(String paymentType, double amount) {
        if (paymentType.equalsIgnoreCase("CREDIT_CARD")) {
            if (supportsPaymentMethod("CREDIT_CARD")) {
                System.out.println("Processing Credit Card via Stripe: $" + amount);
                // Stripe API logic
            }
        } else if (paymentType.equalsIgnoreCase("PAYPAL")) {
            if (supportsPaymentMethod("PAYPAL")) {
                System.out.println("Processing PayPal payment: $" + amount);
                // PayPal API logic
            }
        } else if (paymentType.equalsIgnoreCase("BANK_TRANSFER")) {
            if (supportsPaymentMethod("BANK_TRANSFER")) {
                System.out.println("Processing Direct Wire Transfer: $" + amount);
                // ACH/Wire transfer logic
            }
        } else {
            throw new IllegalArgumentException("Unsupported payment type: " + paymentType);
        }
    }

    private boolean supportsPaymentMethod(String paymentType) {
        return true;
    }
}

✅ REFACTORED CODE: Open for Extension via Strategy Pattern

// --- Stable Contract (Closed for modification) ---
public interface PaymentStrategy {
    boolean supports(String paymentType);
    void process(double amount);
}

// --- Concrete Implementations (Open for extension) ---
public class CreditCardPayment implements PaymentStrategy {
    @Override
    public boolean supports(String paymentType) {
        return "CREDIT_CARD".equalsIgnoreCase(paymentType);
    }

    @Override
    public void process(double amount) {
        System.out.println("Processing Credit Card via Stripe: $" + amount);
    }
}

public class PaypalPayment implements PaymentStrategy {
    @Override
    public boolean supports(String paymentType) {
        return "PAYPAL".equalsIgnoreCase(paymentType);
    }

    @Override
    public void process(double amount) {
        System.out.println("Processing PayPal payment: $" + amount);
    }
}

// --- NEW FEATURE ADDED WITHOUT TOUCHING EXISTING CODE ---
public class ApplePayPayment implements PaymentStrategy {
    @Override
    public boolean supports(String paymentType) {
        return "APPLE_PAY".equalsIgnoreCase(paymentType);
    }

    @Override
    public void process(double amount) {
        System.out.println("Processing Apple Pay: $" + amount);
    }
}

// --- Core Engine (Never needs to change again) ---
public class PaymentProcessor {
    private final List<PaymentStrategy> strategies;

    // Dependency injection automatically registers all strategy implementations
    public PaymentProcessor(List<PaymentStrategy> strategies) {
        this.strategies = strategies;
    }

    public void processPayment(String paymentType, double amount) {
        PaymentStrategy strategy = strategies.stream()
            .filter(s -> s.supports(paymentType))
            .findFirst()
            .orElseThrow(() -> new IllegalArgumentException("Unsupported payment: " + paymentType));

        strategy.process(amount);
    }
}

Architectural Trade-Offs of OCP

Gained: Zero-risk extensions & parallel development. Team A can build ApplePayPayment while Team B builds CryptoPayment. Neither team touches core orchestrator files or creates merge conflicts.
Cost Introduced: Indirection & discovery cost. Tracing runtime execution requires navigating through dynamic dependency injection configurations rather than reading direct code flows.

Scaling OCP to Microservices & Distributed Systems

When scaling platforms like Shopify or Amazon, multiple teams must react when an order is completed:

Fulfillment Team: Generates a shipping label.
Marketing Team: Sends a discount coupon email.
Analytics Team: Updates daily revenue charts.
Fraud Team: Checks transaction risk markers.

Rigid Architecture (Direct Synchronous Calls)

[ Order Service ] ---> (Calls Fulfillment API)
                 ---> (Calls Marketing API)
                 ---> (Calls Analytics API)
                 ---> (Calls Fraud API)  <-- NEW REQUIREMENT REQUIRES DEPLOYING ORDER SERVICE

Failure Mode: Order Service becomes the team bottleneck. If Analytics goes down or experiences latency, checkout fails for end users.

OCP Microservice Architecture (Pub/Sub Event Bus)

graph TD
    subgraph Core ["Core System (Closed for Modification)"]
        OS[Order Service - Producer]
    end

    subgraph Broker ["Event Bus"]
        KT[("Kafka Topic: order-events")]
    end

    subgraph Extension ["Consumers (Open for Extension)"]
        FS[Fulfillment Service]
        MS[Marketing Service]
        AS[Analytics Service]
        FrS[Fraud Service - Extension]
    end

    OS -->|1. Publish OrderPlaced Event| KT
    KT -->|2. Consume Event| FS
    KT -->|2. Consume Event| MS
    KT -->|2. Consume Event| AS
    KT -->|2. Consume Event| FrS

Closed for Modification: The Order Service codebase is 100% frozen. It doesn't care who listens to OrderPlaced events.
Open for Extension: When the Fraud team launches 6 months later, they deploy the standalone Fraud Service microservice and subscribe to Kafka. Zero PRs or deployments are required from the Order team.

Architectural Choice: Synchronous Dispatcher vs. Distributed Pub/Sub

Is Kafka always necessary? Not always.

Metric / Consideration	Approach A: In-Process `NotificationDispatcher`	Approach B: Distributed Event-Driven (Kafka)
Latency	Extremely low (In-memory calls).	Higher (Network hops, broker queuing, consumer polling).
Operational Complexity	Simple (Zero external infrastructure required).	High (Requires Kafka cluster, DLQs, tracing tools).
System Resiliency	Lower (Failure in 1 sync handler impacts caller).	High (Isolated consumer failures, built-in queue buffering).
Throughput Scaling	Limited by single node CPU/RAM limits.	Massive horizontal scale across independent consumer worker groups.

Decision Framework: When to Use Which?

Choose Approach A (In-Process Dispatcher) IF:

Low Volume / Early Stage: Application handles <10,000 events/day in a monolithic setup.
Synchronous Feedback Needed: Callers must confirm processing success inside the HTTP request (e.g., validating 2FA OTP codes).
Low Operational Overhead: No dedicated DevOps infrastructure team available.

Choose Approach B (Distributed Pub/Sub) IF:

High Scale & Burst Traffic: System handles millions of daily operations or experiences extreme flash sales.
Third-Party Rate Limits: Dependent on external vendor APIs (Twilio, SendGrid, WhatsApp) that rate-limit or experience downtime. The message broker acts as a shock absorber.
Cross-Team Independence (Conway's Law): Independent business teams need to process data asynchronously without blocking checkout flows.

The Production Reality: Hybrid Pattern

graph TD
    API[Core Order / Auth API]

    API -->|Critical 2FA OTP| Dispatcher[In-Process Dispatcher]
    Dispatcher -->|Fast Sync Call| User[Immediate Response]

    API -->|Non-Critical Notifications| Bus[Kafka / Event Bus]

    subgraph AsyncWorkers ["Async Consumer Workers"]
        Bus --> EW[Email Worker - Strategy]
        Bus --> PW[Push Notif Worker - Strategy]
    end

3. Liskov Substitution Principle (LSP)

"Subtypes must be substitutable for their base types without altering the correctness of the program."

LSP ensures that polymorphism is safe at scale. If a subclass throws unexpected runtime exceptions, ignores methods, or alters behavior unexpectedly, client code breaks in production.

Real-World Example: Non-Refundable Payment Methods

Consider a payment engine handling refunds. A developer adds GiftCardPaymentService extending PaymentService. However, gift cards cannot be refunded back to cash; they only support store credit.

If the subclass throws UnsupportedOperationException when calling .refund(), it violates LSP and breaks downstream refund processing pipelines.

                  PaymentService (refunds allowed)
                         ▲
                         │
        ┌────────────────┴────────────────┐
        │                                 │
CreditCardPayment                 GiftCardPayment
(Refunds work)                    (Throws UnsupportedOperationException!)
                                        ▲
                                        │
                         CRASHES RefundProcessor!

Code Example: LSP Refactoring

❌ BEFORE (Violates LSP)

import java.math.BigDecimal;

public class PaymentService {
    public void processPayment(String orderId, BigDecimal amount) {
        System.out.println("Processing payment of $" + amount + " for order " + orderId);
    }

    public void refund(String transactionId, BigDecimal amount) {
        System.out.println("Refunding $" + amount + " for transaction " + transactionId);
    }
}

public class GiftCardPaymentService extends PaymentService {
    @Override
    public void processPayment(String orderId, BigDecimal amount) {
        System.out.println("Deducting $" + amount + " from gift card balance for order " + orderId);
    }

    @Override
    public void refund(String transactionId, BigDecimal amount) {
        // VIOLATION: Throws runtime exception for an inherited parent contract method!
        throw new UnsupportedOperationException("Gift card transactions cannot be refunded to cash.");
    }
}

public class RefundProcessor {
    public void handleCustomerRefund(PaymentService paymentService, String transactionId, BigDecimal amount) {
        // Crashes with runtime exception if passed an instance of GiftCardPaymentService!
        paymentService.refund(transactionId, amount);
    }
}

✅ AFTER (LSP Compliant via Interface Segregation)

import java.math.BigDecimal;

// Core contract: Every payment method can charge
public interface ChargeablePaymentService {
    void processPayment(String orderId, BigDecimal amount);
}

// Extended contract: Only refundable payment methods implement this
public interface RefundablePaymentService extends ChargeablePaymentService {
    void refund(String transactionId, BigDecimal amount);
}

// Standard Credit Card supports processing AND refunds
public class CreditCardPaymentService implements RefundablePaymentService {
    @Override
    public void processPayment(String orderId, BigDecimal amount) {
        System.out.println("Charging credit card $" + amount + " for order " + orderId);
    }

    @Override
    public void refund(String transactionId, BigDecimal amount) {
        System.out.println("Refunding $" + amount + " to credit card for transaction " + transactionId);
    }
}

// Gift Card ONLY implements ChargeablePaymentService
public class GiftCardPaymentService implements ChargeablePaymentService {
    @Override
    public void processPayment(String orderId, BigDecimal amount) {
        System.out.println("Deducting $" + amount + " from gift card for order " + orderId);
    }
    // Invalid refund method does not exist. Invalid calls caught AT COMPILE TIME!
}

public class RefundProcessor {
    // Explicitly requires RefundablePaymentService contract
    public void handleCustomerRefund(RefundablePaymentService paymentService, String transactionId, BigDecimal amount) {
        paymentService.refund(transactionId, amount); // 100% type-safe
    }
}

LSP at the Microservice Boundary

In distributed systems, LSP means API contract changes must remain backward-compatible. API producers should not remove fields or change response behavior in ways that force consumers to upgrade immediately or handle breaking exception payloads.

4. Interface Segregation Principle (ISP)

"No client should be forced to depend on methods it does not use."

Large, monolithic interfaces ("fat interfaces") force implementations to write empty methods or throw UnsupportedOperationException. They should be split into lean, client-focused role interfaces.

Benefits of ISP

No Unused Code: Consumers only implement methods they care about.
Isolated Testing: Eliminates the need to mock dozens of unused methods in unit tests.
Safer Refactoring: Updating one domain method does not invalidate unrelated implementations.

Code Example: ISP Refactoring

❌ BEFORE (Violates ISP)

// Fat Interface: Forces all implementations to handle every concern
public interface OrderProcessor {
    void processOrder(String orderId);
    void cancelOrder(String orderId);
    void auditOrderHistory(String orderId);
    void exportMetricsToDataLake();
}

public class MobileOrderService implements OrderProcessor {
    @Override
    public void processOrder(String orderId) {
        System.out.println("Processing mobile order: " + orderId);
    }

    @Override
    public void cancelOrder(String orderId) {
        System.out.println("Canceling mobile order: " + orderId);
    }

    // Irrelevant to mobile checkout!
    @Override
    public void auditOrderHistory(String orderId) {
        throw new UnsupportedOperationException("Mobile backend does not perform audits.");
    }

    // Irrelevant to mobile checkout!
    @Override
    public void exportMetricsToDataLake() {
        throw new UnsupportedOperationException("Mobile backend does not export data lake metrics.");
    }
}

✅ AFTER (ISP Compliant)

// Granular, role-focused interfaces
public interface OrderLifecycleManager {
    void processOrder(String orderId);
    void cancelOrder(String orderId);
}

public interface OrderAuditor {
    void auditOrderHistory(String orderId);
}

public interface OrderAnalyticsExporter {
    void exportMetricsToDataLake();
}

// Mobile Service implements only what it executes
public class MobileOrderService implements OrderLifecycleManager {
    @Override
    public void processOrder(String orderId) {
        System.out.println("Processing mobile order: " + orderId);
    }

    @Override
    public void cancelOrder(String orderId) {
        System.out.println("Canceling mobile order: " + orderId);
    }
}

// Admin Service implements multiple interfaces as needed
public class EnterpriseAdminService implements OrderLifecycleManager, OrderAuditor {
    @Override
    public void processOrder(String orderId) { /* ... */ }

    @Override
    public void cancelOrder(String orderId) { /* ... */ }

    @Override
    public void auditOrderHistory(String orderId) {
        System.out.println("Auditing order: " + orderId);
    }
}

5. Dependency Inversion Principle (DIP)

"1. High-level modules should not depend on low-level modules. Both should depend on abstractions."
"2. Abstractions should not depend on details. Details should depend on abstractions."

DIP removes hardcoded infrastructure dependencies (PostgresDatabase, TwilioSmsClient, AWS S3) from core application logic.

Benefits of DIP

Pluggable Infrastructure: Swap cloud providers or database vendors without touching core business logic.
Isolated Unit Testing: Test domain logic quickly using mock abstractions without spinning up databases or network listeners.

Code Example: DIP Refactoring

❌ BEFORE (Violates DIP)

// Low-level infrastructure classes
public class TwilioSmsClient {
    public void sendSms(String phone, String msg) {
        System.out.println("Sending Twilio SMS to " + phone);
    }
}

public class PostgresDatabase {
    public void insertOrder(String orderId) {
        System.out.println("Saving order " + orderId + " to Postgres");
    }
}

// High-level business logic
public class CheckoutService {
    // VIOLATION: Directly instantiating concrete infrastructure implementations!
    private TwilioSmsClient smsClient = new TwilioSmsClient();
    private PostgresDatabase database = new PostgresDatabase();

    public void checkout(String orderId, String userPhone) {
        database.insertOrder(orderId);
        smsClient.sendSms(userPhone, "Order " + orderId + " confirmed!");
    }
}

✅ AFTER (DIP Compliant)

// Domain Abstractions (Interfaces)
public interface NotificationPublisher {
    void notifyUser(String recipient, String message);
}

public interface OrderRepository {
    void saveOrder(String orderId);
}

// Low-Level Implementations adapting to abstractions
public class TwilioNotificationPublisher implements NotificationPublisher {
    @Override
    public void notifyUser(String recipient, String message) {
        System.out.println("Sending Twilio SMS to " + recipient);
    }
}

public class PostgresOrderRepository implements OrderRepository {
    @Override
    public void saveOrder(String orderId) {
        System.out.println("Saving order " + orderId + " to Postgres");
    }
}

// High-Level Business Logic depends ONLY on abstractions
public class CheckoutService {
    private final NotificationPublisher notificationPublisher;
    private final OrderRepository orderRepository;

    // Dependency Injection via Constructor
    public CheckoutService(NotificationPublisher notificationPublisher, 
                            OrderRepository orderRepository) {
        this.notificationPublisher = notificationPublisher;
        this.orderRepository = orderRepository;
    }

    public void checkout(String orderId, String userPhone) {
        // Pure domain logic—100% decoupled from database & vendor details!
        orderRepository.saveOrder(orderId);
        notificationPublisher.notifyUser(userPhone, "Order " + orderId + " confirmed!");
    }
}

Conclusion & Architecture Roadmap

The SOLID principles are not academic rules to be applied blindly; they are tools to manage system complexity.

               ┌──────────────────────────────────────────────┐
               │              SOLID Architecture              │
               └──────────────────────┬───────────────────────┘
                                      │
         ┌────────────────────────────┼────────────────────────────┐
         ▼                            ▼                            ▼
  Class Level                  Module Boundary             Distributed Scale
  • Lean interfaces (ISP)      • Single Actor boundaries   • Pub/Sub Event Bus (OCP)
  • Type safety (LSP)            (SRP)                     • Isolated microservices
  • Inject abstractions        • Domain-driven packaging   • Stable API contracts
    (DIP)                         structure                   (LSP)

Start with SRP and DIP: Establish clean domain boundaries and inject dependencies.
Apply OCP and LSP as complexity grows: Use Strategy patterns and proper interface hierarchies to make adding features simple and safe.
Scale OCP to Distributed Systems: Use Event-Driven Pub/Sub messaging (like Kafka) to keep microservices decoupled and resilient.

💡 Get the Full 10-Page System Design Guide

Subscribe to The Tech Builder Newsletter to instantly get the full, unredacted guide for free.

Every week, subscribers receive:

🎯 Deep-dive production postmortems & system design trade-off analysis.
🛠️ Real-world architecture playbooks for Senior ICs, Tech Leads, and Architects.
🎁 Instant Bonus: Get the Full 6-Month Prep Tracker & Study Schedule + 10-Page System Design Cheat Sheet immediately upon subscribing.

👉 Get the Full System Design Cheat Sheet

The 10-Minute System Design Interview Cheat Sheet

The Architect — Sun, 26 Jul 2026 16:45:12 +0000

System design interviews can feel overwhelming due to their open-ended nature. Having a structured mental framework and quick access to core operational metrics gives you immediate traction.

Here is a condensed, high-yield cheat sheet covering the foundational topics every engineer should know before an architecture review or interview.

1. Estimation Cheat Sheet & Core Metrics

Latency Scale

L1 Cache / RAM Access: ~1 ns to 100 ns (Use for high-frequency, ultra-low latency memory operations).
NVMe SSD Read: ~100 µs (1,000 times slower than RAM).
Network Read (Same Region): ~0.5 ms to 2 ms.
Cross-Continental Packet Roundtrip: ~150 ms (Justifies placing edge caches/CDNs close to users).

QPS & Capacity Multipliers

100M Daily Active Users (DAU): approx 1,200 Average QPS (assuming 10 requests/user/day).
Peak Traffic: Always multiply average QPS by 2 times to 5 times to size infrastructure for bursts.
Storage Rule: 1 Byte/sec = approx 86.4 KB/day = approx 31.5 MB/year.

2. Database Selection Matrix

Database Type	Key Examples	Primary Use Case	When to Avoid
Relational (SQL)	PostgreSQL, MySQL	ACID transactions, strict schema, complex relational joins	Write throughput exceeding $50k QPS on single nodes
Document	MongoDB, DynamoDB	Rapidly evolving schemas, hierarchical catalog data	Deep multi-table transactional aggregations
Key-Value	Redis, Memcached	Session stores, distributed locks, transient caching	Queries requiring filtering by non-key attributes
Wide-Column	Cassandra, ScyllaDB	High-volume time-series, IoT telemetry, append-only logs	Frequent updates/deletes to existing records
Search Engine	Elasticsearch	Full-text fuzzy search, inverted indexing, log analytics	Primary source-of-truth transactional storage

3. Caching & Data Storage Strategies

Caching Strategies

Cache-Aside (Lazy Loading): App reads from cache; on miss, reads from DB, updates cache, and returns. Best for standard read-heavy workloads.
Write-Through: App writes to cache and DB synchronously. Ensures strong consistency at the cost of higher write latency.
Write-Back (Write-Behind): App writes directly to cache; cache asynchronously updates DB in batches. Ultra-high write performance, but risks data loss on cache failure.

Common Cache Pitfalls

Cache Stampede (Thundering Herd): Concurrent requests miss cache simultaneously, overwhelming the DB. Fix: Distributed locks or proactive cache warming.
Cache Penetration: Non-existent keys repeatedly bypass cache to hit the DB. Fix: Cache null responses or use Bloom Filters.

4. Networking Protocols & Load Balancing

API Protocols

HTTP/REST: Standard request-response over TCP. Best for public, client-facing APIs.
gRPC (HTTP/2): High-performance, binary-serialized RPC protocol. Best for low-latency microservice-to-microservice calls.
WebSockets: Persistent, bi-directional TCP stream. Best for real-time applications (chat, live gaming, collaborative tools).
Server-Sent Events (SSE): Unidirectional streaming from server to client over HTTP. Best for live dashboards and AI text streaming.

Load Balancing

Layer 4 (Transport): Routes traffic based on IP and TCP/UDP ports without payload inspection (ultra-fast).
Layer 7 (Application): Inspects HTTP headers, cookies, and URLs for intelligent routing (e.g., routing /api/v1/payments to dedicated payment servers).

5. Async Pipelines & Distributed Transactions

Messaging Infrastructure

Message Queues (RabbitMQ, AWS SQS): Point-to-point worker queues where messages are deleted once processed. Best for background task processing.
Event Streams (Apache Kafka): Distributed, append-only log where consumers track their own offsets. Best for real-time analytics pipelines and event replayability.

Handling Distributed Consistency

Two-Phase Commit (2PC): Blocking consensus protocol for cross-database ACID guarantees. Avoid in highly distributed systems due to bottleneck locks.
Saga Pattern: A sequence of local microservice transactions coordinated via events, using compensating operations to roll back on failure. Best for complex distributed workflows.

6. Resilience & Fault Tolerance Patterns

Circuit Breaker: Automatically trips and fails fast when a downstream dependency experiences degradation, preventing cascading failure.
Rate Limiter (Token Bucket): Enforces request caps to protect services from traffic surges and abuse.
Exponential Backoff with Jitter: Adds randomized delay intervals to retries to prevent "retry storms" on recovering systems.

📌 Note: This cheat sheet covers the foundational concepts. The full 10-page System Design Interview Guide contains end-to-end architectural diagrams, detailed mathematical derivations, step-by-step trade-off frameworks, and deep-dive case studies for Uber, Netflix, and Twitter.

💡 Get the Full 10-Page System Design Guide

Subscribe to The Tech Builder Newsletter to instantly get the full, unredacted guide for free.

Every week, subscribers receive:

🎯 Deep-dive production postmortems & system design trade-off analysis.
🛠️ Real-world architecture playbooks for Senior ICs, Tech Leads, and Architects.
🎁 Instant Bonus: Get the Full 6-Month Prep Tracker & Study Schedule + 10-Page System Design Cheat Sheet immediately upon subscribing.

👉 Get the Full System Design Cheat Sheet

How to Land USD-Compensated Global Remote Engineering Roles

The Architect — Sun, 26 Jul 2026 16:35:43 +0000

Landing a full-time, USD-compensated remote engineering role at a global product company isn't about applying to 500 job postings on standard job boards. It requires treating your job search like an outbound sales engine.

Here is the strategic framework to position your brand, source inbound recruiter leads, and convert global remote opportunities.

Phase 1: Optimize Your Profile for Global Recruiters

Global recruiters search for specific signals when sourcing senior remote engineers. If your profile reads like a resume summary of tasks, you will be passed over.

1. Headline Optimization

Replace generic titles with clear domain authority and scale metrics:

❌ Software Engineer at Acme Corp
✅ Staff Backend Engineer | Distributed Systems & High-Throughput Pipelines (Golang / Kafka / K8s)

2. Proof-of-Work Bullet Points

Focus heavily on business impact, scale, and engineering complexity:

Quantify Scale: "Engineered a distributed ingestion pipeline handling 50k QPS with sub-50ms latency."
Highlight Trade-offs: "Migrated monolithic database to sharded PostgreSQL instances, reducing P99 latency by 40%."

Phase 2: Strategic Sourcing (Where the Real Jobs Are)

Avoid standard mass job boards. Focus on channels where high-paying remote companies actually recruit:

Direct Remote Platforms: Wellfound, Hacker News "Who is Hiring?", Remotive, Otta.
Inbound LinkedIn Sourcing: Turn on "Open to Work" (Recruiters Only) set strictly to target remote markets.
VC Portfolio Job Boards: Search job boards of top-tier VC firms (a16z, Sequoia, Y Combinator).

Phase 3: The Async Communication Test

In remote hiring pipelines, your written communication during initial recruiter outreach and technical screens is evaluated as a proxy for how you work in a distributed team.

Rules for Async Communication:

Be Concise and Direct: State the context, recommended solution, and trade-offs upfront.
Show Autonomy: Demonstrate that you can make high-judgment decisions across time zones without micromanagement.

💡 Level Up Your Engineering Career

If you found this guide valuable, consider subscribing to The Tech Builder Newsletter.

Every week, I send out:

🎯 Deep-dive production postmortems & system design breakdowns.
🛠️ Real-world engineering playbooks for Senior ICs, Tech Leads, and Architects.
🎁 Instant Bonus: Get our Secure Remote Job Guide + System Design Cheat Sheet free upon subscribing.

👉 Join developers reading The Tech Builder

The 6-Month Preparation Blueprint for L5–L7 Engineering Roles

The Architect — Sun, 26 Jul 2026 16:02:07 +0000

Transitioning from a mid-level engineer to an L5 (Senior), L6 (Staff), or L7 (Principal) role requires a fundamental mindset shift. You are no longer judged just on writing working code, but on evaluating trade-offs, architecture durability, and clean abstraction boundaries.

Here is the condensed 6-month roadmap designed to cover DSA, Low-Level Design (LLD), and High-Level System Design (HLD) systematically without burnout.

Month 1–2: Master DSA Patterns & Invariants (Not LeetCode Memorization)

Stop solving random LeetCode problems. Focus on pattern invariants that apply to hundreds of problems.

Core Focus Areas:

Two Pointers & Sliding Window: Array boundary mutations, sub-array optimization problems.
Monotonic Stack & Queue: Next Greater Element, boundary range queries ($O(N)$ time complexity).
Graph Traversal & Topo Sort: Cyclic dependency resolution, shortest path algorithms (Dijkstra, A*).
Dynamic Programming: Identify state transitions ($DP[i][j]$) rather than guessing memoization.

Month 3–4: Low-Level Design (LLD) & Object-Oriented Clean Code

LLD interviews test your ability to structure maintainable, extensible codebases live on a whiteboard or pair-programming session.

Core Focus Areas:

SOLID Principles in Practice: Refactoring tightly coupled inheritance into composition.
Essential Design Patterns: Strategy, Observer, State, Factory, Adapter, Decorator.
Concurrency & Multithreading: Thread-safe data structures, deadlock prevention, read-write locks, producer-consumer queues.

Month 5: High-Level System Design (HLD) & Distributed Trade-offs

HLD tests whether you understand how real-world production systems scale, break, and recover under load.

Core Focus Areas:

Storage Systems: Relational vs. Document vs. Key-Value vs. Wide-Column (Cassandra).
Scalability Mechanics: Horizontal vs. Vertical scaling, Database Sharding, Read Replicas, Consistent Hashing.
Resilience Patterns: Circuit Breakers, Exponential Backoff with Jitter, Bulkheads, Rate Limiting (Token Bucket).
Async Pipelines: Event Streams (Kafka) vs. Task Queues (RabbitMQ).

Month 6: Behavioral Strategy & Mock Interviews

Senior and Staff roles heavily weight behavioral signals and architecture defense.

Core Focus Areas:

STAR Framework Refinement: Prepare stories covering conflict resolution, system outages, and technical debt management.
Peer Mock Interviews: Conduct at least 2 mock interviews per week (1 HLD, 1 Coding/LLD).

💡 Level Up Your Engineering Career

If you found this roadmap useful, consider subscribing to The Tech Builder Newsletter.

Every week, I send out:

🎯 Deep-dive production postmortems & system design breakdowns.
🛠️ Real-world engineering playbooks for Senior ICs, Tech Leads, and Architects.
🎁 Instant Bonus: Get the Full 6-Month Prep Tracker & Study Schedule + 10-Page System Design Cheat Sheet immediately upon subscribing.

👉 Join developers reading The Tech Builder

DEV Community: The Architect

SOLID Principles Cheat Sheet

SOLID Principles Cheat Sheet

1. Single Responsibility Principle (SRP)

Consequences of Violating SRP

SRP Across Architectural Boundaries

SRP Anti-Patterns

Class-Level Anti-Pattern: Hyper-Fragmentation

Microservice-Level Anti-Pattern: Over-Servicicing

Code Example: SRP Refactoring

❌ BAD DESIGN: Monolithic OrderProcessor

✅ REFACTORED CODE: Domain-Separated Architecture

2. Open/Closed Principle (OCP)

Real-World Scenario

Code Example: OCP Refactoring

❌ BAD DESIGN: Rigid Conditional Checks

✅ REFACTORED CODE: Open for Extension via Strategy Pattern

Architectural Trade-Offs of OCP

Scaling OCP to Microservices & Distributed Systems

Rigid Architecture (Direct Synchronous Calls)

OCP Microservice Architecture (Pub/Sub Event Bus)

Architectural Choice: Synchronous Dispatcher vs. Distributed Pub/Sub

Decision Framework: When to Use Which?

Choose Approach A (In-Process Dispatcher) IF:

Choose Approach B (Distributed Pub/Sub) IF:

The Production Reality: Hybrid Pattern

3. Liskov Substitution Principle (LSP)

Real-World Example: Non-Refundable Payment Methods

Code Example: LSP Refactoring

❌ BEFORE (Violates LSP)

✅ AFTER (LSP Compliant via Interface Segregation)

LSP at the Microservice Boundary

4. Interface Segregation Principle (ISP)

Benefits of ISP

Code Example: ISP Refactoring

❌ BEFORE (Violates ISP)

✅ AFTER (ISP Compliant)

5. Dependency Inversion Principle (DIP)

Benefits of DIP

Code Example: DIP Refactoring

❌ BEFORE (Violates DIP)

✅ AFTER (DIP Compliant)

Conclusion & Architecture Roadmap

💡 Get the Full 10-Page System Design Guide

The 10-Minute System Design Interview Cheat Sheet

1. Estimation Cheat Sheet & Core Metrics

Latency Scale

QPS & Capacity Multipliers

2. Database Selection Matrix

3. Caching & Data Storage Strategies

Caching Strategies

Common Cache Pitfalls

4. Networking Protocols & Load Balancing

API Protocols

Load Balancing

5. Async Pipelines & Distributed Transactions

Messaging Infrastructure

Handling Distributed Consistency

6. Resilience & Fault Tolerance Patterns

💡 Get the Full 10-Page System Design Guide

How to Land USD-Compensated Global Remote Engineering Roles

Phase 1: Optimize Your Profile for Global Recruiters

1. Headline Optimization

2. Proof-of-Work Bullet Points

Phase 2: Strategic Sourcing (Where the Real Jobs Are)

Phase 3: The Async Communication Test

Rules for Async Communication:

💡 Level Up Your Engineering Career

The 6-Month Preparation Blueprint for L5–L7 Engineering Roles

Month 1–2: Master DSA Patterns & Invariants (Not LeetCode Memorization)

Core Focus Areas:

Month 3–4: Low-Level Design (LLD) & Object-Oriented Clean Code

Core Focus Areas:

Month 5: High-Level System Design (HLD) & Distributed Trade-offs

Core Focus Areas:

Month 6: Behavioral Strategy & Mock Interviews

Core Focus Areas:

💡 Level Up Your Engineering Career

❌ BAD DESIGN: Monolithic `OrderProcessor`