Architecture · Runtime · Observability

One Graph.
Design, Run, and Observe
Your Distributed System.

Every request leaves a visual trace through the exact graph that defines and runs your service. Draw the architecture — it generates the code, executes in production, and shows you everything in real time.

1graph = architecture + runtime + traces
0lines of wiring to write
100%execution visibility
Order Pipeline — Live
requestresponseInputSplitProcessDelayErrorMapMerge
7 nodes8ms avg latency✓ fully traced

See It in Action

Open Service Architect is for distributed systems what React is for UI.
1You describe a graph.
2The framework generates the wiring.
3You implement business logic.
4Every execution is traced through the same graph.
The graph is the architecture. It runs the system. It is always accurate by definition.

Stop Thinking in Code

Code is an implementation detail.
Architecture is what matters.

Every system you build starts as a diagram on a whiteboard. Boxes, arrows, flows. That picture is the real design — clean, understandable, true.

Then you translate it into code. And from that moment, the diagram starts lying.

Service Architect keeps the diagram alive. It is the system — not a description of it. What you draw runs in production. What runs in production is what you drew.

Any process is a node. A single API endpoint. Or a full pipeline of transformations. The level of detail is your choice — the graph scales with your thinking.
🔄
The diagram never drifts. There is no "update the docs." The graph generates the service, so architecture and reality are always the same thing.
🚀
Onboarding in an hour. A new developer opens the graph and understands the system immediately — no week of reading code, no archaeology through git history.

Modern Backends Are Hard

Building distributed systems means dealing with complexity that compounds at every layer.

MicroservicesAPIsEvent StreamsAsync WorkflowsRetriesError PropagationObservabilityDocumentation Drift
The bigger the system gets, the harder it becomes to answer:
"What is happening right now?"

What It Costs — And What You Get Back

You don't need to understand distributed systems to understand this: your engineering team is spending most of its time building infrastructure nobody sees, instead of features customers pay for.

60–80%
Less Infrastructure Code
The majority of what engineers write for a new service — boilerplate, wiring, observability setup — is generated automatically.
2–4 weeks
Faster First Delivery
A production-ready service with endpoints, tracing, and metrics goes from whiteboard to running code in days, not months.
10×
Faster Debugging
Visual execution traces eliminate the guesswork. Engineers see what happened, where, and why — without reading logs.
Today

A new service takes 2–4 weeks before a single business line ships — engineers write HTTP handlers, middleware, configs, metrics, tests from scratch.

With Service Architect

The graph generates all of that in seconds. Engineers open a code editor and write only business logic on day one.

Today

Architecture diagrams are drawn once and never updated. Nobody trusts them six months later.

With Service Architect

The graph is the architecture. It runs the system. It is always accurate by definition.

Today

When something breaks in production, engineers spend hours reading logs trying to reconstruct what happened.

With Service Architect

Every request leaves a visual trace through the graph. The team sees exactly which node failed and what data it held.

Today

Giving a feature to an AI assistant means handing it the entire codebase and hoping it doesn't break anything.

With Service Architect

AI gets a single, bounded function with clear inputs and outputs. The scope is enforced by the graph structure.

Who uses this
🚀

Startups

Ship backend services without a dedicated platform team. Move as fast as a large engineering org from day one.

📈

Scale-ups

Standardize how services are built across teams. Eliminate the inconsistency that comes with ten engineers making ten different infrastructure choices.

🏢

Enterprise

Reduce the cost of maintaining distributed systems. Get visibility into every service without a dedicated observability team.

💼

Investors

The code generation and AI-integration market is growing fast. This is a developer tool with a clear ROI story and zero runtime lock-in.

The Graph Is The System

Not a diagram of the system. Not documentation that will drift. The graph defines, generates, and runs your service — simultaneously.

Draw the Architecture

Model services, pipelines, and connections as a graph. Any process — from a single API endpoint to a complex async workflow — is a node.

Run What You Drew

The graph generates a complete Go service and runs it. Transport, metrics, tracing, config — all wired from the same definition.

🔭

See Every Execution

Every request traces through the exact nodes it touched — on the same graph you designed. Architecture and observability are one thing.

