Hacker News new | past | comments | ask | show | jobs | submit login

No specific strategy, I'm still trying to figure out what makes some diagrams better than others, and how to design diagrams which "works". The one I've used which have gotten the most spread in the company I'm working at were is one which mapped the transformation of a specific state in the microservice architecture. The state in question is highly central to our products success, and it reflects many (but not all) the relations between services. The dataflow were from leaf entrypoints, through processing, and finally stopped at internal consumer endpoints. The result is a reversed tree structure where each node is a microservice/external service (text in node explains which one, and linked to gitlab project) and each edge said which protocol is used for them to communicate. So, it reflects what services are required for a specific customer, depending on which path the customer takes in order to produce this state for internal consumers. Doing this enabled us to also analyze the "hot path", and "cold path" to know what services were problematic (rarely used/overused/too poorly written considering their importance/etc) and not.

But in general, it needs to look nice. It should be pleasing for the eye to watch the diagram, should spark curiosity to investigate how the system works. Straight lines, consistent shapes for specific meanings, colour coded blobs. Directed edges also seems to work well. Once I told an ops guy "start here at the leaf, then follow the arrows", it really clicked for him. And at the end of the day, it's a frontend, with all it's ups and downs, and should be treated as such.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: