MONOPOLY — Technology Decision Matrix
Table of Contents
- Database Selection
- Cache Selection
- Message Queue / Event Streaming
- API Protocol
- Search Engine
- Object Storage
- Container Orchestration
- Load Balancer
- Observability Stack
- CDN
1. Database Selection
Relational (SQL)
| Database |
Best For |
Avoid When |
Scale Ceiling |
| PostgreSQL |
Complex queries, JSONB, GIS, strong consistency, most default use cases |
Ultra-high write throughput (>100K writes/s) |
~10TB single node; use Citus for horizontal |
| MySQL / MariaDB |
Read-heavy apps, legacy systems, WordPress/Drupal ecosystem |
Complex queries, full ACID at scale |
~10TB; use Vitess for sharding |
| CockroachDB |
Global distributed SQL, geo-partitioning, multi-region |
Simple single-region apps (overkill) |
Petabyte-scale |
| PlanetScale |
MySQL-compatible, serverless, branch-based workflow |
Complex JOINs (foreign keys removed by design) |
Very high — Vitess based |
| Amazon Aurora |
AWS-native apps, managed PostgreSQL/MySQL, high availability |
Non-AWS environments |
Up to 128TB, 15 replicas |
NoSQL
| Database |
Best For |
Avoid When |
Scale Ceiling |
| MongoDB |
Flexible schema, document model, prototyping |
Financial transactions requiring ACID |
Petabyte-scale with sharding |
| DynamoDB |
Key-value at massive scale, AWS-native, serverless, predictable latency |
Complex queries, ad-hoc analytics, JOINs |
Unlimited (AWS-managed) |
| Cassandra |
Write-heavy, time-series, wide-column, geographically distributed |
Read-heavy with complex queries |
Petabyte-scale; used at Apple, Netflix |
| Redis |
Cache, sessions, leaderboards, pub/sub, rate limiting |
Primary data store for complex models |
~1TB per node; cluster for more |
| Elasticsearch |
Full-text search, log aggregation, analytics |
Primary database (durability risk) |
Petabyte-scale with clusters |
| InfluxDB |
Time-series metrics, IoT, monitoring data |
General-purpose data |
Very high write throughput |
| Neo4j |
Graph data, social networks, recommendation engines, fraud detection |
Non-graph data (overhead not worth it) |
Billions of nodes |
Decision Framework
Is your data relational (joins, foreign keys, transactions)?
YES → Start with PostgreSQL
NO → Continue below
Is your primary access pattern key-value?
YES, need extreme scale → DynamoDB or Cassandra
YES, need speed/cache → Redis
Is your data document-shaped (nested, flexible schema)?
YES → MongoDB
Is it time-series (metrics, logs, IoT)?
YES → InfluxDB or TimescaleDB
Is it graph (relationships are the data)?
YES → Neo4j
Is it search?
YES → Elasticsearch / OpenSearch
2. Cache Selection
| Technology |
Best For |
Max Single Node |
Cluster Support |
| Redis |
Sessions, leaderboards, pub/sub, complex data structures, Lua scripting |
~1TB RAM |
Yes (Redis Cluster, Redis Sentinel) |
| Memcached |
Simple key-value, multi-threaded, large object cache |
~64GB RAM |
Yes (client-side sharding) |
| Varnish |
HTTP reverse proxy cache, full-page caching |
RAM bound |
Limited |
| CloudFront / CDN |
Static assets, edge caching globally |
N/A (distributed) |
Built-in global distribution |
Default recommendation: Redis — more features, better ecosystem, active development.
Use Memcached only when: you need multi-threading for CPU-bound caching workloads and don't need data structures beyond string.
3. Message Queue / Event Streaming
| Technology |
Model |
Best For |
Throughput |
Retention |
| Apache Kafka |
Log-based streaming |
Event sourcing, high-throughput pipelines, replay, audit |
Millions msg/s |
Days to forever |
| RabbitMQ |
AMQP message broker |
Task queues, RPC, routing, fanout |
50K–100K msg/s |
Until consumed |
| AWS SQS |
Managed queue |
AWS-native, simple task queue, serverless |
Very high (managed) |
Up to 14 days |
| AWS SNS |
Pub/sub notification |
Fan-out to many subscribers (email, SMS, Lambda, SQS) |
Very high (managed) |
No retention |
| Google Pub/Sub |
Managed streaming |
GCP-native, global, serverless |
Very high (managed) |
Up to 7 days |
| Redis Pub/Sub |
In-memory pub/sub |
Real-time notifications, low latency, fire-and-forget |
Very high |
None (no retention) |
| NATS |
Lightweight messaging |
IoT, microservices, low latency |
Very high |
JetStream adds retention |
Decision Matrix
Need event replay / audit trail?
YES → Kafka or Kinesis
Need simple task queue with retries and DLQ?
AWS shop → SQS
Self-hosted → RabbitMQ
Need real-time pub/sub with no persistence?
Redis Pub/Sub or NATS
Need fan-out to multiple consumers?
Kafka (consumer groups) or SNS → SQS fan-out
Need < 5 minutes
1---2name: tech-matrix3description: Reference document for monopoly tech-matrix.4---567# MONOPOLY — Technology Decision Matrix89## Table of Contents101. Database Selection112. Cache Selection123. Message Queue / Event Streaming134. API Protocol145. Search Engine156. Object Storage167. Container Orchestration178. Load Balancer189. Observability Stack1910. CDN2021---2223## 1. Database Selection2425### Relational (SQL)2627| Database | Best For | Avoid When | Scale Ceiling |28|----------|----------|------------|---------------|29| **PostgreSQL** | Complex queries, JSONB, GIS, strong consistency, most default use cases | Ultra-high write throughput (>100K writes/s) | ~10TB single node; use Citus for horizontal |30| **MySQL / MariaDB** | Read-heavy apps, legacy systems, WordPress/Drupal ecosystem | Complex queries, full ACID at scale | ~10TB; use Vitess for sharding |31| **CockroachDB** | Global distributed SQL, geo-partitioning, multi-region | Simple single-region apps (overkill) | Petabyte-scale |32| **PlanetScale** | MySQL-compatible, serverless, branch-based workflow | Complex JOINs (foreign keys removed by design) | Very high — Vitess based |33| **Amazon Aurora** | AWS-native apps, managed PostgreSQL/MySQL, high availability | Non-AWS environments | Up to 128TB, 15 replicas |3435### NoSQL3637| Database | Best For | Avoid When | Scale Ceiling |38|----------|----------|------------|---------------|39| **MongoDB** | Flexible schema, document model, prototyping | Financial transactions requiring ACID | Petabyte-scale with sharding |40| **DynamoDB** | Key-value at massive scale, AWS-native, serverless, predictable latency | Complex queries, ad-hoc analytics, JOINs | Unlimited (AWS-managed) |41| **Cassandra** | Write-heavy, time-series, wide-column, geographically distributed | Read-heavy with complex queries | Petabyte-scale; used at Apple, Netflix |42| **Redis** | Cache, sessions, leaderboards, pub/sub, rate limiting | Primary data store for complex models | ~1TB per node; cluster for more |43| **Elasticsearch** | Full-text search, log aggregation, analytics | Primary database (durability risk) | Petabyte-scale with clusters |44| **InfluxDB** | Time-series metrics, IoT, monitoring data | General-purpose data | Very high write throughput |45| **Neo4j** | Graph data, social networks, recommendation engines, fraud detection | Non-graph data (overhead not worth it) | Billions of nodes |4647### Decision Framework4849```50Is your data relational (joins, foreign keys, transactions)?51 YES → Start with PostgreSQL52 NO → Continue below5354Is your primary access pattern key-value?55 YES, need extreme scale → DynamoDB or Cassandra56 YES, need speed/cache → Redis5758Is your data document-shaped (nested, flexible schema)?59 YES → MongoDB6061Is it time-series (metrics, logs, IoT)?62 YES → InfluxDB or TimescaleDB6364Is it graph (relationships are the data)?65 YES → Neo4j6667Is it search?68 YES → Elasticsearch / OpenSearch69```7071---7273## 2. Cache Selection7475| Technology | Best For | Max Single Node | Cluster Support |76|------------|----------|----------------|----------------|77| **Redis** | Sessions, leaderboards, pub/sub, complex data structures, Lua scripting | ~1TB RAM | Yes (Redis Cluster, Redis Sentinel) |78| **Memcached** | Simple key-value, multi-threaded, large object cache | ~64GB RAM | Yes (client-side sharding) |79| **Varnish** | HTTP reverse proxy cache, full-page caching | RAM bound | Limited |80| **CloudFront / CDN** | Static assets, edge caching globally | N/A (distributed) | Built-in global distribution |8182**Default recommendation: Redis** — more features, better ecosystem, active development.8384Use **Memcached** only when: you need multi-threading for CPU-bound caching workloads and don't need data structures beyond string.8586---8788## 3. Message Queue / Event Streaming8990| Technology | Model | Best For | Throughput | Retention |91|------------|-------|----------|------------|-----------|92| **Apache Kafka** | Log-based streaming | Event sourcing, high-throughput pipelines, replay, audit | Millions msg/s | Days to forever |93| **RabbitMQ** | AMQP message broker | Task queues, RPC, routing, fanout | 50K–100K msg/s | Until consumed |94| **AWS SQS** | Managed queue | AWS-native, simple task queue, serverless | Very high (managed) | Up to 14 days |95| **AWS SNS** | Pub/sub notification | Fan-out to many subscribers (email, SMS, Lambda, SQS) | Very high (managed) | No retention |96| **Google Pub/Sub** | Managed streaming | GCP-native, global, serverless | Very high (managed) | Up to 7 days |97| **Redis Pub/Sub** | In-memory pub/sub | Real-time notifications, low latency, fire-and-forget | Very high | None (no retention) |98| **NATS** | Lightweight messaging | IoT, microservices, low latency | Very high | JetStream adds retention |99100### Decision Matrix101102```103Need event replay / audit trail?104 YES → Kafka or Kinesis105106Need simple task queue with retries and DLQ?107 AWS shop → SQS108 Self-hosted → RabbitMQ109110Need real-time pub/sub with no persistence?111 Redis Pub/Sub or NATS112113Need fan-out to multiple consumers?114 Kafka (consumer groups) or SNS → SQS fan-out115116Need < 5 minutes
sickn33