DEV Community: Le Beltagy

Cloud Architecture for Autonomous Systems: The 3-Tier Design & Why It Works

Le Beltagy — Tue, 14 Jul 2026 12:18:49 +0000

Cloud Architecture for Autonomous Systems: The 3-Tier Design & Why It Works

How I designed a production-grade system for handling real-time vehicle data at scale

The Problem I Solved

When I started building VehicleMetrics, I faced a choice that every backend engineer faces when tackling real-time systems:

Do I over-engineer and build something that scales to millions? Or do I start lean and regret it when things break?

I chose a third path: build a system that scales intelligently from day one, but doesn't waste resources on premature optimization.

This is the story of how I designed a 3-tier cloud architecture that handles autonomous vehicle data in real-time, scales horizontally, maintains data integrity, and stays operationally simple enough for one developer to manage.

Why 3 Tiers? Why Not Serverless? Why Not Monolith?

Let me be honest: I considered all approaches.

Serverless (Lambda/DynamoDB)

Pros: No servers to manage. Auto-scales. Pay per invocation.
Cons: Cold starts (critical for real-time data). Vendor lock-in. Query limitations with DynamoDB. Debugging nightmares when things go wrong.

Decision: No. Real-time vehicle data can't tolerate 500ms cold starts.

Monolith (Single large service)

Pros: Simple to deploy. Easier debugging. Single database.
Cons: Can't scale individual components. Technology lock-in. Deployment = all-or-nothing risk.

Decision: No. Different components scale differently. Data ingestion ≠ API response times.

3-Tier Microservices

Pros: Independent scaling. Technology flexibility. Clear separation of concerns. Battle-tested pattern.
Cons: More complex. Requires orchestration (Kubernetes). Multiple databases = consistency challenges.

Decision: Yes. This is the Goldilocks zone.

The Architecture: Layer by Layer

┌─────────────────────────────────────────────────────────────┐
│                    PRESENTATION TIER                        │
│        React + TypeScript + Grafana Dashboards              │
│              (Real-time Analytics UI)                        │
│                                                             │
│  • User Dashboards (React + WebSocket)                      │
│  • Grafana (System Metrics & Alerts)                        │
│  • Real-time Analytics Display                              │
└─────────────────┬───────────────────────────────────────────┘
                  │
         ┌────────┴──────────┐
         │ HTTPS + WebSocket │
         │    TLS 1.3        │
         └────────┬──────────┘
                  │
┌─────────────────▼───────────────────────────────────────────┐
│                  APPLICATION TIER                           │
│  FastAPI Microservices on EKS (Kubernetes)                  │
│                                                             │
│  ┌──────────────────┐  ┌──────────────────┐                │
│  │ Ingestion Svc    │  │ Analytics Svc    │                │
│  │ (High throughput)│  │ (Complex queries)│                │
│  │ Auto-scale: 1-10 │  │ Auto-scale: 1-5  │                │
│  └──────────────────┘  └──────────────────┘                │
│                                                             │
│  ┌──────────────────┐  ┌──────────────────┐                │
│  │ Auth Svc         │  │ Aggregation Svc  │                │
│  │ (Stateless)      │  │ (Batch processes)│                │
│  │ Auto-scale: 1-3  │  │ Auto-scale: 1-2  │                │
│  └──────────────────┘  └──────────────────┘                │
│                                                             │
│  All behind: AWS Application Load Balancer                 │
│  All in: Private subnets with NAT gateway                  │
└─────────────────┬───────────────────────────────────────────┘
                  │
      ┌───────────┼───────────┐
      │           │           │
   (Private Network - VPC)
      │           │           │
      ▼           ▼           ▼
