What are common System Design techniques?

System Design techniques are not just about drawing boxes and arrows—they’re the repeatable thinking tools engineers rely on to turn ambiguous problems into scalable systems. While some engineers memorize architectures, the best ones use System Design techniques to reason, prioritize, and communicate with clarity.

In System Design interviews and real-world architecture alike, these techniques help you reduce noise, manage tradeoffs, and make better decisions under constraints.

Let’s examine the most impactful System Design techniques in architecture, scalability, reliability, and tradeoff analysis.

High-level design approaches

Top-down design begins by defining the system’s goals and decomposing them into subsystems.

• Start with core requirements and constraints.
• Break the system into major components, then into individual services.
• Useful for large, complex systems that demand a clear roadmap.

Bottom-up design starts with building blocks:

• Identify reusable services or patterns you’ve already built.
• Integrate those into higher-level functionality.
• Effective when you already have mature components or libraries.

Great engineers often blend both, zooming in and out of abstraction levels based on the problem.

Architectural patterns

Different problems demand different structures. Common architecture patterns include:

Monolith

• One unified codebase.
• Simple to build and test, but hard to scale or deploy independently.

Microservices

• Decoupled, independently deployable services.
• Enables team autonomy and scalability, but adds complexity in communication and observability.

Event-driven systems

• Services communicate via asynchronous events.
• Ideal for real-time, loosely coupled workflows.

Serverless

• Cloud provider manages compute.
• Simplifies scaling, but limits control and can introduce vendor lock-in.

CQRS (Command Query Responsibility Segregation)

• Splits read and write operations into separate models.
• Useful for improving read performance and managing complex domain logic.

Circuit Breakers

• Prevent cascading failures by halting requests to failing services.
• Improves resilience and gives dependent systems time to recover.

Your architecture should match your product’s evolution, engineering maturity, and team structure.

Scalability techniques

Scaling is not just about infrastructure, it’s about applying the right System Design techniques:

Horizontal scaling: Add more machines to distribute load (e.g., web servers, databases).

Vertical scaling: Add more resources (CPU, memory) to a single machine, which is easier, but limited.

Sharding: Split data across nodes (by user ID, geo, etc.). Complex, but essential at scale.

Caching: Use Redis or Memcached to store hot data and reduce database load. Combine with strategies like write-through or write-behind.

Use back-of-the-envelope math to justify when and how to scale.

Database strategies

Designing data models is where many engineers struggle. Apply these choices deliberately:

SQL databases

• Structured schemas, strong consistency, transactional support.
• Ideal for OLTP and business-critical systems.

NoSQL databases

• Schema-less or flexible data models (e.g., documents, key-value, wide-column).
• Favor availability and scalability.

Normalization

• Reduces redundancy, good for consistency and updates.

Denormalization

• Increases read performance by duplicating data.
• Necessary in read-heavy or distributed systems.

Choose based on access patterns, not trends.

Design decision matrix: SQL vs NoSQL

Criteria	SQL	NoSQL
Schema	Fixed, predefined	Flexible, dynamic
Consistency	Strong (ACID)	Eventual (BASE)
Scaling	Vertical (traditional)	Horizontal (native)
Best for	Complex queries, transactions	Large-scale, unstructured data
Examples	MySQL, PostgreSQL	MongoDB, Cassandra

Fault tolerance and reliability

Good systems degrade gracefully. Design with:

Redundancy: Multiple instances of critical services and data.

Failover: Detect failures and switch to backups (active/passive or active/active).

Data replication: Sync data across zones/regions for resilience. Use synchronous replication for consistency, async for performance.

Design for chaos, not perfection. Assume components will fail.

Security and performance

Security is a design axis:

• Use RBAC/ABAC for access control.
• Encrypt data in transit (TLS) and at rest (AES-256).
• Use secure secret storage (e.g., AWS Secrets Manager).
• Add rate-limiting, input validation, and logging of auth failures.

Performance is equally strategic:

• Use CDNs to serve static assets near users.
• Index queries to reduce DB latency.
• Use async queues for non-critical flows.

Tradeoffs between performance and security are common; call them out explicitly.

Monitoring and deployment

Observable systems are reliable systems.

• Logging: Structure logs for parsing and debugging (e.g., JSON logs).
• Monitoring: Track latency, errors, QPS, saturation.
• Alerting: Threshold-based alerts for symptoms, not causes.
• CI/CD: Automate build/test/deploy. Add canary deploys and rollback support.
• IaC: Use Terraform/CloudFormation to version infrastructure.

