Gatify
A focused software project built around a real workflow.
How the project is put together
6 layers / 5 directed links
100%
- 01Interface
Developer-facing gateway configuration and local operations surface.
Go API / Config files / CLI/dev scripts - 02Application
Request pipeline applies rate limiting, proxying, and traffic logging.
Middleware pipeline / Reverse proxy / Rate limiter - 03Services/API
Gateway server coordinates rate-limit state and analytics persistence.
Go HTTP server / Redis / TimescaleDB - 04Data
Sliding-window counters and time-series request analytics.
Redis / TimescaleDB / PostgreSQL - 05Auth/Permissions
Authentication middleware is part of the roadmap, not the current core gateway.
Planned API keys / JWT middleware - 06Runtime
Self-hosted local/runtime stack with standardized commands and CI checks.
Docker Compose / Makefile / GitHub Actions
From broken workflow to operating system
A workflow needed clearer structure and better software support.
A shipped system made the workflow easier to operate and maintain.
The workflow constraint
Commercial API gateways come with vendor lock-in, opaque pricing, and limited customization. Developers need a self-hosted alternative that's easy to deploy, performant, and gives full control over rate limiting rules and analytics.
What changed
Decisions and trade-offs
Go over Node.js for the gateway
API gateways need raw throughput and low latency at the proxy layer.
Decision: Chose Go for its goroutine concurrency model, low memory footprint, and excellent HTTP performance for proxy workloads.
Trade-off: More verbose than Node.js, but significantly better performance for high-throughput proxy workloads where every microsecond counts.
Sliding window over fixed window rate limiting
Fixed window allows burst traffic at window boundaries.
Decision: Implemented sliding window algorithm in Redis for smooth, accurate rate limiting without boundary bursts.
Trade-off: Slightly more Redis operations per request, but prevents the 2x burst problem at window boundaries that fixed windows allow.
TimescaleDB over plain PostgreSQL for analytics
Analytics data is time-series — need efficient time-range queries and automatic partitioning.
Decision: Used TimescaleDB (PostgreSQL extension) for hypertables with automatic time-based partitioning and compression.
Trade-off: Adds a specialized database dependency, but dramatically improves query performance on time-series analytics data.
Constraints, architecture, and proof
Go HTTP server with middleware pipeline: Rate Limit Middleware → Reverse Proxy. Redis for distributed rate limiting state (sliding window). TimescaleDB for analytics and traffic logging. Docker Compose orchestrates all services.
Deployment, security, and maintenance
CI pipeline with GitHub Actions for linting, testing, and building. Docker Compose for reproducible deployment. Makefile for standardized development commands.