Technology Decision Guide
Decision frameworks and comparison matrices for common technology choices.
Decision Frameworks Index
- Database Selection
- Caching Strategy
- Message Queue Selection
- Authentication Strategy
- Frontend Framework Selection
- Cloud Provider Selection
- API Style Selection
1. Database Selection
SQL vs NoSQL Decision Matrix
| Factor |
Choose SQL |
Choose NoSQL |
| Data relationships |
Complex, many-to-many |
Simple, denormalized OK |
| Schema |
Well-defined, stable |
Evolving, flexible |
| Transactions |
ACID required |
Eventual consistency OK |
| Query patterns |
Complex joins, aggregations |
Key-value, document lookups |
| Scale |
Vertical (some horizontal) |
Horizontal first |
| Team expertise |
Strong SQL skills |
Document/KV experience |
Database Type Selection
Relational (SQL):
| Database |
Best For |
Avoid When |
| PostgreSQL |
General purpose, JSON support, extensions |
Simple key-value only |
| MySQL |
Web applications, read-heavy |
Complex queries, JSON-heavy |
| SQLite |
Embedded, development, small apps |
Concurrent writes, scale |
Document (NoSQL):
| Database |
Best For |
Avoid When |
| MongoDB |
Flexible schema, rapid iteration |
Complex transactions |
| CouchDB |
Offline-first, sync required |
High throughput |
Key-Value:
| Database |
Best For |
Avoid When |
| Redis |
Caching, sessions, real-time |
Persistence critical |
| DynamoDB |
Serverless, auto-scaling |
Complex queries |
Wide-Column:
| Database |
Best For |
Avoid When |
| Cassandra |
Write-heavy, time-series |
Complex queries, small scale |
| ScyllaDB |
Cassandra alternative, performance |
Small datasets |
Time-Series:
| Database |
Best For |
Avoid When |
| TimescaleDB |
Time-series with SQL |
Non-time-series data |
| InfluxDB |
Metrics, monitoring |
Relational queries |
Search:
| Database |
Best For |
Avoid When |
| Elasticsearch |
Full-text search, logs |
Primary data store |
| Meilisearch |
Simple search, fast setup |
Complex analytics |
Quick Decision Flow
Start
│
├─ Need ACID transactions? ──Yes──► PostgreSQL/MySQL
│
├─ Flexible schema needed? ──Yes──► MongoDB
│
├─ Write-heavy (>50K/sec)? ──Yes──► Cassandra/ScyllaDB
│
├─ Key-value access only? ──Yes──► Redis/DynamoDB
│
├─ Time-series data? ──Yes──► TimescaleDB/InfluxDB
│
├─ Full-text search? ──Yes──► Elasticsearch
│
└─ Default ──────────────────────► PostgreSQL
2. Caching Strategy
Cache Type Selection
| Type |
Use Case |
Invalidation |
Complexity |
| Read-through |
Frequent reads, tolerance for stale |
On write/TTL |
Low |
| Write-through |
Data consistency critical |
Automatic |
Medium |
| Write-behind |
High write throughput |
Async |
High |
| Cache-aside |
Fine-grained control |
Application |
Medium |
Cache Technology Selection
| Technology |
Best For |
Limitations |
| Redis |
General purpose, data structures |
Memory cost |
| Memcached |
Simple key-value, high throughput |
No persistence |
| CDN (CloudFront, Fastly) |
Static assets, edge caching |
Dynamic content |
| Application cache |
Per-instance, small data |
Not distributed |
Cache Patterns
Cache-Aside (Lazy Loading):
Read:
1. Check cache
2. If miss, read from DB
3. Store in cache
4. Return data
Write:
1. Write to DB
2. Invalidate cache
Write-Through:
Write:
1. Write to cache
2. Cache writes to DB
3. Return success
Read:
1. Read from cache (always hit)
TTL Guidelines:
| Data Type |
Suggested TTL |
| User sessions |
24-48 hours |
| API responses |
1-5 minutes |
| Static content |
24 hours - 1 week |
| Database queries |
5-60 minutes |
| Feature flags |
1-5 minutes |
3. Message Queue Selection
Queue Technology Comparison
| Feature |
RabbitMQ |
Kafka |
SQS |
Redis Streams |
| Throughput |
Medium (10K/s) |
Very High (100K+/s) |
Medium |
High |
| Ordering |
Per-queue |
Per-partition |
FIFO optional |
Per-stream |
| Durability |
Configurable |
Strong |
Strong |
Configurable |
| Replay |
No |
Yes |
No |
Yes |
| Complexity |
Medium |
High |
Low |
Low |
| Cost |
Self-hosted |
Self-hosted |
Pay-per-use |
Self-hosted |
Decision Matrix
| Requirement |
Recommendation |
| Simple task queue |
SQS or Redis |
| Event streaming |
Kafka |
| Complex routing |
RabbitMQ |
| Log aggregation |
Kafka |
| Serverless integration |
SQS |
| Real-time analytics |
Kafka |
| Request/reply pattern |
RabbitMQ |
When to Use Each
RabbitMQ:
- Complex routing logic (topic, fanout, headers)
- Request/reply patterns
- Priority queues
- Message acknowledgment critical
Kafka:
- Event sourcing
- High throughput requirements (>50K messages/sec)
- Message replay needed
- Stream processing
- Log aggregation
SQS:
- AWS-native applications
- Simple queue semantics
- Serverless architectures
- Don't want to manage infrastructure
Redis Streams:
- Already using Redis
- Moderate throughput
- Simple streaming needs
- Real-time features
4. Authentication Strategy
Method Selection
| Method |
Best For |
Avoid When |
| Session-based |
Traditional web apps, server-rendered |
Mobile apps, microservices |
| JWT |
SPAs, mobile apps, microservices |
Need immediate revocation |
| OAuth 2.0 |
Third-party access, social login |
Internal-only apps |
| API Keys |
Server-to-server, simple auth |
User authentication |
| mTLS |
Service mesh, high security |
Public APIs |
JWT vs Sessions
| Factor |
JWT |
Sessions |
| Scalability |
Stateless, easy to scale |
Requires session store |
| Revocation |
Difficult (need blocklist) |
Immediate |
| Payload |
Can contain claims |
Server-side only |
| Security |
Token in client |
Server-controlled |
| Mobile friendly |
Yes |
Requires cookies |
OAuth 2.0 Flow Selection
| Flow |
Use Case |
| Authorization Code |
Web apps with backend |
| Authorization Code + PKCE |
SPAs, mobile apps |
| Client Credentials |
Machine-to-machine |
| Device Code |
Smart TVs, CLI tools |
Avoid: Implicit flow (deprecated), Resource Owner Password (legacy only)
Token Lifetimes
| Token Type |
Suggested Lifetime |
| Access token |
15-60 minutes |
| Refresh token |
7-30 days |
| API key |
No expiry (rotate quarterly) |
| Session |
24 hours - 7 days |
5. Frontend Framework Selection
Framework Comparison
| Factor |
React |
Vue |
Angular |
Svelte |
| Learning curve |
Medium |
Low |
High |
Low |
| Ecosystem |
Largest |
Large |
Complete |
Growing |
| Performance |
Good |
Good |
Good |
Excellent |
| Bundle size |
Medium |
Small |
Large |
Smallest |
| TypeScript |
Good |
Good |
Native |
Good |
| Job market |
Largest |
Growing |
Enterprise |
Niche |
Decision Matrix
| Requirement |
Recommendation |
| Large team, enterprise |
Angular |
| Startup, rapid iteration |
React or Vue |
| Performance critical |
Svelte or Solid |
| Existing React team |
React |
| Progressive enhancement |
Vue or Svelte |
| Component library needed |
React (most options) |
Meta-Framework Selection
| Framework |
Best For |
| Next.js (React) |
Full-stack React, SSR/SSG |
| Nuxt (Vue) |
Full-stack Vue, SSR/SSG |
| SvelteKit |
Full-stack Svelte |
| Remix |
Data-heavy React apps |
| Astro |
Content sites, multi-framework |
When to Use SSR vs SPA vs SSG
| Rendering |
Use When |
| SSR |
SEO critical, dynamic content, auth-gated |
| SPA |
Internal tools, highly interactive, no SEO |
| SSG |
Content sites, blogs, documentation |
| ISR |
Mix of static and dynamic |
6. Cloud Provider Selection
Provider Comparison
| Factor |
AWS |
GCP |
Azure |
| Market share |
Largest |
Growing |
Enterprise strong |
| Service breadth |
Most comprehensive |
Strong ML/data |
Best Microsoft integration |
| Pricing |
Complex, volume discounts |
Simpler, sustained use |
EA discounts |
| Kubernetes |
EKS |
GKE (best managed) |
AKS |
| Serverless |
Lambda (mature) |
Cloud Functions |
Azure Functions |
| Database |
RDS, DynamoDB |
Cloud SQL, Spanner |
SQL, Cosmos |
Decision Factors
| If You Need |
Consider |
| Microsoft ecosystem |
Azure |
| Best Kubernetes experience |
GCP |
| Widest service selection |
AWS |
| Machine learning focus |
GCP or AWS |
| Government compliance |
AWS GovCloud or Azure Gov |
| Startup credits |
All offer programs |
Multi-Cloud Considerations
Go multi-cloud when:
- Regulatory requirements mandate it
- Specific service (e.g., GCP BigQuery) is best-in-class
- Negotiating leverage with vendors
Stay single-cloud when:
- Team is small
- Want to minimize complexity
- Deep integration needed
Service Mapping
| Need |
AWS |
GCP |
Azure |
| Compute |
EC2 |
Compute Engine |
Virtual Machines |
| Containers |
ECS, EKS |
GKE, Cloud Run |
AKS, Container Apps |
| Serverless |
Lambda |
Cloud Functions |
Azure Functions |
| Object Storage |
S3 |
Cloud Storage |
Blob Storage |
| SQL Database |
RDS |
Cloud SQL |
Azure SQL |
| NoSQL |
DynamoDB |
Firestore |
Cosmos DB |
| CDN |
CloudFront |
Cloud CDN |
Azure CDN |
| DNS |
Route 53 |
Cloud DNS |
Azure DNS |
7. API Style Selection
REST vs GraphQL vs gRPC
| Factor |
REST |
GraphQL |
gRPC |
| Use case |
General purpose |
Flexible queries |
Microservices |
| Learning curve |
Low |
Medium |
High |
| Over-fetching |
Common |
Solved |
N/A |
| Caching |
HTTP native |
Complex |
Custom |
| Browser support |
Native |
Native |
Limited |
| Tooling |
Mature |
Growing |
Strong |
| Performance |
Good |
Good |
Excellent |
Decision Matrix
| Requirement |
Recommendation |
| Public API |
REST |
| Mobile apps with varied needs |
GraphQL |
| Microservices communication |
gRPC |
| Real-time updates |
GraphQL subscriptions or WebSocket |
| File uploads |
REST |
| Internal services only |
gRPC |
| Third-party developers |
REST + OpenAPI |
When to Choose Each
Choose REST when:
- Building public APIs
- Need HTTP caching
- Simple CRUD operations
- Team experienced with REST
Choose GraphQL when:
- Multiple clients with different data needs
- Rapid frontend iteration
- Complex, nested data relationships
- Want to reduce API calls
Choose gRPC when:
- Service-to-service communication
- Performance critical
- Streaming required
- Strong typing important
API Versioning Strategies
| Strategy |
Pros |
Cons |
URL path (/v1/) |
Clear, easy to implement |
URL pollution |
Query param (?version=1) |
Flexible |
Easy to miss |
Header (Accept-Version: 1) |
Clean URLs |
Less discoverable |
| No versioning (evolve) |
Simple |
Breaking changes risky |
Recommendation: URL path versioning for public APIs, header versioning for internal.
Quick Reference
| Decision |
Default Choice |
Alternative When |
| Database |
PostgreSQL |
Scale/flexibility → MongoDB, DynamoDB |
| Cache |
Redis |
Simple needs → Memcached |
| Queue |
SQS (AWS) / RabbitMQ |
Event streaming → Kafka |
| Auth |
JWT + Refresh |
Traditional web → Sessions |
| Frontend |
React + Next.js |
Simplicity → Vue, Performance → Svelte |
| Cloud |
AWS |
Microsoft shop → Azure, ML-first → GCP |
| API |
REST |
Mobile flexibility → GraphQL, Internal → gRPC |
1---2name: 1064-tech-decision-guide-a6a322d73description: Technology Decision Guide4---5# Technology Decision Guide67Decision frameworks and comparison matrices for common technology choices.89## Decision Frameworks Index10111. [Database Selection](#1-database-selection)122. [Caching Strategy](#2-caching-strategy)133. [Message Queue Selection](#3-message-queue-selection)144. [Authentication Strategy](#4-authentication-strategy)155. [Frontend Framework Selection](#5-frontend-framework-selection)166. [Cloud Provider Selection](#6-cloud-provider-selection)177. [API Style Selection](#7-api-style-selection)1819---2021## 1. Database Selection2223### SQL vs NoSQL Decision Matrix2425| Factor | Choose SQL | Choose NoSQL |26|--------|-----------|--------------|27| Data relationships | Complex, many-to-many | Simple, denormalized OK |28| Schema | Well-defined, stable | Evolving, flexible |29| Transactions | ACID required | Eventual consistency OK |30| Query patterns | Complex joins, aggregations | Key-value, document lookups |31| Scale | Vertical (some horizontal) | Horizontal first |32| Team expertise | Strong SQL skills | Document/KV experience |3334### Database Type Selection3536**Relational (SQL):**37| Database | Best For | Avoid When |38|----------|----------|------------|39| PostgreSQL | General purpose, JSON support, extensions | Simple key-value only |40| MySQL | Web applications, read-heavy | Complex queries, JSON-heavy |41| SQLite | Embedded, development, small apps | Concurrent writes, scale |4243**Document (NoSQL):**44| Database | Best For | Avoid When |45|----------|----------|------------|46| MongoDB | Flexible schema, rapid iteration | Complex transactions |47| CouchDB | Offline-first, sync required | High throughput |4849**Key-Value:**50| Database | Best For | Avoid When |51|----------|----------|------------|52| Redis | Caching, sessions, real-time | Persistence critical |53| DynamoDB | Serverless, auto-scaling | Complex queries |5455**Wide-Column:**56| Database | Best For | Avoid When |57|----------|----------|------------|58| Cassandra | Write-heavy, time-series | Complex queries, small scale |59| ScyllaDB | Cassandra alternative, performance | Small datasets |6061**Time-Series:**62| Database | Best For | Avoid When |63|----------|----------|------------|64| TimescaleDB | Time-series with SQL | Non-time-series data |65| InfluxDB | Metrics, monitoring | Relational queries |6667**Search:**68| Database | Best For | Avoid When |69|----------|----------|------------|70| Elasticsearch | Full-text search, logs | Primary data store |71| Meilisearch | Simple search, fast setup | Complex analytics |7273### Quick Decision Flow7475```76Start77 │78 ├─ Need ACID transactions? ──Yes──► PostgreSQL/MySQL79 │80 ├─ Flexible schema needed? ──Yes──► MongoDB81 │82 ├─ Write-heavy (>50K/sec)? ──Yes──► Cassandra/ScyllaDB83 │84 ├─ Key-value access only? ──Yes──► Redis/DynamoDB85 │86 ├─ Time-series data? ──Yes──► TimescaleDB/InfluxDB87 │88 ├─ Full-text search? ──Yes──► Elasticsearch89 │90 └─ Default ──────────────────────► PostgreSQL91```9293---9495## 2. Caching Strategy9697### Cache Type Selection9899| Type | Use Case | Invalidation | Complexity |100|------|----------|--------------|------------|101| Read-through | Frequent reads, tolerance for stale | On write/TTL | Low |102| Write-through | Data consistency critical | Automatic | Medium |103| Write-behind | High write throughput | Async | High |104| Cache-aside | Fine-grained control | Application | Medium |105106### Cache Technology Selection107108| Technology | Best For | Limitations |109|------------|----------|-------------|110| Redis | General purpose, data structures | Memory cost |111| Memcached | Simple key-value, high throughput | No persistence |112| CDN (CloudFront, Fastly) | Static assets, edge caching | Dynamic content |113| Application cache | Per-instance, small data | Not distributed |114115### Cache Patterns116117**Cache-Aside (Lazy Loading):**118```119Read:1201. Check cache1212. If miss, read from DB1223. Store in cache1234. Return data124125Write:1261. Write to DB1272. Invalidate cache128```129130**Write-Through:**131```132Write:1331. Write to cache1342. Cache writes to DB1353. Return success136137Read:1381. Read from cache (always hit)139```140141**TTL Guidelines:**142143| Data Type | Suggested TTL |144|-----------|---------------|145| User sessions | 24-48 hours |146| API responses | 1-5 minutes |147| Static content | 24 hours - 1 week |148| Database queries | 5-60 minutes |149| Feature flags | 1-5 minutes |150151---152153## 3. Message Queue Selection154155### Queue Technology Comparison156157| Feature | RabbitMQ | Kafka | SQS | Redis Streams |158|---------|----------|-------|-----|---------------|159| Throughput | Medium (10K/s) | Very High (100K+/s) | Medium | High |160| Ordering | Per-queue | Per-partition | FIFO optional | Per-stream |161| Durability | Configurable | Strong | Strong | Configurable |162| Replay | No | Yes | No | Yes |163| Complexity | Medium | High | Low | Low |164| Cost | Self-hosted | Self-hosted | Pay-per-use | Self-hosted |165166### Decision Matrix167168| Requirement | Recommendation |169|-------------|----------------|170| Simple task queue | SQS or Redis |171| Event streaming | Kafka |172| Complex routing | RabbitMQ |173| Log aggregation | Kafka |174| Serverless integration | SQS |175| Real-time analytics | Kafka |176| Request/reply pattern | RabbitMQ |177178### When to Use Each179180**RabbitMQ:**181- Complex routing logic (topic, fanout, headers)182- Request/reply patterns183- Priority queues184- Message acknowledgment critical185186**Kafka:**187- Event sourcing188- High throughput requirements (>50K messages/sec)189- Message replay needed190- Stream processing191- Log aggregation192193**SQS:**194- AWS-native applications195- Simple queue semantics196- Serverless architectures197- Don't want to manage infrastructure198199**Redis Streams:**200- Already using Redis201- Moderate throughput202- Simple streaming needs203- Real-time features204205---206207## 4. Authentication Strategy208209### Method Selection210211| Method | Best For | Avoid When |212|--------|----------|------------|213| Session-based | Traditional web apps, server-rendered | Mobile apps, microservices |214| JWT | SPAs, mobile apps, microservices | Need immediate revocation |215| OAuth 2.0 | Third-party access, social login | Internal-only apps |216| API Keys | Server-to-server, simple auth | User authentication |217| mTLS | Service mesh, high security | Public APIs |218219### JWT vs Sessions220221| Factor | JWT | Sessions |222|--------|-----|----------|223| Scalability | Stateless, easy to scale | Requires session store |224| Revocation | Difficult (need blocklist) | Immediate |225| Payload | Can contain claims | Server-side only |226| Security | Token in client | Server-controlled |227| Mobile friendly | Yes | Requires cookies |228229### OAuth 2.0 Flow Selection230231| Flow | Use Case |232|------|----------|233| Authorization Code | Web apps with backend |234| Authorization Code + PKCE | SPAs, mobile apps |235| Client Credentials | Machine-to-machine |236| Device Code | Smart TVs, CLI tools |237238**Avoid:** Implicit flow (deprecated), Resource Owner Password (legacy only)239240### Token Lifetimes241242| Token Type | Suggested Lifetime |243|------------|-------------------|244| Access token | 15-60 minutes |245| Refresh token | 7-30 days |246| API key | No expiry (rotate quarterly) |247| Session | 24 hours - 7 days |248249---250251## 5. Frontend Framework Selection252253### Framework Comparison254255| Factor | React | Vue | Angular | Svelte |256|--------|-------|-----|---------|--------|257| Learning curve | Medium | Low | High | Low |258| Ecosystem | Largest | Large | Complete | Growing |259| Performance | Good | Good | Good | Excellent |260| Bundle size | Medium | Small | Large | Smallest |261| TypeScript | Good | Good | Native | Good |262| Job market | Largest | Growing | Enterprise | Niche |263264### Decision Matrix265266| Requirement | Recommendation |267|-------------|----------------|268| Large team, enterprise | Angular |269| Startup, rapid iteration | React or Vue |270| Performance critical | Svelte or Solid |271| Existing React team | React |272| Progressive enhancement | Vue or Svelte |273| Component library needed | React (most options) |274275### Meta-Framework Selection276277| Framework | Best For |278|-----------|----------|279| Next.js (React) | Full-stack React, SSR/SSG |280| Nuxt (Vue) | Full-stack Vue, SSR/SSG |281| SvelteKit | Full-stack Svelte |282| Remix | Data-heavy React apps |283| Astro | Content sites, multi-framework |284285### When to Use SSR vs SPA vs SSG286287| Rendering | Use When |288|-----------|----------|289| SSR | SEO critical, dynamic content, auth-gated |290| SPA | Internal tools, highly interactive, no SEO |291| SSG | Content sites, blogs, documentation |292| ISR | Mix of static and dynamic |293294---295296## 6. Cloud Provider Selection297298### Provider Comparison299300| Factor | AWS | GCP | Azure |301|--------|-----|-----|-------|302| Market share | Largest | Growing | Enterprise strong |303| Service breadth | Most comprehensive | Strong ML/data | Best Microsoft integration |304| Pricing | Complex, volume discounts | Simpler, sustained use | EA discounts |305| Kubernetes | EKS | GKE (best managed) | AKS |306| Serverless | Lambda (mature) | Cloud Functions | Azure Functions |307| Database | RDS, DynamoDB | Cloud SQL, Spanner | SQL, Cosmos |308309### Decision Factors310311| If You Need | Consider |312|-------------|----------|313| Microsoft ecosystem | Azure |314| Best Kubernetes experience | GCP |315| Widest service selection | AWS |316| Machine learning focus | GCP or AWS |317| Government compliance | AWS GovCloud or Azure Gov |318| Startup credits | All offer programs |319320### Multi-Cloud Considerations321322**Go multi-cloud when:**323- Regulatory requirements mandate it324- Specific service (e.g., GCP BigQuery) is best-in-class325- Negotiating leverage with vendors326327**Stay single-cloud when:**328- Team is small329- Want to minimize complexity330- Deep integration needed331332### Service Mapping333334| Need | AWS | GCP | Azure |335|------|-----|-----|-------|336| Compute | EC2 | Compute Engine | Virtual Machines |337| Containers | ECS, EKS | GKE, Cloud Run | AKS, Container Apps |338| Serverless | Lambda | Cloud Functions | Azure Functions |339| Object Storage | S3 | Cloud Storage | Blob Storage |340| SQL Database | RDS | Cloud SQL | Azure SQL |341| NoSQL | DynamoDB | Firestore | Cosmos DB |342| CDN | CloudFront | Cloud CDN | Azure CDN |343| DNS | Route 53 | Cloud DNS | Azure DNS |344345---346347## 7. API Style Selection348349### REST vs GraphQL vs gRPC350351| Factor | REST | GraphQL | gRPC |352|--------|------|---------|------|353| Use case | General purpose | Flexible queries | Microservices |354| Learning curve | Low | Medium | High |355| Over-fetching | Common | Solved | N/A |356| Caching | HTTP native | Complex | Custom |357| Browser support | Native | Native | Limited |358| Tooling | Mature | Growing | Strong |359| Performance | Good | Good | Excellent |360361### Decision Matrix362363| Requirement | Recommendation |364|-------------|----------------|365| Public API | REST |366| Mobile apps with varied needs | GraphQL |367| Microservices communication | gRPC |368| Real-time updates | GraphQL subscriptions or WebSocket |369| File uploads | REST |370| Internal services only | gRPC |371| Third-party developers | REST + OpenAPI |372373### When to Choose Each374375**Choose REST when:**376- Building public APIs377- Need HTTP caching378- Simple CRUD operations379- Team experienced with REST380381**Choose GraphQL when:**382- Multiple clients with different data needs383- Rapid frontend iteration384- Complex, nested data relationships385- Want to reduce API calls386387**Choose gRPC when:**388- Service-to-service communication389- Performance critical390- Streaming required391- Strong typing important392393### API Versioning Strategies394395| Strategy | Pros | Cons |396|----------|------|------|397| URL path (`/v1/`) | Clear, easy to implement | URL pollution |398| Query param (`?version=1`) | Flexible | Easy to miss |399| Header (`Accept-Version: 1`) | Clean URLs | Less discoverable |400| No versioning (evolve) | Simple | Breaking changes risky |401402**Recommendation:** URL path versioning for public APIs, header versioning for internal.403404---405406## Quick Reference407408| Decision | Default Choice | Alternative When |409|----------|----------------|------------------|410| Database | PostgreSQL | Scale/flexibility → MongoDB, DynamoDB |411| Cache | Redis | Simple needs → Memcached |412| Queue | SQS (AWS) / RabbitMQ | Event streaming → Kafka |413| Auth | JWT + Refresh | Traditional web → Sessions |414| Frontend | React + Next.js | Simplicity → Vue, Performance → Svelte |415| Cloud | AWS | Microsoft shop → Azure, ML-first → GCP |416| API | REST | Mobile flexibility → GraphQL, Internal → gRPC |