Writing it by hand
// HTTP handler
func processOrderHandler(w http.ResponseWriter, r *http.Request) {
    var req ProcessOrderRequest
    if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
        http.Error(w, err.Error(), 400); return
    }
    ctx, cancel := context.WithTimeout(r.Context(), 30*time.Second)
    defer cancel()

    orderID := uuid.New().String()
    results := make(chan OrderItemResult, len(req.Items))
    errs    := make(chan error, len(req.Items))

    var wg sync.WaitGroup
    for _, item := range req.Items {
        wg.Add(1)
        go func(item OrderItem) {
            defer wg.Done()
            span, ctx := tracer.StartSpanFromContext(ctx, "inventory.check")
            defer span.Finish()
            conn, err := grpc.DialContext(ctx, cfg.InventoryAddr,
                grpc.WithInsecure(),
                grpc.WithUnaryInterceptor(otelgrpc.UnaryClientInterceptor()),
            )
            if err != nil { errs <- err; return }
            defer conn.Close()
            client := pb.NewInventoryClient(conn)
            res, err := client.ProcessOrderItem(ctx,
                &pb.ProcessOrderItemRequest{
                    Sku: item.SKU, Quantity: int32(item.Qty),
                })
            if err != nil { errs <- err; return }
            results <- OrderItemResult{SKU: item.SKU, Reserved: res.Reserved}
        }(item)
    }

    // deadline ticker
    softDeadline := time.NewTimer(cfg.SoftDeadlineDuration)
    defer softDeadline.Stop()

    var confirmed []OrderItemResult
    received := 0
    status := "CONFIRMED"
    for received < len(req.Items) {
        select {
        case r := <-results:
            confirmed = append(confirmed, r)
            if !r.Reserved { status = "PARTIALLY_CONFIRMED" }
            received++
        case err := <-errs:
            log.Error("item error", zap.Error(err))
            received++
        case <-softDeadline.C:
            status = "TIMED_OUT"; goto done
        case <-ctx.Done():
            status = "TIMED_OUT"; goto done
        }
    }
done:
    // metrics
    orderDuration.Observe(time.Since(start).Seconds())
    ordersTotal.With(prometheus.Labels{"status": status}).Inc()

    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(ProcessOrderResponse{
        OrderID: orderID, Status: status,
        ConfirmedItems: confirmed,
    })
}
~80 lines · goroutines, waitgroups, timeouts, gRPC wiring, tracing, metrics, error propagation — all manual
The same thing as a graph
HTTP Input · Process Order
Split
↓ ↓
FlatMap → gRPC Sink → Map
Delay → Map
Merge → Response
6 nodes · goroutines, timeouts, gRPC, tracing, metrics — generated. You write only the business logic.
Graph Definition (example.yaml)
settings:
  name: Example
services:
  orderService:
    pipelines:
      order:
        processOrder:
          type: Input
          endpoint: processOrder
          valueType: order
        splitPipeline:
          type: Split
          source: processOrder
        softDeadline:
          type: Delay
          source: splitPipeline
          fn: SoftDeadline
        processOrderItems:
          type: FlatMap
          source: splitPipeline
          valueType: orderItem
          fn: ProcessOrderItems
        processOrderItem:
          type: Sink
          source: processOrderItems
          endpoint: processOrderItem
        mergeResults:
          type: Merge
          sources: [mapToOrderState, mapOrderItemResult]
↓ generates
Complete Go Services
http_service.generated.gogrpc_service.generated.goservice.generated.goconfig.generated.gomake.generated.mkserdes/order.goinventoryserviceapi.protoinventoryserviceapi.pb.gografana/dashboards/ (×11)Dockerfileci.yml+docs, config, scripts…
↓ runs as
Running System
Live · Traced · Metered · Observable

Let AI Implement Business Logic

Instead of asking AI to generate an entire application — constrain it to one function at a time. The framework handles everything else.

Traditional AI Code Gen
  • Generates 2000+ lines of uncontrolled code
  • Invents its own architecture
  • Unknown external dependencies
  • Impossible to test in isolation
  • Breaks unpredictably in production
VS
With Service Architect
AI only implements this:
func (f *GetInventoryItemData) Process(
    _ context.Context,
    _ runtime.Stream,
    value *types.OrderItem,
    out  runtime.Collect[*types.OrderItemResult],
    rout runtime.Collect[*types.OrderItemResult],
) {
    result, err := f.db.ReserveStock(value.SKU, value.Quantity)
    if err != nil || !result.Reserved {
        rout.Collect(&types.OrderItemResult{
            SKU: value.SKU, Status: "OUT_OF_STOCK",
            AvailableQty: result.AvailableQty,
        })
        return
    }
    out.Collect(&types.OrderItemResult{
        SKU: value.SKU, Reserved: true, Status: "CONFIRMED",
        AvailableQty: value.Quantity,
    })
}
Pure business logic. Inputs, outputs, error path — all defined by the graph.
🎯

Smaller Tasks

AI stays focused on a single, well-defined function — not an entire application.

Better Code Quality

Bounded context with clear inputs and outputs means fewer mistakes and cleaner logic.

🧠

Less Hallucination

AI doesn't need to invent infrastructure — it only implements business logic within a strict contract.

👁

Easier Reviews

10 lines of business logic is easy to review. 2000 lines of generated scaffolding is not.

Every Request, Traced Through The Graph

Execution traces aren't separate from your architecture — they run through the exact graph you drew. Click any node, see every request that touched it, and drill down to the exact values it held.

Trace · ord-9f3a1c22ms total
▶ POST /v1/processorder · 2 items
0ms├─Input · Process Orderorder{id: ord-9f3a1c, items: 2}
1ms├─Split Pipeline→ 2 branches
parallel branch · per item
2ms│ ├─FlatMap · Order Items× 2 emitted
4ms│ ├─gRPC Sink · InventoryITEM-001 reserved · ITEM-042 reserved
18ms│ └─Map · Item Result2× CONFIRMED
timeout branch · not reached
1ms│ ├─Delay · Soft Deadline25ms — deadline not fired
│ └─Map · Order Stateskipped
20ms└─Merge ResultsCONFIRMED · 2/2 items · → response
Same graph, live data

