tech-matrix

name: tech-matrixdescription: Reference document for monopoly tech-matrix.source: communitydate_added: "2026-06-14"risk: safereports-to: monopoly

MONOPOLY — Technology Decision Matrix

When to Use

• Use this skill when the task matches this description: Reference document for monopoly tech-matrix.

Use this as a qualitative candidate list. Verify exact editions, versions, service quotas and pricing with current primary docs; fixed throughput, memory, storage, edge counts and prices are not established capacity evidence. Decide from measured workload, operations and failure tests rather than user/team counts.

Table of Contents

1. Database Selection
2. Cache Selection
3. Message Queue / Event Streaming
4. API Protocol
5. Search Engine
6. Object Storage
7. Container Orchestration
8. Load Balancer
9. Observability Stack
10. CDN

---

1. Database Selection

Relational (SQL)

NoSQL

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

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

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 a managed AWS-native task queue with explicit retry/latency objectives?
  SQS

Volume > 1 million messages/second?
  Kafka (self-hosted) or Kinesis (managed)

---

4. API Protocol

Default recommendation:

• External / public: REST
• Internal service-to-service: gRPC
• Real-time features: WebSocket or SSE

---

5. Search Engine

Selection: Benchmark relevance, query mix, indexes, language support, data size and update latency. Document count alone does not determine when to leave PostgreSQL FTS.

---

6. Object Storage

Compare AWS S3, Cloudflare R2, GCS, Azure Blob, Backblaze B2 and self-hosted S3-compatible systems against region/residency, consistency/API compatibility, operations, availability, replication and object lifecycle needs. Build a dated cost model including storage, requests, retrieval, inter-region transfer, internet egress and connected compute. Zero egress for one service does not make the full delivery path free. Use current calculators; this reference supplies no price quote.

---

7. Container Orchestration

Startup default: ECS + Fargate (zero cluster management). Scale decision: Choose orchestration from operational requirements and team capacity, not fixed engineer/service counts.

---

8. Load Balancer

---

9. Observability Stack

Metrics

Logging

Distributed Tracing

Recommended open-source stack: Prometheus + Grafana + Loki + Jaeger (all integrate via OpenTelemetry) Recommended managed stack: Datadog (expensive but unified) or Grafana Cloud

---

10. CDN

Default recommendation: Cloudflare for most use cases (best value, DDoS included, free SSL, Workers for edge compute).

---

Capacity evidence

Use the bundled capacity planning reference at skills/monopoly/scale-benchmarks/SKILL.md to define workload measurements. No fixed product throughput benchmark is established here.

Limitations

• This is a reference document and may not cover all edge cases. Always verify architectures before production.