Architecture examples are most useful when their boundaries and arrows mean something specific. A layered application emphasizes responsibilities, an event-driven system emphasizes asynchronous work and a data platform emphasizes movement between storage and processing stages.
Layered application
A browser sends a request to an application, which applies business logic and reads or writes a database. This view introduces ownership and dependencies without showing every function. Label the request and response relationship, and keep the database behind the component that owns access.
Choose this example for a system overview or an early design conversation. Add a separate sequence diagram when a specific interaction needs detailed review.
Event-driven service
An API accepts work and places a task on a queue. A worker later processes the task and stores its result. The illustrated example uses that pattern for document jobs. The queue marks a change from immediate request handling to asynchronous execution; it does not guarantee any particular delivery or retry semantics.
Describe retries, deduplication and failure states explicitly when they matter. Keep storage writes and notifications visible so a reader can tell how completion becomes observable.
Data platform
A data platform view can show ingestion, raw storage, transformation and curated outputs. Label the datasets crossing each boundary, and distinguish batch jobs from streaming flows. Layers should explain a real difference in data readiness or responsibility.
Choose a data flow diagram for transformations and a system architecture diagram for the services that run them. Do not assume a visual layer automatically enforces access control.
Make it about your work
Edit this starting prompt, then send it when you are ready.