Good monitoring tells you what broke before users do.

Tradeoff analysis

Tradeoffs are the soul of System Design.

CAP Theorem:

• Choose two: Consistency, Availability, Partition tolerance.
• CP (e.g., HBase): consistent but not always available.
• AP (e.g., Cassandra): available but eventually consistent.

Consistency models:

• Strong consistency: All reads reflect the latest write.
• Eventual consistency: Reads may be stale temporarily.

Simplicity vs. Flexibility

• Simple systems are easy to build/debug.
• Flexible systems are harder to reason about but more adaptable.

Strong engineers make tradeoffs visible and explain them.

Best practices and principles

Apply timeless design wisdom:

SOLID:

• Single Responsibility
• Open/Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion

DRY: Don’t repeat logic, centralize it.

KISS: Favor simpler solutions over clever ones.

YAGNI: Don’t build what you don’t need yet.

These aren’t rules. They’re pressure-tested heuristics.

Real-world example: Designing a scalable chat app

Let’s apply the above System Design techniques to build a scalable messaging system.

Requirements

• One-on-one and group messaging
• Typing indicators, delivery/read receipts
• Low-latency message delivery
• Scale to millions of users

Architecture overview

A scalable chat application needs both real-time responsiveness and long-term durability. The architecture can be broken down into several loosely coupled layers:

• Clients: Web and mobile clients establish persistent WebSocket connections for low-latency messaging. Fallback to HTTP long polling in limited environments.
  
• API Gateway: Acts as the single entry point to the system. Handles authentication, rate limiting, and routing requests to the appropriate service. Supports versioned APIs.
  
• Chat Service: Manages message handling, validation, storage triggers, and broadcasting. Designed as a stateless service behind a load balancer.
  
• Presence Service: Tracks user online/offline status in memory using Redis and broadcasts presence updates through pub/sub.
  
• Message Queue: Uses Kafka or RabbitMQ to ensure ordered, asynchronous message delivery. Buffers spikes in message volume and decouples services.
  
• Database: A combination of NoSQL (e.g., Cassandra for message storage) and SQL (e.g., PostgreSQL for user metadata). Supports sharding based on conversation ID.
  
• Cache: Redis/Memcached used to store frequently accessed data like recent conversations and active presence states.
  
• Notification Service: Integrates with push notification providers (APNs, FCM) to notify users of new messages when offline. Also handles email/persistent alerts.
  
• CDN/Media Service: Handles image/video uploads for chat. Large payloads are offloaded to blob storage (e.g., S3) with pre-signed URLs.

Techniques in use

• Event-driven architecture: Chat messages, presence updates, and notifications are all processed asynchronously via message queues and event buses.
  
• Sharding: Messages are partitioned across database shards by conversation or user ID, distributing load and improving parallelism.
  
• Replication: Data is synchronously replicated across multiple availability zones and asynchronously across regions to ensure high durability.
  
• Rate limiting: Applied at the gateway level per user/IP to prevent spamming, brute-force attacks, and abuse.
• Observability: End-to-end tracing across services using tools like OpenTelemetry. Logs are aggregated and analyzed with ELK or Datadog. Custom dashboards visualize message latency, error rates, and delivery success.
  
• CI/CD: Deployment pipelines with automated tests, canary deployments, and rollback safety. Infrastructure changes version-controlled via Terraform.
  
• CQRS: Separate write model (command) for message creation and read model (query) for chat history display. The read model is optimized for speed using pre-aggregated views.
  
• Circuit Breakers: Applied to all external service calls, including media storage and push notification providers, to prevent cascading failures.
  
• Feature flags: Gradual rollout of new features (e.g., voice messages or reactions) using toggle-based flags and real-time metrics.
  
• Security: End-to-end encryption for messages at rest and in transit. Token-based authentication (JWT) and fine-grained authorization using scoped API tokens.

This real-world design demonstrates how modular architecture and layered techniques make the chat app reliable, observable, and highly scalable across different workloads and geographies.

Final thoughts

There’s no perfect design template. However,  there are powerful thinking tools: the System Design techniques that guide you through ambiguity, scale, and tradeoffs.

Use them to drive structure, not just sketch architecture. Apply them to real problems, not just interviews. Because great engineers don’t just design systems. They design with systems thinking.