Type-safe multi-service orchestration for Kotlin coroutines.
Flat chains, visible phases, compiler-checked argument order.
Your code shape is the execution plan.

You have 11 microservice calls. Some can run in parallel, others depend on earlier results. With raw coroutines:

val checkout = coroutineScope {
    val dUser = async { fetchUser() }
    val dCart = async { fetchCart() }
    val dPromos = async { fetchPromos() }
    val dInventory = async { fetchInventory() }
    val user = dUser.await()
    val cart = dCart.await()
    val promos = dPromos.await()
    val inventory = dInventory.await()

    val stock = validateStock()

    val dShipping = async { calcShipping() }
    val dTax = async { calcTax() }
    val dDiscounts = async { calcDiscounts() }
    val shipping = dShipping.await()
    val tax = dTax.await()
    val discounts = dDiscounts.await()

    val payment = reservePayment()

    val dConfirmation = async { generateConfirmation() }
    val dEmail = async { sendEmail() }

    CheckoutResult(
        user, cart, promos, inventory, stock,
        shipping, tax, discounts, payment,
        dConfirmation.await(), dEmail.await()
    )
}

• Invisible phases. Where are the parallel groups? Where are the barriers? You can't tell without reading every line.
• Silent bugs. Move one await() above its async — silently serialized. The compiler says nothing.
• Boilerplate. 30+ lines of shuttle variables, no structure. Each new phase doubles the async/await ceremony.

val checkout: CheckoutResult = Async {
    kap(::CheckoutResult)
        .with { fetchUser() }              // ┐
        .with { fetchCart() }               // ├─ phase 1: parallel
        .with { fetchPromos() }             // │
        .with { fetchInventory() }          // ┘
        .then { validateStock() }     // ── phase 2: barrier
        .with { calcShipping() }            // ┐
        .with { calcTax() }                 // ├─ phase 3: parallel
        .with { calcDiscounts() }           // ┘
        .then { reservePayment() }    // ── phase 4: barrier
        .with { generateConfirmation() }    // ┐ phase 5: parallel
        .with { sendEmail() }              // ┘
}

11 service calls. 5 phases. One flat chain. Swap any two .with lines and the compiler rejects it. Each service returns a distinct type — the typed function chain locks parameter order at compile time.

130ms total (vs 460ms sequential) — verified in ConcurrencyProofTest.kt.

t=0ms   ─── fetchUser ────────┐
t=0ms   ─── fetchCart ────────┤
t=0ms   ─── fetchPromos ─────├─ phase 1 (parallel)
t=0ms   ─── fetchInventory ──┘
t=50ms  ─── validateStock ───── phase 2 (barrier)
t=60ms  ─── calcShipping ────┐
t=60ms  ─── calcTax ─────────├─ phase 3 (parallel)
t=60ms  ─── calcDiscounts ───┘
t=80ms  ─── reservePayment ──── phase 4 (barrier)
t=90ms  ─── generateConfirm ─┐
t=90ms  ─── sendEmail ───────┘─ phase 5 (parallel)
t=130ms ─── done

No intermediate variables. The constructor receives all arguments at once — no shuttle vals, no manual threading.

All code examples on this page are compilable and verified in readme-examples.

// build.gradle.kts
dependencies {
    implementation("io.github.damian-rafael-lattenero:kap-core:2.3.0")
}

<dependency>
    <groupId>io.github.damian-rafael-lattenero</groupId>
    <artifactId>kap-core-jvm</artifactId>
    <version>2.3.0</version>
</dependency>

import kap.*

data class Dashboard(val user: String, val cart: String, val promos: String)

suspend fun main() {
    val result = Async {
        kap(::Dashboard)
            .with { fetchDashUser() }    // ┐ all three in parallel
            .with { fetchDashCart() }     // │ total time = max(individual)
            .with { fetchDashPromos() }   // ┘ not sum
    }
    println(result) // Dashboard(user=Alice, cart=3 items, promos=SAVE20)
}

Try it: ./gradlew :examples:ecommerce-checkout:run

That's the whole model. Here's all three in a BFF endpoint — the classic pattern where phase 2 depends on phase 1's results:

val userId = "user-42"

val dashboard: FinalDashboard = Async {
    kap(::UserContext)
        .with { fetchProfile(userId) }       // ┐
        .with { fetchPreferences(userId) }   // ├─ phase 1: parallel
        .with { fetchLoyaltyTier(userId) }   // ┘
        .andThen { ctx ->                     // ── barrier: phase 2 NEEDS ctx
            kap(::EnrichedContent)
                .with { fetchRecommendations(ctx.profile) }  // ┐
                .with { fetchPromotions(ctx.tier) }          // ├─ phase 2: parallel
                .with { fetchTrending(ctx.prefs) }           // │
                .with { fetchHistory(ctx.profile) }          // ┘
                .andThen { enriched ->                        // ── barrier
                    kap(::FinalDashboard)
                        .with { renderLayout(ctx, enriched) }     // ┐ phase 3
                        .with { trackAnalytics(ctx, enriched) }   // ┘
                }
        }
}

