Internal Microservices Gateways
Single entry point for internal services with routing, access control, and visibility—run it yourself.
Practical use cases
Concrete ways teams use Zerq for this scenario.
One place to route, auth, and observe internal APIs
Front all internal services (and optional legacy backends) with one gateway. Each team or service gets its own product and quotas; you see traffic and errors per service in your existing Prometheus and logs without sending data outside your perimeter.
Enforce per-team or per-service limits
Prevent one team or runaway client from overloading a backend. Set rate limits and quotas per product; the gateway enforces them and returns clear responses (e.g. 429) so callers can back off or request a higher tier.
Customize behavior per API without forking the gateway
Use the workflow designer to add conditional routing, aggregation, or custom responses for specific paths. No need to ship custom code into the gateway binary; your team owns the logic in config.
Outcomes
- Unified control plane and data plane without vendor lock-in.
- Per-service/team visibility and limits; metrics and logs stay on-prem.
- Custom behavior per API via workflows instead of forked gateway code.
How Zerq helps
- API products map to internal services or domains; access levels and per-partner (e.g. team or service account) quotas and rate limits.
- Token and certificate validation at the gateway; optional client certs for service-to-service calls; credential storage with encryption and rotation.
- Workflow designer for conditional routing, branching, and custom responses; reference previous steps for multi-call flows; optional code node for one-off logic.
- Prometheus export and structured logs; filter by product and partner (team); run Grafana and log pipelines in your own environment.
- Docker Compose for dev; Kubernetes for production with multi-replica scaling and rolling updates.
- Duplicate request protection and optional caching to protect backends from thundering herd or retries.
For architects & evaluators (technical context, requirements)
Technical context
Internal API gateways front microservices and legacy backends, providing a single place for routing, auth, and observability. Teams need per-service or per-team rate limits, token or certificate validation, optional request/response transformation, and metrics/logs in their own environment. Avoiding vendor lock-in and keeping data on-prem is often a requirement for sensitive internal systems.
Technical requirements
- Route by path, header, or tenant; optional transformation and aggregation.
- Centralized auth (JWT, API key, or mTLS) and per-service or per-team quotas.
- Metrics and logs in your environment (Prometheus, Grafana, SIEM); no egress of traffic logs to third parties.
- High availability and zero-downtime rollouts; health checks and readiness for orchestrators.
- Self-hosted so infrastructure and data stay inside your perimeter.