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.