t=0ms   ─── fetchProfile ──────┐
t=0ms   ─── fetchPreferences ──├─ phase 1 (parallel, all 3)
t=0ms   ─── fetchLoyaltyTier ──┘
t=50ms  ─── andThen { ctx -> }  ── barrier, ctx available
t=50ms  ─── fetchRecommendations ──┐
t=50ms  ─── fetchPromotions ───────├─ phase 2 (parallel, all 4)
t=50ms  ─── fetchTrending ─────────┤
t=50ms  ─── fetchHistory ──────────┘
t=90ms  ─── andThen { enriched -> } ── barrier
t=90ms  ─── renderLayout ──┐
t=90ms  ─── trackAnalytics ┘─ phase 3 (parallel)
t=115ms ─── FinalDashboard ready

The dependency graph IS the code shape.

Bold = unique to KAP or significantly better.

val dashboard = Async {
    kap { user: Result<String>, cart: String, config: String ->
        PartialDashboard(user.getOrDefault("anonymous"), cart, config)
    }
        .with(Kap { fetchUserMayFail() }.settled())
        .with { fetchCartAlways() }
        .with { fetchConfigAlways() }
}
// fetchUser fails? Dashboard still builds with "anonymous".
// fetchCart fails? Everything cancels (it's not settled).

val results: List<Result<String>> = Async {
    ids.traverseSettled { id -> Kap { fetchUser(id) } }
}

val result = Async {
    Kap { fetchFromPrimary() }
        .timeoutRace(100.milliseconds, Kap { fetchFromFallback() })
}
// Fallback starts at t=0. If primary wins before 100ms, use it.
// If primary times out, fallback is ALREADY RUNNING.

val quorum: List<String> = Async {
    raceQuorum(
        required = 2,
        Kap { fetchReplicaA() },
        Kap { fetchReplicaB() },
        Kap { fetchReplicaC() },
    )
}
// Returns the 2 fastest. Third cancelled. If 2+ fail, throws.

Async {
    kap(::DashboardPage)
        .with { fetchProfile(userId) }       // returns UserProfile     — slot 1
        .with { fetchPreferences(userId) }   // returns UserPreferences — slot 2
        // Swap these two? COMPILE ERROR — expected LoyaltyTier, got UserPreferences
}

val fetchOnce = Kap { expensiveCall() }.memoizeOnSuccess()

val a = Async { fetchOnce }  // runs the actual fetch
val b = Async { fetchOnce }  // cached, instant
// First call FAILS? Not cached. Next call retries.

val fastest = Async {
    raceN(
        Kap { fetchFromRegionUS() },   // 100ms
        Kap { fetchFromRegionEU() },   // 30ms
        Kap { fetchFromRegionAP() },   // 60ms
    )
}
// Returns EU at 30ms. US and AP cancelled.

val policy = Schedule.times<Throwable>(5) and
    Schedule.exponential(10.milliseconds) and
    Schedule.doWhile<Throwable> { it is RuntimeException }

val result = Async {
    Kap { flakyService() }.retry(policy)
}

val breaker = CircuitBreaker(maxFailures = 5, resetTimeout = 30.seconds)

val result = Async {
    Kap { fetchUser() }
        .timeout(500.milliseconds)
        .withCircuitBreaker(breaker)
        .retry(Schedule.times<Throwable>(3) and Schedule.exponential(10.milliseconds))
        .recover { "cached-user" }
}
// timeout -> circuit breaker -> retry -> recover. All composable.

val result = Async {
    kap { db: String, cache: String, api: String -> "$db|$cache|$api" }
        .with(bracket(
            acquire = { openDb() },
            use = { conn -> Kap { conn.query("SELECT 1") } },
            release = { conn -> conn.close() },
        ))
        .with(bracket(
            acquire = { openCache() },
            use = { conn -> Kap { conn.get("key") } },
            release = { conn -> conn.close() },
        ))
        .with(bracket(
            acquire = { openHttp() },
            use = { client -> Kap { client.get("/api") } },
            release = { client -> client.close() },
        ))
}
// All 3 in parallel. Any fails -> ALL released (NonCancellable context).

val results = Async {
    userIds.traverse(concurrency = 10) { id ->
        Kap { fetchUser(id) }
    }
}

val result: Either<NonEmptyList<RegError>, User> = Async {
    zipV(
        { validateName("Alice") },
        { validateEmail("alice@example.com") },
        { validateAge(25) },
        { checkUsername("alice") },
    ) { name, email, age, username -> User(name, email, age, username) }
}
// All pass? -> Either.Right(User(...))
// 3 fail?  -> Either.Left(NonEmptyList(NameTooShort, InvalidEmail, AgeTooLow))

Three modules, pick what you need:

