GitRev

• 

  GitRev

• 

  Total Requests

• 

  Server

Project Story

Inspiration

We kept running into the same production problems that break real services: schema drift, bad seed data, brittle deployments, and load tests that exposed weak points only after the system was already under pressure. GitRev was built to practice production engineering, not just ship endpoints.

What it does

GitRev provides a small but complete API surface for users, short URLs, and events, plus health checks, redirects, seeded data, and the operational guardrails needed to keep the service observable and recoverable.

How we built it

We used Flask and Peewee on PostgreSQL, wrapped the app in Docker, deployed with Helm, and validated behavior with unit, integration, and load tests. We also added deterministic seeding, sequence recovery, and test fixtures so the application can be reset and exercised repeatably in both local and kubernetes cluster environments.

Challenges we ran into

The hard parts were operational, not just functional. We had to fix sequence drift, make seed data happen only in the right environments, make integration tests work against a realistic database state, and handle Locust runs that hit DNS and CPU limits before the API itself failed. Load testing also exposed that POST /users was the primary bottleneck under heavy concurrency.

Accomplishments we’re proud of

We shipped a backend that stays up through seeded baselines, integration coverage, and load-test validation. The project now through all our issues has a track that has brought us reliability reliability: health checks pass, redirects work, events stay responsive, and the system keeps serving traffic even when one path becomes the bottleneck.

What we learned

Production reliability is rarely about one big bug. It is usually about many small things working together: correct hostnames, predictable seed data, stable database sequences, connection limits, and tests that reflect real operational behavior.

What’s next for GitRev

Better observability, distributed Locust runs for higher load, caching for the hottest read paths, and stronger failover behavior so the system can surface problems earlier instead of simply surviving them later.

Built With

• argocd
• docker
• flask
• k3s
• kubernetes
• peewee
• postgresql
• traefik