Conventions for Drawing Arrows in Architectural Diagrams
When drawing architectural diagrams, are we supposed to draw arrows that show flow of information, or arrows that show what service calls what? Or does it follow whether it is GET or PUT? Does it matter, as long as we are consistent?
For example, if putting an objects in an S3 bucket triggers a lambda function, and the lambda function then passes the object to an API, do the arrows go:
S3 -> Lambda -> API, since that is flow of information.
or is it:
S3 <- Lambda -> API
Since the Lambda passes the object to the API?
- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
As always, "it depends". But I would draw it S3 -> Lambda -> API because you're drawing the flow of information. If you wanted to be super clear, you would label the arrows S3 --Trigger--> Lambda --Calls--> API and then because Lambda is retrieving the object from S3 you would put another arrow there between Lambda and a second S3 "object".
A good reference would be UML Sequence Diagrams. In a system, the arrow represents the flow of events or data.
Relevanter Inhalt
AWS OFFICIALAktualisiert vor 3 Jahren- AWS OFFICIALAktualisiert vor 3 Jahren
- AWS OFFICIALAktualisiert vor 3 Jahren
- AWS OFFICIALAktualisiert vor 3 Jahren