┌──────────────────────────────┐   ┌──────────────────────────────┐
│          kap-arrow           │   │       kap-resilience         │
│  zipV · withV · validated {} │   │  Schedule · CircuitBreaker   │
│  attempt() · raceEither      │   │  Resource · bracket          │
│  Either/Nel · accumulate {}  │   │  raceQuorum · timeoutRace    │
│  + Arrow Core (JVM only)     │   │  retry(schedule) · retryOrElse│
└──────────────┬───────────────┘   └──────────────┬───────────────┘
               │                                  │
               └──────────────┬───────────────────┘
                              │
┌─────────────────────────────┴───────────────────────────────┐
│                        kap-core                             │
│  Kap · with · then · andThen · kap · combine  │
│  race · traverse · memoize · timeout · recover · retry(n)   │
│  settled · catching · Deferred/Flow bridges                 │
│    depends on: kotlinx-coroutines-core (JVM, JS, Native)    │
└─────────────────────────────────────────────────────────────┘

Adoption path: Start with kap-core. It covers orchestration, race, traverse, memoize, settled, and basic retry — with zero dependencies beyond coroutines. Add kap-resilience when you need composable Schedule policies, CircuitBreaker, or Resource management. Add kap-arrow only if you're already using Arrow and want validated error accumulation.

dependencies {
    implementation("io.github.damian-rafael-lattenero:kap-core:2.3.0")

    // Optional
    implementation("io.github.damian-rafael-lattenero:kap-resilience:2.3.0")
    implementation("io.github.damian-rafael-lattenero:kap-arrow:2.3.0")
}

Cancellation safety. CancellationException is never caught by any KAP combinator. recover, retry, catching, attempt — all re-throw it. bracket/guarantee release in NonCancellable context. When any .with branch fails, all siblings cancel via standard coroutineScope behavior.

Context propagation. Async(context) propagates CoroutineContext into all parallel branches — MDC, OpenTelemetry, tracing:

val result = Async(MDCContext()) {
    kap(::Dashboard)
        .with { fetchUser() }      // MDC propagated
        .with { fetchCart() }      // MDC propagated
        .with { fetchPromos() }    // MDC propagated
}

Observability. Bring your own logger — no framework coupled:

val tracer = KapTracer { event ->
    when (event) {
        is TraceEvent.Started -> logger.info("${event.name} started")
        is TraceEvent.Succeeded -> metrics.timer(event.name).record(event.duration)
        is TraceEvent.Failed -> logger.error("${event.name} failed", event.error)
    }
}

val result = Async {
    kap(::Dashboard)
        .with { fetchUser().traced("user", tracer) }
        .with { fetchConfig().traced("config", tracer) }
}

Composition guarantees. Kap satisfies functor, applicative, and monad laws — property-based tested via Kotest. Refactoring with these combinators is provably safe. See LAWS.md.

KAP shines when:

• You have 4+ concurrent operations with sequential phases (BFF, checkout, booking)
• You need parallel error accumulation across validators (add kap-arrow)
• The dependency graph should be visible in code shape
• You want compile-time parameter order safety
• You need composable retry/timeout/race policies (add kap-resilience)
• You want all of the above without pulling Arrow into your entire project

Use something else when:

• 2-3 simple parallel calls — coroutineScope { async {} } is enough
• Purely sequential code — regular suspend functions
• Stream processing — use Flow
• Full FP ecosystem (optics, typeclasses) — use Arrow directly

Target audience: BFF layers, checkout/booking flows, dashboard aggregation, multi-service orchestration.

Seven runnable examples in /examples:

All claims backed by 119 JMH benchmarks and deterministic virtual-time proofs. No flaky timing assertions — runTest + currentTime gives provably correct results.

Environment: JDK 21, Ubuntu 24.04. JMH 1.37. Live dashboard.

KAP overhead is indistinguishable from raw coroutines. It pulls ahead on race (auto-cancel loser), timeoutRace (parallel fallback), and validation arity.

./gradlew :kap-core:jvmTest          # core tests (438 tests) — start here
./gradlew :kap-resilience:jvmTest    # resilience tests (164 tests)
./gradlew :kap-arrow:test            # arrow integration tests (223 tests)
./gradlew jvmTest                    # all tests at once

./gradlew :examples:ecommerce-checkout:run   # run examples
./gradlew :benchmarks:jmh                    # JMH benchmarks

Push / PR to master
├── validate          Gradle wrapper validation
├── test              4 parallel jobs: kap-core · kap-resilience · kap-arrow · benchmarks
├── compile-platforms JS + LinuxX64 compilation checks
├── codegen-check     Regenerate all codegen, fail if out-of-date
├── examples          Run all 7 examples + Ktor integration tests
├── benchmark         (push only) Full JMH -> store results in gh-pages
├── benchmark-pr      (PR only) Quick JMH -> compare against baseline
└── ci-gate           Aggregate status for branch protection

Release (tag vX.Y.Z)
├── test              Full test suite + multiplatform compilation + codegen check
├── publish           Maven Central (macOS runner for Apple targets)
└── verify            Wait for Maven Central sync -> run examples against real artifacts

Apache 2.0