6. Runtime View¶

Help: The runtime view describes concrete behavior and interactions of the system's building blocks in the form of scenarios from the following areas:

• Important use cases or features: how do building blocks execute them?
• Interactions at critical external interfaces: how do building blocks cooperate with users and neighboring systems?
• Operation and administration: launch, start-up, stop
• Error and exception scenarios

Motivation: You should understand how (instances of) building blocks of your system perform their job and communicate at runtime. You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders who are less willing or able to read and understand the static models (building block view, deployment view).

Form: There are many notations for describing scenarios, e.g.: - Numbered list of steps (in natural language) - Activity diagrams or flow charts - Sequence diagrams - BPMN or EPCs (event process chains) - State machines

6.1 \<Runtime Scenario 1: Key Use Case>¶

Help: Describe the most important runtime scenario first -- typically the primary use case or "happy path" that stakeholders care about most.

Description¶

\<Describe the scenario in 2-3 sentences. What triggers it? What is the expected outcome?>

Sequence Diagram¶

\<Insert a sequence diagram. Consider using PlantUML or Mermaid.>

Actor       -> API Gateway   : 1. HTTP Request
API Gateway -> Service A     : 2. Route request
Service A   -> Database      : 3. Query data
Database    -> Service A     : 4. Return results
Service A   -> Service B     : 5. Enrich with additional data
Service B   -> Service A     : 6. Return enriched data
Service A   -> API Gateway   : 7. Response
API Gateway -> Actor         : 8. HTTP Response

Step-by-Step¶

6.2 \<Runtime Scenario 2: Alternative/Error Path>¶

Help: Describe an important alternative or error scenario. How does the system behave when things go wrong?

Description¶

\<Describe what triggers this error scenario and how the system handles it.>

Error Handling Flow¶

Actor       -> API Gateway   : 1. HTTP Request
API Gateway -> Service A     : 2. Route request
Service A   -> Service B     : 3. Call dependent service
Service B   --X Service A    : 4. TIMEOUT / FAILURE
Service A   -> Service A     : 5. Circuit breaker opens
Service A   -> Cache         : 6. Fallback to cached data
Cache       -> Service A     : 7. Return stale data
Service A   -> API Gateway   : 8. Degraded response (200 + warning)
API Gateway -> Actor         : 9. Response with degradation notice

Behavior¶

6.3 \<Runtime Scenario 3: Asynchronous Processing>¶

Help: Describe scenarios involving asynchronous or event-driven processing.

Description¶

\<Describe the async workflow, what triggers it, and how eventual consistency is achieved.>

Event Flow¶

Service A   -> Message Broker : 1. Publish event
Message Broker -> Service B   : 2. Deliver event
Service B   -> Database B     : 3. Process and persist
Service B   -> Message Broker : 4. Publish completion event
Message Broker -> Service C   : 5. Deliver completion event
Service C   -> Notification   : 6. Notify user

6.4 \<Runtime Scenario 4: Startup/Shutdown>¶

Help: Describe the system startup and shutdown procedures if they are architecturally relevant.

Startup Sequence¶

1. \<Infrastructure provisioning / container orchestration readiness>
2. \<Database migration check and execution>
3. \<Configuration loading from config service>
4. \<Health check endpoint becomes available>
5. \<Service registers with service discovery>
6. \<Traffic routing begins>

Graceful Shutdown¶

1. \<Stop accepting new requests>
2. \<Complete in-flight requests (drain timeout: 30s)>
3. \<Deregister from service discovery>
4. \<Close database connections>
5. \<Flush logs and metrics>
6. \<Exit process>

Based on the arc42 architecture template (https://arc42.org).
Created by Dr. Peter Hruschka and Dr. Gernot Starke.
Licensed under CC BY-SA 4.0.