Caching Strategies for High-Traffic Tor Hidden Services

Nginx's built-in proxy cache stores responses from the backend application server, serving cached content directly without hitting the backend for repeat requests. Configure in nginx.conf: proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=hs_cache:10m max_size=10g inactive=60m use_temp_path=off. In server block: proxy_cache hs_cache; proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; proxy_cache_key '$host$request_uri$cookie_sessionid'; add_header X-Cache-Status $upstream_cache_status. Cache key includes session cookie to prevent serving cached content across sessions for session-specific responses. Cache valid directive sets TTL per response code. Bypass cache for authenticated users: proxy_cache_bypass $http_authorization (don't cache authenticated requests).

Redis provides in-memory key-value storage for application-level caching. Effective uses: session storage (eliminates database round-trips for every request), frequently accessed database queries (user profiles, configuration data), computed results (statistics, counts), and rate limiting counters. Implementation: cache database query results with a TTL matching data freshness requirements. Example (Python): from redis import Redis; r = Redis(); result = r.get('user:123:profile'); if not result: result = db.query('SELECT * FROM users WHERE id=123'); r.setex('user:123:profile', 300, json.dumps(result)). Cache invalidation: use cache versioning or explicit invalidation when data changes (delete cache key after UPDATE in database). Redis on localhost avoids network latency - on hidden service servers, always deploy Redis on localhost, not exposed to internet.

External CDNs (Cloudflare, Fastly) would reveal the hidden service's origin server (CDN knows your server IP). Self-hosted alternatives: serve static assets from the same server with aggressive caching headers (Cache-Control: max-age=31536000 for versioned assets). GeoDNS-based routing is not applicable to .onion addresses. OnionBalance for multi-backend distribution is the .onion equivalent of a CDN: multiple backend servers share a single .onion address, and OnionBalance distributes traffic across them. This provides geographic distribution (servers in different data centers) without revealing any server's IP. Configure OnionBalance with backends in different regions for lower average circuit latency.

Database performance directly impacts hidden service response times. Optimization layers: indexes on frequently queried columns (EXPLAIN ANALYZE query in PostgreSQL shows query plans and identifies missing indexes), connection pooling (PgBouncer for PostgreSQL reduces connection overhead from multiple application workers), read replicas for read-heavy workloads (write to primary, read from replica), and query caching at the application layer for expensive aggregations. PostgreSQL-specific: pg_stat_statements extension identifies slow queries for targeted optimization. work_mem parameter increases memory for sort operations (reduces disk I/O). shared_buffers should be 25% of RAM for dedicated database servers. Regular VACUUM and ANALYZE maintain table statistics for query planner accuracy.

Monitoring response times identifies performance bottlenecks in hidden service deployments. Tools: Prometheus + Grafana for metrics collection and visualization. Application-level metrics: track p50, p95, and p99 response times per endpoint. Database metrics: query execution times, connection pool utilization, cache hit rates. System metrics: CPU utilization, memory pressure, network I/O. Alert thresholds: p95 response time exceeding 5 seconds indicates degraded performance. Cache hit rate below 60% for cacheable content indicates caching configuration issues. Response time breakdowns (time in Tor circuit vs. time in application) help identify whether bottlenecks are in the Tor network or the server application.