lounge.

A map of your application
that runs.

Lounge is a declarative runtime. You compose an application by describing it — the flow of data through named steps — and the engine runs real events through that description.

Use your coding assistant to draft the steps. Inspect the tree, run the checks, and keep routing, data and failures visible as the app grows.

a larger application structure A shipment flow composed from named steps. EVENT IN SEQUENTIAL ROUTING root REPLY BRANCH TO FIRST MATCH main-flow TASK normalize-event VALIDATOR validate-customer TASK enrich-order PERSISTENCE persist-order PARALLEL FAN-OUT notify customer · warehouse · … QUERY IN THE FLOW find-pending-shipments SEQUENTIAL ROUTING return-flow normalize · validate · … ON FAILURE on-exception log · alert support
§1 · WHAT IT IS

§1Composition you can read

In many backends, the application flow is distributed across controllers, services, queues and integration code. Lounge makes that flow explicit: the flow is the artifact you write, expressed as a tree of named and typed routing and task nodes that refer to application functions.

Declarative composition

You describe what happens and in what order, not how to wire it up. Steps are declared, not constructed; the engine builds the running graph from the description and refuses ambiguity before anything starts.

A generated data-flow map

The diagram is generated from the executable description. A change to the running topology therefore changes the diagram at the same time, preserving a node-by-node view of the deployed flow.

Your code stays yours

Each task node points at an ordinary function in the application's own style. Lounge composes those functions and manages the routing between them without requiring framework types in their signatures.

§2 · THE MAP

§2The project description file

Start with the same small tree generated by the installer: one typed request, one response, and an explicit error handler. The larger shipment diagram above shows how this structure can grow. Run the first-app walkthrough

project.yaml — the runnable starter
include: []
appTree:
  name: HelloLoungePipeline
  version: 0.1.0
  root:
    type: SequentialRoutingNode
    id: root
    description: Minimal starter pipeline
    children:
      - type: SequentialRoutingNode
        id: main-flow
        description: Main processing pipeline
        children:
          - type: TaskNode
            id: echo
            description: Echo the incoming ping
            procFnRef: app::echo
            inputType: raw.Ping
            outputType: domain.Pong
      - type: ExceptionHandlerTaskNode
        id: handle-errors
        description: Catch and sanitize pipeline errors
        config:
          logLevel: MESSAGE_WITH_STACK
          stackTraceDepth: 10
        outputType: tech.lounge.core.ExceptionHandlerTaskNode$SanitizedException

Reading the map

Nesting defines the flow. A sequential node runs its children in order; a branch node picks the first matching lane; a parallel node fans out. The shape on the page is the shape at runtime.

Types are contracts. Each step declares what it accepts and what it produces, so a mismatch is caught when the description is loaded — not in production.

Queries live in the flow. A query step reads records committed earlier — including earlier in the same flow — with no external store and no object-relational plumbing in between.

The diagram is generated. The developer console renders the map from the description and updates it when the description changes.

§3 · THE ENGINE

§3What one description gives you

The parts every event-driven system needs are derived from the same tree you already wrote, instead of assembled from separate infrastructure.

Ordering, by entity

Every event belongs to a group — your order, your customer, your device. Work for one group happens in strict order, while thousands of groups make progress at the same time. The group key provides the ordering boundary that a partitioned queue would otherwise supply.

State and queries, in place

Records committed by earlier steps are queryable by later ones, through a query language designed for flows rather than tables. The same query plan can search committed records or remain subscribed to newly committed ones.

The response follows the flow

A value that leaves the map becomes the response. HTTP and the internal transport use the same contract, so reply routing follows the declared flow without a separate response-routing layer.

Concurrency without application threading

Built on modern virtual-threaded Java for high concurrency on ordinary hardware. Optional parallelism is declared in the description rather than implemented in business logic. Benchmarks ship with the source so you can measure on your own machines.

Durability and recovery

Durability, recovery and failover are engine features: a committed log restores a restarted instance, and handover completes only after the replacement proves that it recovered the state recorded by its predecessor.

§4 · EDITIONS

§4Editions and production licences

All editions use the same artifact and description language. The same project file runs as core, pro, or cluster; editions differ in available capabilities, not vocabulary or results.

Every pro capability is free for development and evaluation, with no time limit. You may build, test, benchmark, demonstrate and stage without a licence, a trial key, or registration. Payment begins with production: a licence is due within 30 days of your first production deployment.

CORE

single-node production

$499
ONE-TIME · PER INSTANCE · INTRODUCTORY
  • Unlimited concurrent sessions, single node
  • Strict per-entity ordering
  • Full query language + indexing
  • Operations surfaces, auth, strict validation
  • Parallel processing within a session
  • Durability — restart is a cold start
For state that is external or rebuildable.

PRO

single-node parallelism and durability

$1,199
ONE-TIME · PER INSTANCE · INTRODUCTORY
  • Overlapped processing within a busy session
  • Concurrent fan-outs with declarative failure handling
  • Committed log — restart warm, replay, record & re-run
  • Multidimensional indexing for spatial and range queries
  • Runs the Lounge applications, starting with LoungeBuzz (licensed separately)
  • Everything in CORE
For durable state and busy event groups on one node.

CLUSTER

multi-node deployment and independent subtree sizing

$2,499
ONE-TIME · PER NODE · INTRODUCTORY
  • Multi-node execution — affinity routing and a native transport
  • Independent subtree sizing — a subtree that waits on the network needs concurrency, not cores; give it its own replicas
  • Instance handover with custody of in-flight work
  • Everything in PRO
For applications whose event groups and subtrees can be distributed.

A licence is perpetual and per instance. The version you buy is yours to run forever, with 12 months of updates included. The installed version does not expire or require a licence-server connection, and it continues to run after the update window ends.

These are introductory prices. They will rise, but only for purchases made afterwards; a licence bought today stays at today's price forever. Download and pricing →

§5 · RECOVERY

§5Two kinds of recovery

Whether a process restarts or a whole instance is replaced, the engine follows a declared recovery procedure. Drills for both cases ship with the source.

RESTARTING FROM COMMITTED STATE

PRO · SINGLE NODE

Committed records and completed sessions are appended to a verified log. When it grows past its threshold, live state is written forward as a fresh generation and older segments are sealed, so recovery stays bounded by the amount of live state rather than by total uptime. Choose how strictly each completion is flushed to storage — up to no completed session ever lost.

REPLACING AN INSTANCE

CLUSTER · MULTI-NODE

A departing instance settles, seals, and writes a manifest describing its log contents. The router retains its in-flight work while a replacement replays the same log and proves it reached the same state. Traffic moves only after that proof matches. Before the ownership change, the handover can be aborted and the original instance returned to service.

§6 · EXPLORE

§6Where to go next

Build a first app, explore the runtime, or talk to us on a Lounge-powered relay.