Assessing Architectural Structures and Paradigms

Review the architectural aspects of an event-driven transit app.

Establishing an architectural baseline helps to drive decisions regarding how the application and its components will ultimately be implemented. Additionally, it also provides an opportunity to evaluate different patterns and practices with the ultimate goal of selecting a path forward. This lesson covers the overall architectural design of the sample application and some core tenets that enable the creation and consumption of events.

A high-level logical architecture

The solution is predicated on the use of hardware interfaces (such as equipment) that can communicate to hosted services in the cloud via a standard network connection. There’s a hardware gateway (such as Raspberry Pi) that hosts simple write-only services, which will integrate using relevant domain services to record turnstile usage, facial recognition hits, and possible malfunctions with the turnstile or camera. Any user interface can interact with a common API gateway layer, which allows for data exchange without needing to know all the particulars of the available APIs. The backend runtime is managed by Kubernetes (in this particular case, AKSAzure Kubernetes Service), with containers for each available domain microservice. Each microservices interacts with the event bus to send events. Then, the events are handled according to the domain’s applicable event handlers. A reporting layer is used to access information captured via the event stream. SQL databases will be used to maintain the append-only activity log of events that come in via Kafka and read models will be consumed from domain databases using read-oriented services.

The following reference illustration shows the logical construction of the application:

Create a free account to view this lesson.

By signing up, you agree to Educative's Terms of Service and Privacy Policy