StreamHub runs on Java/Spring Boot services, Postgres, Redis, Kafka, and S3 on AWS EKS. That stack wasn't picked because it's "best" — it matched the team's expertise, hiring pool, and the need for mature ecosystem tooling at streaming scale.
Decision framework
Five lenses for every choice
- Team skill: What can you ship and operate in 90 days with your current team?
- Scale target: 1K QPS and 1M QPS need different databases and queues.
- Operational burden: Managed services vs self-hosted — engineer time is the hidden cost.
- Ecosystem: Libraries, hiring pool, community support, cloud integration.
- Migration cost: Today's choice becomes tomorrow's legacy — prefer boring technology.
Language and runtime
| Aspect | Java / Kotlin (Spring Boot) | Go |
|---|---|---|
| StreamHub fit | Primary backend — team expertise, mature ecosystem | Edge services, high-concurrency proxies |
| Throughput | Excellent with virtual threads (Java 21+) | Excellent goroutine concurrency |
| Startup time | Slower cold start (~2–5 s) | Fast (~100 ms) — better for scale-to-zero |
| Hiring | Large pool for enterprise backends | Strong in infra/DevOps roles |
| When to pick | Complex business logic, large teams | CLI tools, sidecars, lightweight services |
StreamHub fit
Java / Kotlin (Spring Boot)Primary backend — team expertise, mature ecosystemGoEdge services, high-concurrency proxiesThroughput
Java / Kotlin (Spring Boot)Excellent with virtual threads (Java 21+)GoExcellent goroutine concurrencyStartup time
Java / Kotlin (Spring Boot)Slower cold start (~2–5 s)GoFast (~100 ms) — better for scale-to-zeroHiring
Java / Kotlin (Spring Boot)Large pool for enterprise backendsGoStrong in infra/DevOps rolesWhen to pick
Java / Kotlin (Spring Boot)Complex business logic, large teamsGoCLI tools, sidecars, lightweight services
Database selection
| Workload | Pick | Why not the alternative |
|---|---|---|
| Transactional core (users, payments) | Postgres | ACID, joins, mature — not DynamoDB (no joins) |
| Session cache, rate limits | Redis | Sub-ms latency — not Postgres (too slow for counters) |
| Chat message history at scale | Cassandra / DynamoDB | Write-heavy, partition by conversation — not Postgres at billions of rows |
| Full-text search | Elasticsearch | Inverted index, autocomplete — not Postgres LIKE |
| Analytics / event log | ClickHouse / BigQuery | Columnar aggregation — not OLTP Postgres |
Transactional core (users, payments)
PickPostgresWhy not the alternativeACID, joins, mature — not DynamoDB (no joins)Session cache, rate limits
PickRedisWhy not the alternativeSub-ms latency — not Postgres (too slow for counters)Chat message history at scale
PickCassandra / DynamoDBWhy not the alternativeWrite-heavy, partition by conversation — not Postgres at billions of rowsFull-text search
PickElasticsearchWhy not the alternativeInverted index, autocomplete — not Postgres LIKEAnalytics / event log
PickClickHouse / BigQueryWhy not the alternativeColumnar aggregation — not OLTP Postgres
Polyglot persistence — different stores for different access patterns, not one DB for everything.
Cache and queue
StreamHub choices
- Cache: Redis Cluster — team knows it, ElastiCache is managed, supports rate limiting + pub/sub + sorted sets.
- Task queue: RabbitMQ for transcode jobs — priority queues, dead-letter exchanges, simpler ops than Kafka for point-to-point.
- Event stream: Kafka for viewer analytics and cross-service events — replay, retention, high throughput.
- Object store: S3 — durability, presigned uploads, lifecycle policies, CDN integration.
Cloud and deployment
StreamHub production architecture (AWS)
| Layer | StreamHub choice | Alternative considered |
|---|---|---|
| Compute | AWS EKS (Kubernetes) | ECS simpler but less portable |
| CDN | CloudFront | Cloudflare for DDoS + CDN combo |
| Load balancer | ALB (L7) | NLB for WebSocket-heavy paths |
| Secrets | AWS Secrets Manager | Vault for multi-cloud |
| Observability | OpenTelemetry → Grafana stack | Datadog for managed (higher cost) |
Compute
StreamHub choiceAWS EKS (Kubernetes)Alternative consideredECS simpler but less portableCDN
StreamHub choiceCloudFrontAlternative consideredCloudflare for DDoS + CDN comboLoad balancer
StreamHub choiceALB (L7)Alternative consideredNLB for WebSocket-heavy pathsSecrets
StreamHub choiceAWS Secrets ManagerAlternative consideredVault for multi-cloudObservability
StreamHub choiceOpenTelemetry → Grafana stackAlternative consideredDatadog for managed (higher cost)
Buy vs build
| Aspect | Buy (managed) | Build (self-hosted) |
|---|---|---|
| When | Commodity capability (auth, email, payments) | Competitive differentiator (recommendation engine) |
| Cost model | Per-unit pricing; predictable early | Engineer time + infra; cheaper at massive scale |
| StreamHub buys | Stripe (payments), SendGrid (email), Auth0 (OAuth) | — |
| StreamHub builds | — | Stream discovery, live transcoding, chat delivery |
When
Buy (managed)Commodity capability (auth, email, payments)Build (self-hosted)Competitive differentiator (recommendation engine)Cost model
Buy (managed)Per-unit pricing; predictable earlyBuild (self-hosted)Engineer time + infra; cheaper at massive scaleStreamHub buys
Buy (managed)Stripe (payments), SendGrid (email), Auth0 (OAuth)Build (self-hosted)—StreamHub builds
Buy (managed)—Build (self-hosted)Stream discovery, live transcoding, chat delivery
Quick recall
Everything you need if you only revisit this box.
- Stack choices follow team skill, scale target, ops burden, ecosystem, and migration cost.
- Polyglot persistence: Postgres for transactions, Redis for cache, Cassandra for write-heavy, ES for search.
- RabbitMQ for tasks, Kafka for events — hybrid messaging is normal at scale.
- Buy commodity (auth, payments, email); build differentiators (recommendation, transcoding).
- Managed services save engineer time early; self-host when cost or control demands it at scale.
- "Boring technology" that your team can operate beats trendy technology you can't debug at 3 AM.
Test yourself
Answer these before moving on — recall is what makes it stick.