Skip to main content

Microservice Design and Evolution

Individual Ports

An original microservice idea: each endpoint is an individual service / server that runs on its own port. Good for isolation. Impractical for implementation of large sets. You can still use AWS Lambda, GCP Cloud Functions etc. to isolate a specialized endpoint. But if it’s part of a set: teams usually group them into one service / container. Seen here via a swagger explorer.

Cloud Run

Scheduled and Random Restarts

Another microservice idea is for the service to randomly reboot every n seconds. A way to resolve memory leaks, deadlocks etc. The idea: ensure service scalability and that it could handle a crash / restart. A kill endpoint is another way to invoke it. Once a day is still common.

Kubernetes Liveness Probes

Another common practice is to monitor service (pod / container) health in kubernetes with a liveness probe. Like hitting a simple endpoint and restarting if it times out. It can also be manipulated through chron settings to invoke a daily restart.

Docker and PM2

You can use tools like docker and pm2 to automatically restart service containers on a crash too. Helpful for developing and testing recovery on your local machine.

Chaos Monkey

The kill endpoint can also be used by chaos monkey tools to test how the server handles extreme conditions. Just make sure the endpoint requires a special auth header so bad actors can’t mess with your site.