Architecture

Mastering System Design Through Diagrams: A Personal Journey A few years ago, I found myself in an interview where I was asked about architecture diagrams—and honestly, I choked. That moment was a wake-up call. I realized that if I wanted to be confident in system design and convey my ideas clearly, I needed to make diagrams a core part of my process. Today, I’m sharing my step-by-step approach to diagramming through the various stages of system development. Not only will this guide help you in interviews, but it also serves as a roadmap to developing well-thought-out systems. ...

Below is an example of a Mermaid diagram that shows a high-level context diagram for our event-based reservation system using Wolverine. In this diagram, you can see external actors (like customers, an administrator, payment gateway, etc.) interacting with internal components such as a Reservation Frontend, Reservation Service, and the Wolverine Event Bus responsible for handling events. flowchart LR %%External Actors Customer[Customer] PaymentGateway[Payment Gateway] NotificationService[Notification Service] Administrator[Administrator] ResourceCatalog[Resource Catalog] %%Internal System Components subgraph System [Reservation System] Frontend[Reservation Frontend] Service[Reservation Service] EventBus[Wolverine Event Bus] end %%Interactions between External Actors and the System Customer -->|Creates/Manages Booking| Frontend Frontend --> Service Service -->|Publishes Events| EventBus EventBus -->|Notifies| PaymentGateway EventBus -->|Notifies| NotificationService Service -->|Checks Availability| ResourceCatalog Administrator -->|Manages System| Service Explanation External Actors: ...

Here is a Use Case Diagram for our reservation system, which visualizes the interactions between users (actors) and the system’s functionalities (use cases). graph TD %% External Actors Customer[Customer] --> CreateReservation Customer --> CancelReservation Customer --> ViewReservationDetails Customer --> ReceiveNotifications Administrator[Administrator] --> ManageResources Administrator --> GenerateReports Administrator --> ViewCustomerDetails %% System subgraph ReservationSystem [Reservation System] CreateReservation[Create Reservation] CancelReservation[Cancel Reservation] ViewReservationDetails[View Reservation Details] ReceiveNotifications[Receive Notifications] ManageResources[Manage Resources] GenerateReports[Generate Reports] ViewCustomerDetails[View Customer Details] end Explanation of the Diagram Actors: ...

Here’s an example of a Flowchart that represents a simple workflow for a reservation system, illustrating key steps in the booking process. graph TD Start[Start] --> EnterDetails[Customer Enters Reservation Details] EnterDetails --> CheckAvailability[Check Resource Availability] CheckAvailability -->|Available| ProceedPayment[Proceed with Payment] CheckAvailability -->|Not Available| DisplayError[Display Error Message] ProceedPayment --> ConfirmReservation[Confirm Reservation] ConfirmReservation --> SendNotification[Send Confirmation Notification] SendNotification --> End[End] Explanation of the Workflow: Start: The process begins when a customer initiates a reservation. Enter Details: The customer provides reservation details (e.g., date, time, resource). Check Resource Availability: The system verifies if the requested resource is available. If available, the workflow proceeds to payment. If not available, an error message is displayed to the customer. Proceed with Payment: The customer completes the payment process. Confirm Reservation: The system confirms the reservation after successful payment. Send Notification: A confirmation message (email/SMS) is sent to the customer. End: The workflow concludes.

Below is an example of an Architecture Diagram for our event-driven reservation system, illustrating a microservices architecture. It highlights the relationships between components, external systems, and underlying patterns used. flowchart TB %% External Clients Customer[Customer Frontend] Admin[Administrator Panel] %% Gateway Layer subgraph Gateway[API Gateway] GatewayService[Routing & Security] end %% Service Layer subgraph ServiceLayer[Service Layer] ReservationService[Reservation Service] ResourceService[Resource Catalog Service] NotificationService[Notification Service] PaymentService[Payment Service] end %% Event Handling Layer subgraph EventLayer[Event Handling Layer] EventBus[Wolverine Event Bus] end %% Data Layer subgraph DataLayer[Data Layer] ReservationDB[Reservations Database] ResourceDB[Resources Database] CustomerDB[Customers Database] end %% External Services ExternalNotification[Third-Party Notification System] ExternalPaymentGateway[Third-Party Payment Gateway] %% Interactions Customer --> GatewayService Admin --> GatewayService GatewayService --> ReservationService GatewayService --> ResourceService ReservationService --> ReservationDB ResourceService --> ResourceDB ReservationService --> CustomerDB ReservationService --> EventBus EventBus --> NotificationService EventBus --> PaymentService NotificationService --> ExternalNotification PaymentService --> ExternalPaymentGateway Breakdown of the Diagram External Clients: ...