┌─────────────────────────────────────────────────────────────┐
│                    DATA TIER                                │
│                                                             │
│  ┌────────────────────────────────────────┐                │
│  │ PostgreSQL 14 + TimescaleDB            │                │
│  │ • Time-series data (optimized)         │                │
│  │ • Retention: 90 days hot, 1yr archive  │                │
│  │ • Backup: Continuous PITR              │                │
│  │ • Read replicas for analytics queries  │                │
│  │ • Multi-AZ for high availability       │                │
│  └────────────────────────────────────────┘                │
│                                                             │
│  ┌────────────────────────────────────────┐                │
│  │ Redis 7 (Cluster Mode)                 │                │
│  │ • Real-time data streams               │                │
│  │ • Session storage                      │                │
│  │ • Cache layer for hot queries          │                │
│  │ • 6 nodes, 1GB each                    │                │
│  └────────────────────────────────────────┘                │
│                                                             │
│  ┌────────────────────────────────────────┐                │
│  │ S3 Data Lake                           │                │
│  │ • Raw sensor data (parquet format)     │                │
│  │ • Lifecycle: 30 days → Glacier         │                │
│  │ • Partition by vehicle_id/date         │                │
│  │ • Versioning enabled                   │                │
│  └────────────────────────────────────────┘                │
│                                                             │
│  ┌────────────────────────────────────────┐                │
│  │ Kinesis Data Streams                   │                │
│  │ • Real-time ingest (1000 rps)          │                │
│  │ • Lambda consumers for processing      │                │
│  │ • 24-hour retention                    │                │
│  └────────────────────────────────────────┘                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Tier 1: Presentation (Frontend)

Why React + TypeScript?

React:

Component-driven = easier to maintain
Virtual DOM = predictable performance
Ecosystem = everything you need exists
WebSocket support = real-time data

TypeScript:

Catches bugs at compile time
Self-documenting code
Refactoring confidence
Better IDE support

Why Grafana Dashboards?

Grafana wasn't in the original plan. But I realized:

Users expect dashboards. Giving them a custom React dashboard = I maintain it forever.
Grafana solves this. Pre-built panels, alerting, user management, all free.
It integrates. Prometheus metrics flow directly into Grafana.

Decision: Custom React for business dashboards. Grafana for ops/metrics dashboards.

Connection Pattern: WebSocket

Why not REST polling?

REST Polling:
Client → POST /api/latest → Server (every 5 seconds)
= 12 requests per minute per client
= 12,000 requests/min with 1000 clients
= Unnecessary load

WebSocket (Server-Sent Events):
Server opens persistent connection
Server pushes updates when available
= Only real changes transmitted
= 1/10th the bandwidth

Decision: WebSocket for real-time data. REST for historical queries.

Tier 2: Application (Backend Microservices)

Why Microservices? Why Not One Giant Service?

Here's the problem with monoliths:

Ingestion Service receives 1,000 requests/second of sensor data. It needs:

Minimal processing
Immediate response
Horizontal scaling

Analytics Service runs complex queries across months of data. It needs:

Heavy CPU
Large memory
Fewer instances (expensive to scale)

These services have opposite needs.

A monolith forces you to scale the entire application. Microservices let you scale only what you need.

Service Breakdown

1. Ingestion Service

Endpoint: POST /api/vehicles/{id}/sensor-data
Input: Raw sensor telemetry (30KB per message)
Processing: Validation + De-duplication
Output: 
  - Write to Kinesis (real-time stream)
  - Write to PostgreSQL (persistent storage)
Response: 201 Created (< 50ms)

Scaling: Auto-scale 1-10 instances
Reasoning: This is your bottleneck. High throughput, simple logic.

Why this design?

Fire-and-forget writes to Kinesis = immediate response
Async processing = no blocking operations
Database writes are asynchronous (Lambda consumes Kinesis)
One instance handles 100+ messages/second

2. Analytics Service

Endpoint: GET /api/analytics/vehicle/{id}?from=date&to=date
Input: Query parameters (dates, filters)
Processing: Complex SQL joins, aggregations
Output: Processed metrics (vehicle efficiency, anomalies, trends)
Response: 200 OK (may take 2-5 seconds)

Scaling: Auto-scale 1-5 instances
Reasoning: CPU-bound, fewer instances needed, heavy queries.

Why this design?

Queries run against read replicas (no impact on write performance)
Results cached in Redis (repeat queries = 50ms response)
Batch processing at off-peak hours
One instance per 5-10 concurrent users

3. Auth Service

Endpoint: POST /api/auth/token
Input: credentials or refresh_token
Processing: OAuth2/OIDC with AWS Cognito
Output: JWT token + claims
Response: 200 OK (< 100ms)

Scaling: Auto-scale 1-3 instances
Reasoning: Stateless, lightweight. Rarely the bottleneck.

Why this design?

