Technology Selection

Which technology to pick and why. Use this after NFRs tell you what the system needs — these are the decision criteria that map requirements to specific tools.

Database

Choose the right database for your access pattern, consistency requirements, and scale. Default to SQL unless you have a clear reason not to.

SQL vs NoSQL — Pick One First

The most important database decision — make this call before comparing specific products.

Rule of thumb: Default to SQL (PostgreSQL). Only switch to NoSQL when you have a clear reason — scale, schema flexibility, or access pattern that SQL handles poorly.

SQL Databases

Relational databases with ACID guarantees — pick based on scale needs and whether you're on AWS or self-hosted.

NoSQL Databases

Databases optimized for specific access patterns — each trades ACID guarantees for a different combination of scale, flexibility, or query speed.

Database Decision Tree

Follow this path from requirements to a specific database choice in under 30 seconds.

CopyNeed ACID transactions across multiple tables?
├── Yes → SQL (PostgreSQL default)
│         ├── Need horizontal write scale? → CockroachDB or shard PostgreSQL
│         └── Managed + AWS? → Aurora
└── No → What's the access pattern?
          ├── High write throughput + time-ordered? → Cassandra
          ├── Key lookups + AWS + auto-scale? → DynamoDB
          ├── Flexible/nested documents? → MongoDB
          ├── Cache + data structures + sub-ms? → Redis
          └── Timestamped metrics/sensor data? → InfluxDB / TimescaleDB

Message Queue

Choose the right queue or stream based on durability needs, throughput, routing complexity, and whether you want managed infrastructure.

Kafka vs SQS vs RabbitMQ vs Redis Pub/Sub

Four queue options compared across the dimensions that matter most for picking one in an interview.

When to use each:

• Kafka: High throughput event streaming. Multiple independent consumers. Replay needed (audit, ML pipelines). Event sourcing. Use for: Uber GPS, analytics pipelines, activity feeds.
• SQS: Simple async task queue. AWS ecosystem. Don't want to manage infrastructure. Each task processed by one worker. Use for: email sending, image resizing, background jobs.
• RabbitMQ: Complex routing rules. Priority queues. Message TTL. Fan-out with filtering. Use for: task routing across microservices, job prioritization.
• Redis Pub/Sub: Real-time fan-out with no durability requirement. Extremely low latency. Use for: WebSocket fan-out, live notifications, chat room broadcasting.

Rule of thumb: Kafka for streams, SQS for tasks, RabbitMQ for routing, Redis Pub/Sub for real-time broadcast.

Cache

Redis is the default choice for almost every caching use case — pick Memcached only if you need pure string throughput with no other features.

Redis vs Memcached

Feature-by-feature comparison — Redis wins in almost every column, but Memcached has lower overhead for pure get/set workloads.

When to choose Memcached: Pure simple string cache with extremely high get/set throughput and no need for any Redis features. Rare — Redis handles this fine for most systems.

When to choose Redis: Everything else. Sorted sets, pub/sub, geo, persistence, Lua scripts, cluster support. Redis is the default choice.

Load Balancer

Distributes traffic across app servers — the choice depends on protocol, latency requirements, and whether you're on AWS or self-managed.

Rule of thumb: Default to AWS ALB for web and API traffic. Use NLB only when you need sub-millisecond latency, UDP, or a static IP. Use Nginx/HAProxy when you're not on AWS or need custom configuration.

API Gateway

A single entry point for all client requests. Its primary purpose is routing — directing requests to the right backend service. Middleware (auth, rate limiting, logging) is secondary. Clients don't need to know your internal service structure.

Request flow:

CopyRequest → Validate → Middleware → Route → Backend → Transform → Cache → Response

What it handles (middleware responsibilities):

• Auth — JWT validation, API keys, OAuth token introspection
• Rate limiting — per user, per IP, per endpoint (see building_blocks for algorithms)
• SSL termination — decrypt HTTPS at gateway, plain HTTP internally (offloads CPU from backends)
• Request/response transformation — HTTP ↔ gRPC protocol translation, header injection, body format conversion
• Caching — cache full responses for non-user-specific endpoints (e.g. product catalog, public feeds). Never cache user-specific data.
• Logging and distributed tracing — inject trace IDs, forward to Datadog/Prometheus
• Circuit breaker — fail fast to a struggling backend service (see Reliability Patterns in building_blocks)

Two LB layers in practice:

Copy[Clients]
    ↓
[Load Balancer]       ← distributes across gateway instances (AWS ALB)
    ↓
[API Gateway cluster] ← stateless, scales horizontally
    ↓
[Backend Services]    ← gateway load-balances across service instances

The gateway is stateless — no session data stored in the gateway itself. This makes it trivially horizontally scalable: add more instances behind the ALB.

Routing example:

Copy/users/*      →  user-service:8080
/orders/*     →  order-service:8081
/payments/*   →  payment-service:8082

Protocol translation: Gateway can accept HTTP from clients and call backends over gRPC. Backend services use the most efficient protocol without the client needing to know.

Global distribution: For global users, deploy gateway instances in multiple regions + GeoDNS to route each user to the nearest gateway — same strategy as CDN edge nodes.

Technology options:

When you don't need one: Single-service apps, internal APIs, or when your app server already handles auth and rate limiting cleanly. A gateway adds a hop and complexity — only add it when cross-cutting logic would otherwise be duplicated across many services.

Real systems — what the gateway actually does:

Interview tip: Say "I'll add an API Gateway for routing and middleware" then move on. Don't over-explain the gateway — it's not the interesting part of the design. You can draw the Load Balancer and API Gateway as a single entry-point box if the interviewer doesn't ask about them specifically.

Rule of thumb: Microservices or multiple client types → API Gateway. Single service or internal API → skip it.

Object Storage

For files, images, and video. All major clouds have a native object store — pick based on your cloud ecosystem, then consider cost and compliance.

By cloud provider:

The patterns covered in this guide — presigned URLs, two-bucket strategy, signed CDN URLs, multipart upload — are identical across all three. Only the API names differ.

Cross-cloud comparison — object storage itself:

Rule of thumb: Use whichever matches your cloud ecosystem — S3 on AWS, GCS on GCP, Blob Storage on Azure. Switch to Cloudflare R2 if egress costs are significant regardless of cloud. Self-host only for compliance or data residency requirements.

Search

Match your search solution to dataset size and operational tolerance — zero infra for small datasets, Elasticsearch for billions of documents.

When to use each:

• PostgreSQL FTS: Search on < 10M rows, exact-word matching is acceptable, no typo tolerance needed. Already on Postgres — zero extra infra. Use tsvector + GIN index; LIKE '%keyword%' forces a full table scan and should never be used at scale.
• Elasticsearch: Complex search, fuzzy matching, faceted filtering, log analytics, autocomplete at scale. Worth the ops cost.
• Typesense / Meilisearch: Fast autocomplete/search for smaller datasets, typo tolerance out of the box, much simpler than Elasticsearch.

Keeping Elasticsearch in sync with PostgreSQL:

The hardest part of adding Elasticsearch is keeping it consistent with your source-of-truth DB. Options ranked best to worst:

CDC wins because it captures changes from anywhere — DB migrations, admin scripts, other services — not just your application code. Debezium reads the PostgreSQL WAL, publishes change events, and an ES consumer indexes them. Near real-time with no application code changes required.

Quick Reference — Decision Summary

One row per requirement — the fastest path from what you need to which technology to name in an interview.