Architecture and Dataflow Flowchart

[drewjj]

PR Details

Description

This pull request includes a flowchart to help explain the complexities of the CV Manager and how it communicates throughout all of its microservices and databases.

The diagram was made using draw.io and the readme was updated to include the diagram.

How Has This Been Tested?

N/A

Types of changes

• Defect fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that cause existing functionality to change)

Checklist:

• My changes require new environment variables:
  • I have updated the docker-compose, K8s YAML, and all dependent deployment configuration files.
• My changes require updates to the documentation:
  • I have updated the documentation accordingly.
• My changes require updates and/or additions to the unit tests:
  • I have modified/added tests to cover my changes.
• All existing tests pass.

[dmccoystephenson]

Looks great to me, this is awesome!

[jacob6838]

A few small comments:

1. The Conflict Visualizer API reads from Kafka (live intersection data)
2. Technically, the webapp and both APIs talk directly with Keycloak. If this adds too much clutter I guess its ok
3. Arrow directions
   • The cvmanager API -> postgres arrow should be bi-directional
   • The Conflict Visualizer API -> MongoDB arrow should be bi-directional
   • The Conflict Visualizer API -> PostgreSQL arrow should be reversed (from postgres to API)

[John-Wiens]

I believe that RSU units receive BSMs from OBU units. I think we need an arrow from the OBU units to the RSU units. We could also consider an arrow from the OBU units back to itself because OBUs can communicate directly with one another via BSMs.

[drewjj]

A few small comments:

1. The Conflict Visualizer API reads from Kafka (live intersection data)

2. Technically, the webapp and both APIs talk directly with Keycloak. If this adds too much clutter I guess its ok

3. Arrow directions

   • The cvmanager API -> postgres arrow should be bi-directional
   • The Conflict Visualizer API -> MongoDB arrow should be bi-directional
   • The Conflict Visualizer API -> PostgreSQL arrow should be reversed (from postgres to API)

I wrote the arrows from the perspective of the origin of the request.

[jacob6838]

A few small comments:

1. The Conflict Visualizer API reads from Kafka (live intersection data)

2. Technically, the webapp and both APIs talk directly with Keycloak. If this adds too much clutter I guess its ok

3. Arrow directions

   • The cvmanager API -> postgres arrow should be bi-directional
   • The Conflict Visualizer API -> MongoDB arrow should be bi-directional
   • The Conflict Visualizer API -> PostgreSQL arrow should be reversed (from postgres to API)

I wrote the arrows from the perspective of the origin of the request. Not sure how PosgreSQL would cause the API to do something unless it was periodici

ah ok, I was thinking of which way the information flowed

[drewjj]

I believe that RSU units receive BSMs from OBU units. I think we need an arrow from the OBU units to the RSU units. We could also consider an arrow from the OBU units back to itself because OBUs can communicate directly with one another via BSMs.

In my opinion, this is borderline out of scope since it is more of an edge architecture detail. I could see it being justifiable since it will explain the origin of the BSM message if someone was trying to trace the dataflow beyond the edge RSU forwarding them. I will add a line between the OBU and RSU.

[drewjj]

I am going to adjust this diagram to follow the dataflow as the name suggests to prevent confusion.

[Michael7371]

LGTM!

[jacob6838]

Changes look great!