I can't tell you the exact traffic because I don't really know. Basically the every big company used our product and this service handled notifications across the system. If something happened to something you were interested in our system did something (technical, I know).

It didn't follow some established microservice best practice/architecture so I can't really answer the other questions in a helpful way but interaction was via shared bus/pub-sub/REST. Discovery was sending an IM to someone on our team saying "Hey I want to use your thing". It was a pragmatic approach where every team was given large amounts of leeway to develop their service how they felt they should. The goal was looser coupling of systems really. It was a good sized organization so they wanted people specializing in their areas and the freedom to make changes without impacting the entire organization. If I decided to rip out the database and replace it with something else only my team is impacted. The rest of the company doesn't care if as long as it works.

The Fowler link shared below is fantastic. It really is true, our app was a monolithic application we started breaking up and building microservices around it to extend it. We never started off on a microservice path originally, we didn't think it would get as big as it did. Really there are trade offs and the answer to your question is "it depends". If you're a small group of co-located developers building a reasonably complex system it may not be needed. I would honestly take the approach of a monolithic system that is compartmentalized and allows you to break things off if they get too big. You'll know when it happens.