Scaling strategies — kiedy i jak skalować

Scaling to nie problem MVP. To problem sukcesu. Nie skaluj za wcześnie — premature optimization. Ale projektuj tak żeby dało się skalować.

Kiedy skalować?

Sygnały że potrzebujesz skalowania:

• Response time > 2 sekundy (było < 500ms)
• Database queries timeout
• Server CPU > 80% constantly
• Costs rosną szybciej niż revenue
• Users narzekają na wolność

Kiedy NIE skalować:

• < 1000 active users
• Response time OK
• Costs w budżecie
• "Na wszelki wypadek" — to premature optimization

Vertical vs Horizontal Scaling

Vertical (scale up):

• Większy serwer (więcej CPU, RAM)
• Prosty — zero zmian w kodzie
• Limit — max rozmiar maszyny
• Droższy per unit

Horizontal (scale out):

• Więcej serwerów
• Złożony — load balancer, distributed state
• Unlimited — dodaj więcej maszyn
• Tańszy per unit

Dla MVP: Start vertical. Migrate horizontal gdy vertical nie wystarcza.

Database Scaling

1. Optimize queries (zawsze najpierw)

• Add indexes
• Limit results
• Avoid N+1 queries
• Cache frequent queries

2. Read replicas

• Master (writes) + Replicas (reads)
• Skaluje read-heavy apps
• Firestore: automatic replication

3. Sharding

• Podziel dane na wiele databases
• Np. users 0-1M → DB1, 1M-2M → DB2
• Złożone — ostateczność

4. Migrate to different DB

• Firestore → PostgreSQL (gdy potrzebujesz SQL)
• PostgreSQL → Cassandra (gdy potrzebujesz massive scale)

Caching Strategies

Client-side cache:

• Cache API responses w app
• Reduce network calls
• Flutter: Hive, shared_preferences

CDN (Content Delivery Network):

• Cache static assets (images, CSS, JS)
• Serve from edge locations (blisko użytkownika)
• Firebase Hosting: CDN built-in

Server-side cache:

• Redis, Memcached
• Cache database queries
• Cache computed results

Firebase Scaling

Firestore auto-scales:

• Do 1M concurrent connections
• 10k writes/second per database
• Wystarczy dla większości apps

Bottlenecks:

• Hot documents (1 doc updated często) — max 1 write/second
• Solution: Shard counters, distributed writes

Cloud Functions scaling:

• Auto-scales do 1000 concurrent instances
• Cold start problem — keep warm

Cost Optimization przy skalowaniu

• Monitor costs: Firebase Usage dashboard
• Optimize queries: Mniej reads = mniej kosztów
• Cache aggressively: Reduce API calls
• Cleanup old data: Delete unused documents
• Use cheaper tiers: Firestore → BigQuery dla analytics

Migration Strategy

Gdy Firebase nie wystarcza (bardzo rzadko dla MVP):

1. Identify bottleneck: Database? Functions? Storage?

2. Migrate incrementally:

• Nie migruj całości naraz
• Start z bottleneck
• Dual-write (Firebase + nowy system)
• Migrate users gradually

3. Common migrations:

• Firestore → PostgreSQL (SQL queries)
• Cloud Functions → Cloud Run (containers)
• Firebase Storage → S3 (cheaper at scale)