Stateless = trivial to scale
Outsourced to AWS Cognito = we validate JWTs
No database lookups
Can run anywhere

4. Aggregation Service

Schedule: Every 10 minutes
Input: Raw sensor data from yesterday
Processing: Compress + rollup data
Output: Daily summaries written to cold storage
Storage: S3 (cheap long-term)

Scaling: Batch job, auto-scale 1-2 instances
Reasoning: Runs off-peak, one instance sufficient.

Why this design?

PostgreSQL only keeps 90 days hot
S3 keeps 1 year (Parquet format = 1/10th the space)
Old data queries redirect to S3 (Athena)
Cost reduction: hot vs cold data storage

Orchestration: Kubernetes (EKS)

Why not Docker Compose?

Docker Compose:

✅ Great for local development
✅ Simple deployments
❌ No auto-scaling
❌ No self-healing
❌ No rolling updates
❌ Doesn't survive node failures

Kubernetes (EKS):

✅ Auto-scaling based on CPU/memory
✅ Self-healing (pod dies? restart automatically)
✅ Rolling updates (zero downtime)
✅ Multi-AZ resilience
✅ Proven at scale

Decision: EKS for production. Docker Compose for local dev + CI/CD testing.

Load Balancing: ALB (Application Load Balancer)

Why ALB over NLB?

NLB (Network Load Balancer):
- Ultra-high throughput (millions/sec)
- Layer 4 (connection-level)
- Cost: High

ALB (Application Load Balancer):
- Layer 7 (application-level)
- URL-based routing
- Cost: Reasonable

Your load: ~5,000 requests/second total
→ ALB handles this easily
→ Save money

If you hit 50,000+ requests/second:
→ Upgrade to NLB

Decision: ALB. Easy path to upgrade if needed.

Tier 3: Data (Persistence & Processing)

PostgreSQL + TimescaleDB: Why Time-Series Specialization?

Standard PostgreSQL for time-series data is... bad.

Your data:
- Millions of rows per day
- Queries: "show me data from this vehicle last 30 days"
- Traditional indexing: SLOW

TimescaleDB advantage:
- Hypertables = automatic partitioning by time
- Native time-series functions (rollup, downsample)
- 10-100x faster queries
- Compression = 1/10th storage

Example:

-- Standard PostgreSQL
SELECT AVG(speed) FROM sensor_data 
WHERE vehicle_id = 'V123' 
AND timestamp > NOW() - INTERVAL '30 days'
-- Scans millions of rows, slow

-- TimescaleDB
SELECT time_bucket('1 hour', timestamp) as hour,
       AVG(speed)
FROM sensor_data
WHERE vehicle_id = 'V123'
  AND timestamp > NOW() - INTERVAL '30 days'
GROUP BY hour
-- Uses hypertable partitions, 100x faster

Data Retention Strategy:

Hot (PostgreSQL): 90 days
- Real-time queries
- Full resolution
- Fast

Warm (S3 Parquet): 1 year
- Historical analysis
- Aggregated
- Cheap (Glacier)

Cold (Archival): Indefinite
- Regulatory compliance
- Deep archive (AWS Glacier Deep Archive)

Redis: Why Not Just Use PostgreSQL Cache?

PostgreSQL has built-in caching...

Real-time dashboard needs latest speed for vehicle V123:
- Query PostgreSQL: 200ms (disk I/O)
- Query Redis: 2ms (memory)
- 100x difference

With 1000 concurrent users:
- PostgreSQL: Database collapses
- Redis: Handles trivially

Redis Specific Use Cases:

Session Storage: User login tokens (TTL: 24 hours)
Real-Time Streams: Vehicle location updates (using Redis Streams)
Query Cache: "Latest metrics for vehicle V123" (TTL: 30 seconds)
Rate Limiting: "API key used 950/1000 requests" (TTL: 1 hour)

Why Cluster Mode?

Single Redis instance:
- Holds entire dataset in memory
- 6GB vehicle data = 6GB RAM
- Cost: ~$0.50/hour

Redis Cluster (3 nodes):
- Partitions data across nodes
- Each node holds 2GB
- More resilient
- Cost: ~$0.80/hour (33% premium for resilience)

Decision: Cluster mode. The 33% cost for high availability is worth it.

Kinesis: Real-Time Data Pipeline

