Single deployment If the system you are developing is intended to be delivered by a single team (or a single backend team), there might be less need for a decomposed solution where parts can be deployed separately. This also applies if you are starting out on something relatively small and don’t have the operations setup for doing microservices. If you still will want to structure your code in separate parts with clear API boundries between them you can define request/response, publish: /// <summary[...]

HTTP might be good enough For many systems there isn’t a need for message queues. Regular HTTP-style request/response are often enough. If your system is architected without thinking about events you might have very little need for it. A webhook can be good enough. It all depends on your architecture and business scenarios if it makes sense. What good is a message queue A message queue is good for dealing with asynchronous messages not expected to be dealt with immediately. You can also use a message q[...]

HTTP might be good enough For many systems there isn’t a need for message queues. Regular HTTP-style request/response are often enough. If your system is architected without thinking about events you might have very little need for it. A webhook can be good enough. It all depends on your architecture and business scenarios if it makes sense. What good is a message queue A message queue is good for dealing with asynchronous messages not expected to be dealt with immediately. You can also use a message q[...]

Service mesh Service mesh looks like an evolution of Enterprise Service Bus and has similar focus. An ESB is a single point of failure. Since it’s a combination of many concerns, it can be hard to get right. A service mesh tries to mitigate this by focus mainly on HTTP, HTTP2 style communication and being distributed as a deployment (each service has it’s own copy of the mesh software). Typical concerns Security (restrict traffic between services, use ssl for internal communication) Observability ([...]

Service mesh Service mesh looks like an evolution of Enterprise Service Bus and has similar focus. An ESB is a single point of failure. Since it’s a combination of many concerns, it can be hard to get right. A service mesh tries to mitigate this by focus mainly on HTTP, HTTP2 style communication and being distributed as a deployment (each service has it’s own copy of the mesh software). Typical concerns Security (restrict traffic between services, use ssl for internal communication) Observability ([...]