In front of your microservices

An internal application is no longer a program: it is a dozen services, written in several languages, shipped by several teams. The question is then not only what a gateway can do, but where it goes.

One door, not a library per service

Every one of those services needs to know who is calling and what that person is allowed to do. Answered service by service, that means as many login pages as services, as many user tables, and sessions that do not mean the same thing from one service to the next. Answered once, in front, it means a door.

Browser your users API client integrations, machines Operator or an AI agent :9090 console :8080 applications Meerkat one binary, two ports sign-in, MFA, SSO, sessions access rules, roles, organisations routing, rate limits, TLS, vault audit, traffic, issue reports UI route API route orders-ui Angular billing-ui React orders-api Go invoices-api Java your services, unchanged + they receive the portal, the account button, the theme and the colour scheme - and ship no library for it + they receive a signed token: who is calling, their roles and their organisation - and they authenticate nobody
The path of one request: it reaches the gateway, which decides, and leaves for the service concerned - an interface or an API.

A UI route is a page a person looks at, so the gateway adds to it on the way through: the navigation portal, the account button, the theme, light and dark mode, injected into the HTML. The application carries nothing for that and does not even know.

An API route is called by a program, so there is nothing to add. It receives a signed token saying who is calling, with their roles and their organisation, and it authenticates nobody. A service is often both: its pages behind a UI route, its own API behind an API route.

In the cluster

your cluster Browser your users API client integrations, machines Operator or an AI agent :8080 applications Ingress, or your load balancer the only published point :9090 console three interchangeable replicas meerkat :8080 :9090 meerkat :8080 :9090 meerkat :8080 :9090 UI routes API routes orders-ui Angular billing-ui React orders-api Go invoices-api Java your services, unchanged PostgreSQL the shared state sessions, routes, audit None of your services is published: only the gateway is.
One published point, several interchangeable replicas behind it, and your services staying inside.

Your ingress publishes one thing: the gateway's application port. Your services stay reachable from inside the cluster only, so none of them has a door to guard. The admin console is not on that port at all: it has its own, on an internal network.

Behind the ingress, several replicas serve the same routes. They never talk to each other: what they have in common is in the database, and a route that changes reaches the others in a second. Sessions live there too, so there is no affinity to ask of the load balancer: a request lands on any replica, and a rolling update takes nobody's session with it.

That shared state needs a PostgreSQL, and it is an Enterprise capability. One gateway on its embedded storage shares nothing with anybody and does not need it: that is the community edition, and it carries a whole application.

What your services stop carrying

The login page

It is served by the gateway, in your colours, with the password, the second factor, passkeys and your corporate directory behind it. None of your services has one any more.

The user table

Accounts, roles, groups and organisations are in the gateway. Your services no longer store identities and no longer have to keep them agreeing with each other.

The access rules

Who gets through is decided at the door, per route and down to one operation of your OpenAPI spec. The rule changes without redeploying the service it protects.

The shared interface

The navigation portal, the account button and the theme arrive in the HTML on the way through. A new application gets them without a line of code.

Where the gateway does not go

Traffic between your services stays between your services. Meerkat holds the door, which is what comes in and who is allowed, not the cluster's internal circulation. If you already run a service mesh for east-west traffic, the two do not overlap: one takes care of your services among themselves, the other of the world knocking.

Adding a service

Declare the route

A path, a target, and the gateway routes. From the console, from the admin API, or by letting an agent do it.

Say whether it is an interface or an API

That decides whether the page gets the portal and the account button, or the request leaves with a signed token.

Set the access rule

A level, roles, named accounts, and if needed a rule per operation taken from the service's spec.

The service itself does not move: it carries no library of ours, speaks no protocol of ours, and does not know it is behind a gateway.

The detail

The full Kubernetes shape, with the Deployment, the two Services, the Ingress and the probes, is on Kubernetes cluster. The two planes and what separates them are on Architecture. What the same assembly costs otherwise is on the case for Meerkat.