Why not just write directly to PostgreSQL?

Direct writes:
POST /ingest → PostgreSQL (synchronous)
Problems:
- Ingest service waits for disk I/O
- Database is bottleneck
- Can't exceed database write throughput

Kinesis pattern:
POST /ingest → Kinesis (fast, async)
Lambda → PostgreSQL (asynchronous processing)
Benefits:
- Ingest responds in 50ms (only writes to Kinesis buffer)
- Database is decoupled
- Can retry failed writes
- Can replay data if needed
- Can add new consumers without changing ingest

Why 1,000 requests/second is our target:

Single vehicle:
- GPS: 10Hz (10 updates/second)
- Sensors: 100Hz (speed, temp, pressure, etc)
- 1 vehicle = 110 messages/second

50 vehicles in production:
50 × 110 = 5,500 messages/second needed
Kinesis shard handles 1,000/sec
→ Need 6 shards
→ Cost: ~$300/month

1 million messages/second:
→ 1,000 shards
→ Cost: $300,000/month (enterprise scale)

Decision: Kinesis with on-demand scaling. Pay per GB ingested.

Design Decisions I Made (and Why)

1. Private Subnets for Everything

Why? Reduces attack surface. No direct internet access to databases.

Internet → ALB (public subnet)
         → EKS (private subnet)
         → RDS (private subnet)

Attacker gets ALB? Can't reach databases directly.

2. Multi-AZ Deployment

AWS Region (e.g., us-east-1)
├── AZ 1: RDS Primary, EKS nodes, Redis nodes
├── AZ 2: RDS Replica, EKS nodes, Redis nodes
└── AZ 3: EKS nodes, backup

One AZ goes down?
→ System still running (automatic failover)

3. Stateless Services

Every service is 100% stateless:

No local files
No in-memory caches
No session storage

Why? Easy horizontal scaling. Kill pod, create new one, no state loss.

4. API Rate Limiting

Per API key: 1,000 requests/minute
Enforced at: ALB + Auth service
Benefit: Prevents one bad actor from crushing system

Data Flow: A Single Vehicle's Update

┌─────────────────────────────────────────────────────────────┐
│ 1. Vehicle Telemetry (GPS + 50 sensors)                     │
│    Sent: Every 100ms                                        │
│    Payload: ~30KB                                           │
└─────────────────┬───────────────────────────────────────────┘
                  │ HTTPS
┌─────────────────▼───────────────────────────────────────────┐
│ 2. ALB (Application Load Balancer)                          │
│    • Rate limit check                                       │
│    • Route to Ingestion service                             │
└─────────────────┬───────────────────────────────────────────┘
                  │
┌─────────────────▼───────────────────────────────────────────┐
│ 3. Ingestion Service (Pod)                                  │
│    • Validate payload (< 5ms)                               │
│    • De-duplicate (Redis check)                             │
│    • Write to Kinesis (async, < 10ms)                       │
│    • Return 201 Created (< 50ms total)                      │
└─────────────────┬───────────────────────────────────────────┘
                  │
   ┌──────────────┴───────────────┐
   │                              │
   ▼                              ▼
┌──────────────────┐      ┌──────────────────┐
│ Kinesis Stream   │      │ Redis Cache      │
│ (Real-time)      │      │ (Latest value)   │
└─────────┬────────┘      └──────────────────┘
          │
┌─────────▼─────────────────────────────────────────────────┐
│ 4. Lambda (Kinesis Consumer)                              │
│    • Runs every 1 second                                  │
│    • Batch processes messages (efficiency)                │
│    • Writes to PostgreSQL + TimescaleDB                   │
│    • Updates Redis streams (real-time feed)               │
└─────────┬───────────────────────────────────────────────┘
          │
