TL;DR: I deployed the entire Tixin event platform onto a tiny ARM edge cluster (2× Raspberry Pi 5) using k3s and tuned it to serve ~1000 concurrent connections while sustaining ~16k req/sec during load testing.

Why Edge Computing?

Edge-first infrastructure is underrated. I wanted a real-world test: can a tiny, cheap cluster run production-like traffic while staying stable and observable? Tixin, as an event booking and hosting platform, needs to handle traffic spikes during ticket releases and maintain low latency for real-time seat selection.

Beyond just proving it could work, this experiment had practical goals:

Cost efficiency at scale for a startup
Low latency for users across India
Learning resource optimization under real constraints
Understanding ARM performance for future edge deployments

Architecture & Setup

Hardware

Compute: 2 × Raspberry Pi 5 (8GB)
- BCM2712 quad-core ARM Cortex-A76 @ 2.4GHz
- Full gigabit Ethernet between nodes
Storage: NVMe SSDs via PCIe HATs
- PCIe Gen 2 provides ~500MB/s bandwidth
- Eliminates typical Raspberry Pi I/O bottlenecks
- Write-back caching for lower tail latency

Software Stack

OS: Ubuntu Server 22.04 LTS (ARM64)
Kubernetes: k3s (lightweight, perfect for edge)
Container Runtime: containerd (bundled with k3s)
Ingress: HAProxy (replaced Traefik for better performance)
Load Testing: k6 for realistic traffic simulation

Performance Metrics

The cluster handled impressive loads for its size:

Throughput:

~1,000 concurrent connections sustained
~16,000 req/sec peak (targeted k6 tests with realistic payloads)
Mix of 70% reads, 30% writes

Latency:

p50: ~15ms
p95: <50ms (steady state)
p99: ~80ms

Resource Usage:

CPU: 60-75% average during peak load
Memory: ~5.5GB per node (safe buffer remaining)
Network: 400-500Mbps during peak traffic

Key Optimizations

Application Layer

Stateless services for easy horizontal scaling
Session state in Redis, no local file dependencies
Aggressive caching for hot data paths (event listings, venue info)
Read replicas for frequently accessed data

System Tuning

CPU pinning to reduce context switching
- Cores 0-1: k8s control plane
- Cores 2-3: application workloads
Storage optimization:
- ext4 with data=writeback mode
- Disabled access time updates ("noatime")
- Optimized I/O scheduler for SSDs
Memory management:
- Tuned Node.js heap sizes per container
- 2GB zram-based swap as safety buffer
- Aggressive GC tuning to prevent spikes

Kubernetes Optimizations

Careful resource requests/limits to prevent OOM kills
HPA based on p95 latency (not just CPU)
Pod disruption budgets for high availability
Linkerd2 only on critical paths (not cluster-wide)

Observability

Prometheus + Grafana: Custom dashboards tracking latency percentiles, error rates, resource usage
Jaeger tracing: 10% sampling (100% during load tests)
Alert rules for p95 latency >100ms and error rate >1%

Technical Challenges

Memory constraints: 8GB per node required aggressive optimization

Switched to memory-efficient data structures
Implemented streaming for large responses
Monitored OOM events closely

Network saturation: Gigabit Ethernet is the bottleneck at peak

Payload compression (gzip) for responses >1KB
HTTP/2 multiplexing to reduce overhead
WebSocket connection reuse for real-time features

ARM compatibility:

Built custom multi-arch images for all services
Replaced libraries with poor ARM performance
Used native compilation (no QEMU emulation)

Stack Technologies

Infrastructure: Kubernetes (k3s) · containerd · HAProxy · Ubuntu Server Application: Node.js · Express.js · Socket.io Data: PostgreSQL · Redis · NVMe storage Observability: Prometheus · Grafana · Linkerd2 · Jaeger Testing: k6

Key Takeaways

This experiment proved edge computing on consumer hardware can handle serious production workloads:

Performance scales with optimization, not just hardware cost
ARM is production-ready for most web workloads
Resource constraints breed better engineering
Edge-first can reduce costs dramatically for startups like Tixin

For an event platform that needs to handle traffic spikes (think concert ticket drops), this setup performed surprisingly well. While we'd need more nodes for full redundancy and higher traffic, the Pi 5 cluster proved the concept: edge computing is viable for real applications.

Repository

All k8s manifests, load testing scripts, and configs: github.com/Adityaadpandey

Check out:

/k8s/ - Deployment YAMLs
/load-tests/ - k6 scenarios
/monitoring/ - Prometheus & Grafana configs