Hacker News new | ask | show | jobs
by karmakaze 405 days ago
I've worked in monoliths done poorly and well, as well as bad and good implementations of microservices (even if done for the wrong reasons). The part of this post on 'if you go microservices' doesn't state things strongly enough. My takeaways comparing what worked vs what didn't:

- Use one-way async messaging. Making a UserService that everything else uses synchronously via RPC/REST/whatever is a very bad idea and an even worse time. You'll struggle for even 2-nines of overall system uptime (because they don't average, they multiply down).

- 'Bounded context' is the most important aspect of microservices to get right. Don't make <noun>-services. You can make a UserManagementService that has canonical information about users. That information is propagated to other services which can work independently each using the eventually consistent information they need about users.

There's other dumb things that people do like sharing a database instance for multiple 'micro'-services and not even having separately accessible schemas. In the end if done well, each microservice is small and pleasant to work on, with coordination between them being the challenging part both technically and humanly.