┌─────────▼───────────────────────────────────────────────────┐
│ 5. Dashboard (User's Browser)                               │
│    • Subscribes to Redis Streams (WebSocket)               │
│    • Receives updates instantly                            │
│    • Displays latest metrics                               │
│    • Historical queries hit PostgreSQL (cached in Redis)   │
└───────────────────────────────────────────────────────────────┘

Total latency: ~100ms from vehicle sensor to dashboard display

Cost Breakdown (Rough Monthly)

Service              Usage              Cost
─────────────────────────────────────────────
EKS Compute         6 nodes (t3.medium) $150
RDS PostgreSQL      db.t3.small + replica $100
ElastiCache Redis   3-node cluster      $60
S3 Storage          100GB per month     $2
Kinesis Streams     5-10M records       $25
Lambda Processing   1B invocations      $20
Data Transfer       ~50GB out           $5
NAT Gateway         200GB               $30
─────────────────────────────────────────────
TOTAL (monthly):                        ~$392

Annual: ~$4,700 for production system

What I'd Change If Building Today

1. Add a Message Queue (SQS)

Between Ingestion and Kinesis:

Current: POST → Kinesis → Lambda
Problem: Kinesis can get backlogged

Better: POST → SQS → Kinesis → Lambda
Benefit: SQS is cheaper, provides buffering

2. Use EventBridge Instead of Kinesis

EventBridge (AWS's event bus) is newer and:

More flexible routing
Better filtering at source
Native integration with Lambda, SNS, etc.

3. Kafka for Very High Volume

If hitting 100,000+ messages/second:

Kinesis: $300,000+/month
Kafka (self-managed): $2,000/month
Kafka (Confluent managed): $10,000/month

Lessons for Your Architecture

1. Match Tool to Problem

Low latency, high throughput: Use Kinesis + Lambda
Complex queries, low throughput: Use PostgreSQL + read replicas
Session state, caching: Use Redis
Long-term storage: Use S3 with Parquet

Don't try to use one tool for everything.

2. Separate Read and Write Paths

Writes are different from reads:

Writes: Fast, simple, durable (Kinesis)
Reads: Complex, slow, can be stale (Redis cache)

Build them separately.

3. Auto-Scaling Is Non-Negotiable

For autonomous vehicle data, you can't predict demand:

3 AM Tuesday: 0 vehicles
3 PM Friday: 50 vehicles
3 AM Sunday: 10 vehicles

Every service must auto-scale based on load.

4. Think in Tiers

Tier 1 (Hot): Everything in memory, milliseconds
Tier 2 (Warm): Disk-based, seconds
Tier 3 (Cold): Archive, days

This matches cost to need.

Next Steps

This architecture handles Phase 1 comfortably. For Phase 2/3:

Add ML pipeline: Model training on historical data
Add notifications: Alert when anomalies detected
Add analytics: Trend analysis across vehicles
Multi-region: Deploy to multiple AWS regions

TL;DR

3-tier architecture separates concerns: frontend, backend, data
Microservices scale independently (1,000 rps ingestion ≠ analytics queries)
Kubernetes provides auto-scaling, self-healing, and resilience
Polyglot persistence: PostgreSQL (structured) + Redis (real-time) + S3 (archive)
Async pipelines: Kinesis decouples ingest from processing
Cost: ~$400/month for production system handling 50 vehicles

GitHub: beltagyy/vehicle-metrics
Author: Mohamed ElBeltagy (@beltagyy)
Topic: Cloud Architecture | Microservices | Autonomous Systems

I Built an Autonomous Vehicle Analytics Platform (Solo) — Here's What I Learned

Le Beltagy — Tue, 14 Jul 2026 12:13:11 +0000

# I Built an Autonomous Vehicle Analytics Platform (Solo) — Here's What I Learned

And why I'm open-sourcing it all.

The Origin Story

It started simple: What if one person could build a real-time analytics platform for autonomous vehicles?

Not the software for driving them. But something that watches them, learns from them, and makes sense of all that sensor data streaming in. Something that could scale from tracking one vehicle to fifty.

Three months ago, I decided to find out.

Today, I'm launching VehicleMetrics — the full codebase, architecture diagrams, deployment guides, and everything — on GitHub. And I want to tell you why this matters, even if you don't care about autonomous vehicles.

Because the lesson isn't about AVs. It's about building production systems solo.

The Challenge

Here's what I wanted to prove:

One developer (me)
One vehicle (to start with, or simulated data)
One month for a proof-of-concept
Production-ready architecture that could scale to 50+ vehicles

No shortcuts. No "we'll refactor later." Real infrastructure, real security, real DevOps.

The catch? I had to use AWS, Kubernetes, Terraform, PostgreSQL, Redis, React, FastAPI, and a CI/CD pipeline. All while working solo.

Most people would say that's insane.

I said, "let's build."

What We Built

VehicleMetrics is a 3-tier cloud-native system designed to ingest, process, and analyze vehicle sensor data in real-time.

The Architecture (The Part Everyone Asks About)

┌─────────────────────────────────────────────────────────────┐
│                    PRESENTATION TIER                        │
│        React + TypeScript + Grafana Dashboards              │
│              (Real-time Analytics UI)                        │
└─────────────────┬───────────────────────────────────────────┘
                  │ HTTPS / WebSocket
┌─────────────────▼───────────────────────────────────────────┐
│                  APPLICATION TIER                           │
│  FastAPI Microservices on EKS (Kubernetes)                  │
│  • Ingestion Service    • Analytics Service                 │
│  • Auth Service         • Aggregation Service               │
└─────────────────┬───────────────────────────────────────────┘
                  │ VPC / Private Subnets
┌─────────────────▼───────────────────────────────────────────┐
│                    DATA TIER                                │
│  • PostgreSQL + TimescaleDB (Time-Series Data)              │
│  • Redis (Caching & Real-Time Streams)                      │
│  • S3 (Data Lake for Raw Sensor Data)                       │
│  • Kinesis (Real-Time Data Pipeline)                        │
└─────────────────────────────────────────────────────────────┘

It's the kind of architecture you'd build at a startup with 5 engineers. Except one person built it.

Why? Because boring architecture wins. Nothing custom. Nothing clever. All battle-tested, industry-standard tools that have proven themselves a million times over.

The Tech Stack (No Surprises Here)

Layer	Tech	Why
Compute	AWS EKS (Kubernetes)	Industry standard for container orchestration
Infrastructure	Terraform	IAC done right. Version control everything.
Backend	FastAPI + Python 3.11	Fast, modern, great for microservices
Frontend	React + TypeScript	Type safety. Component-driven. Community support.
Database	PostgreSQL 14 + TimescaleDB	ACID compliance + time-series specialization
Cache	Redis 7	Blazingly fast. Proven. Boring.
Data Pipeline	AWS Kinesis + Lambda	Stream processing at scale
Monitoring	Prometheus + Grafana	Observability you can understand
CI/CD	GitHub Actions	Right here where the code lives

Every choice was made for the same reason: When things break at 2 AM, I need to fix them alone. So I chose tools I could understand, debug, and reason about.

The Timeline (How I Actually Did This)

Phase 1: Proof of Concept (Month 1)

Week 1: Architecture & AWS Setup
Week 2: Infrastructure (EKS, RDS, S3 configured)
Week 3: Core API (FastAPI ingestion service)
Week 4: Dashboard (React + real data visualization)

Phase 2: Production (Months 2-6)

Multi-vehicle support
Advanced analytics
Alert system
Performance optimization

Phase 3: Intelligence (Months 7-12)

AI/ML integration (GPT-4, Claude, Llama)
Predictive analytics
Anomaly detection
Custom model training

What Shocked Me

1. The 80/20 Rule is Real

80% of the work was the infrastructure and plumbing. The actual "vehicle analytics" code? Maybe 20%.

This means: invest in architecture first. The business logic is easy. Getting it to scale is the hard part.

2. Documentation > Code

I spent as much time writing deployment guides as I did writing code. And you know what? That's the right ratio.

Future me (and future maintainers) will thank me.

3. You Don't Need a Team

You need:

Clear constraints (1 month, 1 vehicle)
Battle-tested tools (no experiments)
Ruthless scope management
Good documentation
Boring choices

You DON'T need:

Meetings
Design reviews
Consensus
Enterprise process

Solo developers move fast.

Why Open Source?

Three reasons:

Teach — This is a real, production-ready system. Use it to learn how real architectures work.
Prove — Solo developers can build enterprise systems. You don't need a team for this.
Build — Take this, fork it, modify it, scale it. Make something better. I genuinely want to see what you build with this.

What's Included

Everything is on GitHub at beltagyy/vehicle-metrics:

✅ Complete source code (backend, frontend, infrastructure)
✅ Terraform templates for full AWS deployment
✅ Kubernetes manifests (development and production)
✅ Docker Compose for local development
✅ API reference (complete endpoint documentation)
✅ Security guide (including ISO 21434 compliance notes)
✅ Operations manual (what to do when things break)
✅ 17 Phase 1 GitHub issues (ready to start working)
✅ MIT License (do what you want with it)

Clone it. Deploy it. Learn from it. Improve it.

The Real Lesson

This project isn't really about autonomous vehicles.

It's about proving that good engineering beats team size.

One person with:

Clear goals
Boring tools
Good documentation
Real constraints

...can build something that actually scales.

Most teams fail because they optimize for process instead of output. I succeeded because I optimized for speed and clarity.

What's Next?

For me: Building Phase 2 (multi-vehicle support) and adding AI/ML capabilities
For you: Check out the repo, read the ARCHITECTURE.md, deploy it locally with Docker Compose

Questions? Issues? Improvements?

Hit me up on GitHub (@beltagyy) or in the issues. I built this to be learned from, modified, and improved.

TL;DR

Built a production-grade autonomous vehicle analytics platform solo
Used AWS, Kubernetes, FastAPI, React, PostgreSQL, Redis, and good engineering practices
Open-sourced everything at github.com/beltagyy/vehicle-metrics
Proof that solo developers can build enterprise systems with boring, proven tools
Phase 1 done. Phase 2 coming soon.

Come build with me. 🚀

GitHub: beltagyy/vehicle-metrics
Author: Mohamed ElBeltagy (@beltagyy)
License: MIT

How I Reorganized 45 Kubernetes Manifests and Saved Hours of Development Time

Le Beltagy — Mon, 13 Jul 2026 19:28:39 +0000

How I Reorganized 45 Kubernetes Manifests (And You Should Too)

TL;DR: I took a messy flat structure of 45 manifest files and reorganized them into 8 logical component groups with clear dependencies, reducing confusion and deployment time. Here's how I did it and why it matters.

The Problem: 45 Files in One Directory

Imagine this:

talos/manifests/
├── argocd-applications.yaml
├── argocd.yaml
├── cert_manager.yaml
├── cilium-bgp-config.yaml
├── cilium-ingressclass.yaml
├── cilium-ingress-lb.yaml
├── cilium-ingress-rbac.yaml
├── cilium-l2-ippool.yaml
├── cilium-loadbalancer-ippool.yaml
├── cilium-minimal.yaml
├── cilium-network-policies-examples.yaml
├── cilium-values-minimal.yaml
├── cilium-values.yaml
├── cilium.yaml
├── dns_admin.yaml
├── gateway-api-crds.yaml
├── gateway-api-examples.yaml
├── grafana-hubble-dashboard-configmap.yaml
├── headlamp-token.yaml
├── headlamp.yaml
├── ingress.yaml
├── jenkins.yaml
├── loki.yaml
├── longhorn-grafana-dashboard.yaml
├── longhorn-namespace.yaml
├── longhorn-recurring-jobs.yaml
├── longhorn-storage-classes.yaml
├── longhorn-values-minimal.yaml
├── longhorn-values.yaml
├── longhorn.yaml
├── metallb.yaml
├── minio.yaml
├── namespaces.yaml
├── openebs.yaml
├── portainer-ingress.yaml
├── portainer-traefik-ingress.yaml
├── portainer.yaml
├── prometheus-grafana.yaml
├── rook-ceph-cluster-values.yaml
├── rook-ceph-cluster.yaml
├── rook-ceph-operator-values.yaml
├── rook-ceph-operator.yaml
└── traefik-ingressroutes.yaml

Real talk:

Finding related files? Good luck.
Understanding dependencies? Unclear.
Enabling/disabling components? Confusing.
New team member onboarding? Nightmare.

The Solution: Organized Component Groups

Here's what I built:

talos/manifests/
├── 00-namespaces/          ← Deploy 1st
├── 10-networking/          ← Cilium, Traefik
├── 20-security/            ← cert-manager, policies
├── 30-storage/             ← Longhorn, MinIO, OpenEBS
├── 40-observability/       ← Prometheus, Grafana, Loki
├── 50-management/          ← Portainer, Headlamp
├── 60-gitops/              ← ArgoCD, Jenkins
└── 70-loadbalancing/       ← MetalLB

Benefits immediately visible:
✅ Related files grouped together

✅ Deployment order clear (00 → 70)

✅ Easy to find what you need

✅ Component dependencies obvious

The Impact: Before vs After

BEFORE

💥 Pain Points:
  • 45 files in one directory
  • No clear structure
  • Hard to find components
  • Unclear dependencies
  • Confusing Terraform config
  • New team members lost
  • "Where's the Longhorn config?"

AFTER

✨ Improvements:
  ✅ 8 organized component groups
  ✅ Clear naming scheme (00-* through 70-*)
  ✅ Dependency order built-in
  ✅ Component READMEs with guides
  ✅ Easy to enable/disable
  ✅ New team members productive in minutes
  ✅ "Longhorn? Check 30-storage/longhorn/"

Deployment Order & Dependencies

        START
         ↓
    [00-namespaces]     ← Creates namespaces
         ↓
    [10-networking]     ← Cilium, Traefik
         ↓
    [20-security]       ← cert-manager, policies
         ↓
    [30-storage]        ← Longhorn, MinIO, OpenEBS
         ↓
    [40-observability]  ← Prometheus, Grafana, Loki
         ↓
    [50-management]     ← Portainer, Headlamp
         ↓
    [60-gitops]         ← ArgoCD, Jenkins
         ↓
    [70-loadbalancing]  ← MetalLB
         ↓
        END

Smart Part: Terraform automatically respects this order because of the numeric prefixes!

Real-World Example: Finding & Enabling Longhorn

BEFORE (Confusing)

$ grep -r "longhorn" .
# 15 results scattered everywhere
# Which one is the main one?
# Are there dependencies?
# Where's the config?

AFTER (Clear)

$ ls talos/manifests/30-storage/longhorn/
longhorn.yaml
longhorn-namespace.yaml
longhorn-values.yaml
longhorn-storage-classes.yaml
longhorn-recurring-jobs.yaml
longhorn-grafana-dashboard.yaml
README.md

To enable Longhorn:

# Edit talos/main.tf
longhorn = "manifests/30-storage/longhorn/longhorn.yaml"

# Deploy
tofu apply

Crystal clear!

The Numbers

What I reorganized:

Metric	Value
Files Reorganized	45 manifests
Component Groups	8 organized groups
Documentation Created	21 files
Lines of Docs	10,000+
Components Documented	14
Environments Configured	4 (local/dev/staging/prod)
Time Saved (Long-term)	Hours per month

Key Learnings

1. Naming Matters

Numeric prefixes (00-, 10-, etc.) enforce deployment order naturally.

2. Documentation is Everything

Each component group has a README explaining what's included, when to use it, how to enable/disable, and common issues.

3. Dependencies Should Be Obvious

By looking at the folder structure, you know what depends on what, what can run independently, and what order to deploy in.

4. Multi-Environment is Essential

Having local/dev/staging/prod configs lets teams test safely, promote changes gradually, and learn without risk.

5. Enable/Disable Should Be Simple

One line in Terraform = deploy or remove a component

# To enable: uncomment
longhorn = "manifests/30-storage/longhorn/longhorn.yaml"

# To disable: comment
# longhorn = "manifests/30-storage/longhorn/longhorn.yaml"

Try It Yourself

My complete reorganized GitOps repo is open source:

⭐ github.com/beltagyy/gitops

You'll find:

Completely organized manifests
Multi-environment setup
10,000+ lines of clear documentation
Component status matrix
Quick start guides
Real examples

What's Next?

I'm working on Phase 2:

App Deployment Scaffold - Deploy new apps in 30 seconds
Makefile Automation - Common commands via make
Local Dev Environment - 5-minute Kind cluster setup
Troubleshooting Runbooks - Self-service operations guide

Check out the GitHub Issues to see what's coming!

The Bottom Line

Organization matters. Especially at scale.

Taking time to organize your infrastructure code:

Saves hours long-term
Makes team onboarding faster
Reduces confusion & errors
Makes GitOps actually work
Improves code quality

If you're managing Kubernetes manifests, take a weekend to reorganize. Your future self will thank you. 🚀

Questions?

How would you organize these manifests differently?
What's your biggest pain point with Kubernetes management?
Want help reorganizing your own repo?

Drop a comment below! 👇

Connect with me on GitHub: @beltagyy

Star the repo if you found this helpful! ⭐