The trace runs through the exact nodes you designed. No separate trace UI to learn.

Branches shown as branches

Parallel fanout, timeout paths, error streams — all visible as separate branches in the trace, matching graph structure exactly.

🔍
Values at every node

See the actual data — inputs, outputs, errors — at each node for any request. No log parsing required.

Zero config

Tracing, spans, and node-level metrics are generated automatically. You write business logic; traces appear.

Everything You Usually Build By Hand

Most frameworks generate almost nothing. Service Architect generates an entire operational service — ready to deploy on day one.

HTTP endpoints
gRPC endpoints
Service clients
Configuration
Serialization
Runtime wiring
Prometheus metrics
OpenTelemetry tracing
Grafana dashboards
API documentation
Integration tests
Stream wiring
Project structure — generated from one graph definition
example/
├── graph/example.yaml
├── docker-compose.yml
├── go.work
├── Makefile
├── orderservice/
│ ├── cmd/service/main.go
│ ├── config/config.yaml
│ ├── grafana/dashboards/ (11 dashboards)
│ ├── internal/app/http_service.generated.go
│ ├── internal/app/service.generated.go
│ ├── internal/app/service.go ← you implement
│ ├── internal/config/config.generated.go
│ ├── internal/config/config.go ← you customize
│ ├── internal/functions/softdeadline.go ← you implement
│ ├── internal/functions/maptoorderstate.go ← you implement
│ ├── internal/functions/processorderitems.go ← you implement
│ ├── internal/serdes/
│ ├── internal/types/
│ ├── Dockerfile
│ └── Makefile
├── inventoryservice/
│ ├── internal/app/grpc_service.generated.go
│ ├── internal/functions/getinventoryitemdata.go ← you implement
│ └── ... (same structure)
└── inventory_service_api/
├── proto/inventoryserviceapi/inventoryserviceapi.proto
└── pkg/generated/proto/ (generated Go from proto)
■ generated■ you implement

From Graph To Running Service

The order pipeline example. Graph defined, code generated, service running — with full traces included automatically.

Order Service Pipeline
HTTP Input · Process Order
Split Pipeline
FlatMap · Order Items
gRPC Sink · Inventory
Map · Item Result
Delay · Soft Deadline
Map · Order State
Merge Results → Response
Live Request
curl -X POST /v1/processorder \
  -d '{
    "items": [
      { "sku": "ITEM-001", "qty": 2 },
      { "sku": "ITEM-042", "qty": 1 }
    ]
  }'
Response
{
  "order_id": "ord-9f3a1c",
  "status": "CONFIRMED",
  "confirmed_items": [
    { "sku": "ITEM-001", "reserved": true },
    { "sku": "ITEM-042", "reserved": true }
  ],
  "trace_id": "d1e2f3a4-bc5d-6789",
  "latency_ms": 22
}
💡trace_id gives you full execution visibility across both services — included automatically in every response.

A New Way to Build Backend Systems

Traditional DevelopmentService Architect
Architecture docs drift from realityGraph is the source of truth
Manual service wiringGenerated automatically
Observability added later — or neverBuilt in from day one
AI generates entire uncontrolled appsAI implements focused functions
Debugging means reading logsExecution graph + full traces
Hidden runtime behaviorVisual execution at every level

Not a Workflow Engine

The first question backend developers ask: "How is this different from Temporal, Dapr, or Camunda?" Short answer: those are workflow engines — they coordinate long-running processes with a central server. Service Architect is different in kind, not just degree.

AspectTemporal / Dapr / CamundaService Architect
Primary use caseLong-running workflows, sagas, compensationRequest processing pipelines, service orchestration, parallel fanout, event processing
Central serverRequired (Temporal/Cadence cluster)None — standard Go binary, no sidecar
ObservabilitySeparate UI, separate tracesArchitecture graph IS the trace — same diagram
Code ownershipFramework controls execution modelYou own all generated code, no framework lock-in
Architecture sourceLives in code and workflow definitionsGraph is the single source of truth

Use Temporal when you need sagas, compensation, or durable execution across days. Use Service Architect when you need stream processing pipelines, parallel request fanout, and a system where architecture and observability are the same graph.

Open Core. Production Focused.

No vendor lock-in. No black box. The generated code is standard Go — it belongs to you.

📖

Source Available

Read, audit, and contribute to the framework.

🏠

Code Belongs to You

Generated code is yours. No runtime dependency on us.

🔓

No Vendor Lock-in

Standard Go projects you can build and run anywhere.

📡

Standard OpenTelemetry

Works with any compatible tracing and metrics backend.

Lightweight Runtime

A small runtime library coordinates the graph execution. Generated code is standard Go — you own it, build it, deploy it anywhere.

The Future Of Backend Development

Architecture becomes executable.

🔭

Observability becomes the primary interface.

🤖

AI focuses on business logic.

🧑‍💻

Developers focus on system design.

Stop Wiring Services.
Start Designing Systems.

Build distributed applications as executable graphs. Observe every execution. Let AI implement the details.