Sequence Diagrams — Benchmark Gallery

A user enters their credentials into the login interface, which forwards them to the authentication service for verification. The authentication service loads the matching record from the user database and internally verifies the password hash. The interface then receives an access token in return and notifies the user of the successful login.

A bank customer initiates a transfer in their banking app, which is submitted as a request to the transfer service. The transfer service first queries the current account balance in the account database and then posts the transfer there. After a successful booking, the app receives a transaction reference number and displays a confirmation to the customer.

A buyer enters a search term in the web shop, which is passed to the search service. The search service finds matching products in the product catalog and returns the results list to the shop. Only if results are found does the shop additionally load the associated product images from the catalog before displaying the results page to the buyer.

A customer initiates the checkout process in the shop, whereupon the checkout service has the stored payment details verified by the payment gateway. If the check is positive, the order is saved in the database and the payment is subsequently processed via the gateway. If the payment details are invalid, the process is instead rejected with an error message. In both cases the customer sees the result displayed in the shop at the end.

A client requests data via the API gateway, which checks with the rate limiter before forwarding whether the client’s quota has not yet been exhausted. If quota is still available, the request is forwarded to the backend service and the data is returned to the client; otherwise the client receives a rejection for too many requests. After a rejection the client waits a backoff period and retries the request, up to three times.

A user requests a password reset via the web portal, and the authentication service looks up the provided email address in the user database. If the user exists, the service internally generates a reset token, stores it in the database and triggers sending of the reset email without waiting for its completion. If the address is unknown, the service responds with the same innocuous success message for security reasons. In both cases the user sees only a neutral notification.

A client calls the order endpoint via the API gateway carrying a JWT, which first checks the token cache to see whether the token has already been validated. If there is no cache entry, the gateway has the token verified by the authentication service and stores the result in the cache as a side effect. If the token is valid, the request is forwarded to the order service and the order list is returned; if the token is invalid, access is denied.

A customer places an order, whereupon the order service instantiates a dedicated saga orchestrator that coordinates the distributed transaction and writes each step concurrently to an event log. The orchestrator first reserves the items in the warehouse service; only if the goods are available is the payment executed and the shipment subsequently commissioned. If the payment fails, the warehouse reservation is cancelled as a compensating step; if the goods are not available at all, the transaction is aborted immediately. After completion the orchestrator is torn down and the customer is informed of the order status.

A user initiates login in a client application and is redirected via browser to the authorization server, which creates a new session in the session store for the process and delivers a login form. After entering credentials, the server issues an authorization code upon successful verification, which the client application exchanges via its callback for an access token; the issuance is concurrently noted in the audit log. If the requested scope includes the profile, the application additionally retrieves the user data from the resource server, which has the token re-verified by the authorization server before releasing it. If the credentials are wrong, the created session is discarded and the user sees an error message.

Camera and radar sensors simultaneously and without acknowledgement deliver their measurement data to the fusion unit, which internally computes a consolidated environment model from it and reports a collision risk with time-to-collision to the emergency braking assistant. If this time-to-collision falls below the critical threshold, the assistant warns the driver acoustically, initiates an autonomous braking maneuver and repeatedly adjusts the brake pressure at the control unit until the vehicle is stationary; the maneuver is then ended and the event is recorded in the diagnostic log. If the time-to-collision is above the threshold, the driver is at most shown a distance warning and the observed risk is concurrently logged.