Ask HN: What micro-services work best? | Hacker News Reader

Ask HN: What micro-services work best?

4 pointsevanmoran3 comments

There is a lot of discussion on if micro-services are worth having or which tech stacks to use, but I’ve been curious recently if anyone has good examples of specific micro-services that have worked well within their own startups/companies?

I’m especially interested if you’ve felt there was a good separation of data from each service and what the service specifically did (identity management, email marketing, or more). Did it turn out two services were secretly one and you merged them later? Did you split any out? Also did you use a lot of message queuing services and did you find it necessary or too much overhead?

(A bit of background: I’m working on a service that is a collaborative editor like Google Docs with shared drive/files per organization and I’m currently thinking through the service boundaries. Thank you!)

View on HN

I did contract work for Under Armour and their setup used microservices for everything (facet search, tax calculation, shipping calculation, cart, checkout, user data, etc). They used Docker and Kubernetes for nodejs apps for each service, and gRPC/protobuf for communication, and Kafka for message queuing. It was a good setup, since one service going down didn't take down the whole app. I remember facet search went down (it was ElasticSearch and something in the index broke). You could still browse and add to cart, checkout and most users probably didn't even notice unless they wanted to search by material or color. Similarly shipping calculation broke once but it had a fallback so that when the service was down instead of hitting the shipping partner API and returning the actual shipping cost (e.g. $5.65) it would return a sensible estimate (e.g. $6). Almost every service was set up so that if the service was down temporarily, messages were queued and processed later.

This is great, thank you. I do keep hearing about Kafta but I’m still mulling over what is in a message queue vs a db with similar state. For example a email queue could add an item for every email to send out. Is that clearer than an email table that queries for missing items and deletes the records when sent?

I think the benefit is that the services don't have to communicate directly with each other. So you have a user's cart that needs tax and shipping calculated. So you add a message to the queue, and one of the hundreds of nodes in the shipping cluster grabs the message and processes it.

In your example, a database storing outgoing messages could be a single point of failure or performance bottleneck. But a distributed message queue would be more fault tolerant. You could have hundreds of sending nodes reading from the outgoing mail queue and sending out emails.

Reply on news.ycombinator.com