Below is a Mermaid diagram that outlines a component diagram for your event-based reservation system using Wolverine. This diagram breaks down the core components and shows how they interact with each other and with external systems. graph TD %% External Systems PG[Payment Gateway] NS[Notification Service] RC[Resource Catalog] %% Reservation System Components subgraph Reservation_System [Reservation System] FE[Reservation Frontend] RS[Reservation Service] DO[Durable Outbox] EB[Wolverine Event Bus] EH[Event Handlers] end %% Internal Interactions FE -->|User Requests| RS RS -->|Persists Events/Commands| DO RS -->|Publishes Events| EB EB --> EH RS -->|Checks Availability| RC %% External Interactions via Event Bus EB -->|Notifies| PG EB -->|Notifies| NS Explanation Reservation System Components: ...

Here’s an example of a Level-1 Data Flow Diagram (DFD) for our reservation system. It highlights how data moves between external entities, processes, and storage components. flowchart TD %% External Entities Customer[Customer] ResourceCatalog[Resource Catalog] PaymentGateway[Payment Gateway] NotificationService[Notification Service] %% Processes Process1[Submit Reservation] Process2[Check Resource Availability] Process3[Process Payment] Process4[Notify Customer] %% Data Stores D1[Reservation Data Store] D2[Customer Data Store] %% Data Flows Customer -->|Reservation Details| Process1 Process1 -->|Reservation Data| D1 Process1 -->|Customer Details| D2 Process1 -->|Resource Details| Process2 ResourceCatalog -->|Resource Availability| Process2 Process2 -->|Reservation Confirmation| Process1 Process1 -->|Payment Info| Process3 PaymentGateway -->|Payment Status| Process3 Process3 -->|Notification Request| Process4 Process4 -->|Notification| NotificationService Explanation External Entities: ...

Below is an example of a Mermaid class diagram representing the core classes for our event-based reservation system to visualize the relationships between the entities, services, and events. classDiagram %% Domain Entities class Customer { +int Id +string FullName +string Email } class Resource { +int Id +string Name +string Description } class Reservation { +int Id +int CustomerId +int ResourceId +DateTime StartDate +DateTime EndDate +ReservationStatus Status } %% Service Layer class ReservationService { +CreateReservation(customerId: int, resourceId: int, startDate: DateTime, endDate: DateTime) Reservation +CancelReservation(reservationId: int) bool } %% Domain Events class ReservationCreatedEvent { +Guid ReservationId +DateTime CreatedAt +int CustomerId } class ReservationCancelledEvent { +Guid ReservationId +DateTime CancelledAt +int CustomerId } %% Event Handling Component class ReservationEventHandler { +Handle(event: ReservationCreatedEvent) +Handle(event: ReservationCancelledEvent) } %% Associations Customer "1" --o "0..*" Reservation : creates Resource "1" --o "0..*" Reservation : assigned to ReservationService ..> ReservationCreatedEvent : publishes ReservationService ..> ReservationCancelledEvent : publishes ReservationEventHandler ..> ReservationCreatedEvent : handles ReservationEventHandler ..> ReservationCancelledEvent : handles %% Note: ReservationStatus is an enumeration (e.g., Pending, Confirmed, Cancelled) Explanation Domain Entities: ...

Below is a Mermaid sequence diagram that showcases how components of our event-based reservation system interact during a typical workflow. This example outlines the process of a customer creating a reservation and includes key components such as the frontend, service layer, Wolverine event bus, and external systems. sequenceDiagram participant Customer participant Frontend participant Service as Reservation Service participant EventBus as Wolverine Event Bus participant ResourceCatalog participant Notification as Notification Service Customer ->> Frontend: Request to create a reservation Frontend ->> Service: Submit reservation details Service ->> ResourceCatalog: Check resource availability ResourceCatalog -->> Service: Availability status Service ->> Service: Validate and process reservation Service ->> EventBus: Publish ReservationCreated event EventBus ->> Notification: Notify customer of confirmation EventBus -->> Service: Acknowledge event publishing Service -->> Frontend: Return confirmation to customer Frontend -->> Customer: Display confirmation details Explanation of the Workflow Customer Interaction: ...

Below is a System Sequence Diagram for a reservation system, which highlights the interaction between external actors (e.g., customer, administrator) and the system during a reservation workflow: sequenceDiagram participant Customer participant System as Reservation System Customer ->> System: Enter reservation details System -->> Customer: Validate inputs Customer ->> System: Submit reservation request System ->> System: Check resource availability alt Resource available System ->> System: Create reservation System ->> Customer: Confirm reservation System ->> System: Trigger payment process System ->> Customer: Notify payment status else Resource not available System ->> Customer: Display unavailability message end Explanation of the Diagram: Actors and System: ...