DEV Community: Sergiy Yevtushenko

We Should Write Java Code Differently: Frictionless Prod

Sergiy Yevtushenko — Thu, 02 Apr 2026 21:51:07 +0000

We Should Write Java Code Differently: Frictionless Prod

It's not a secret that modern production deployment is extremely complex. Following "best practices" and deploying in Kubernetes "for scalability" makes things even more complex. But how complex exactly? Let's look at the numbers.

The Setup

A mid-sized e-commerce platform. Nothing exotic -- catalog, cart, checkout, orders, payments, shipping, inventory, pricing, promotions, notifications. Standard bounded contexts, standard domain decomposition.

In a microservices architecture, this translates to roughly 30 services. Not because someone wanted 30 -- because the domain naturally decomposes into ~10 core services, ~10 supporting services (integrations, async processing, admin), and ~10 platform services (gateway, auth, search, analytics, event processing).

30 is not a large number. It is a realistic baseline for a system that does what mid-sized e-commerce systems do.

What 30 Services Actually Cost

Each service needs to be built, deployed, configured, monitored, and kept alive -- independently. On managed Kubernetes, the standard deployment substrate for this scale, here is what the numbers look like.

Production environment:

12-18 shared platform components (ingress controller, cert manager, external DNS, metrics stack, logging pipeline, tracing collector, secrets integration, policy controller, autoscaler, GitOps controller, backup controller, image registry integration)
220-280 Kubernetes workload objects (deployments, services, config maps, secrets, service accounts, network policies, autoscalers, pod disruption budgets, ingress rules, worker/consumer deployments)
260-340 configuration sets (image tags, rollout strategies, replica counts, CPU/memory limits, probes, environment variables, feature flags, secret references, IAM permissions, network exposure rules, alerting configs -- per service)

Staging environment:

Topologically similar to production. You save on capacity, not on configuration complexity. 190-250 workload objects. 220-300 configuration sets.

Testing environment:

80-160 workload objects in a shared cluster with ephemeral namespaces. 100-180 configuration sets.

Across all three environments: 500-700 managed runtime objects and 580-820 configuration surfaces.

This is before counting databases, message brokers, CDN, object storage, and external SaaS integrations. The application itself -- the business logic that actually generates revenue -- is a small fraction of this surface.

The Team That Manages This

This infrastructure does not manage itself. For a 30-service system on managed Kubernetes:

Minimum viable: 3-5 platform/DevOps engineers
Typical realistic: 5-8 engineers
Comfortable/mature: 8-12 engineers

This is platform and SRE combined -- not including the feature development teams that write the actual business logic. These engineers manage pipelines, rollout policies, cluster security, network configuration, secrets, observability, capacity planning, incident response, and the endless stream of version upgrades across 30 independent deployment units.

The dominant complexity is not code. It is coordination: version coexistence (new service talking to old service), schema evolution (new code on old database), deployment ordering (which service goes first), and failure propagation (one bad deploy cascading through dependent services).

A mid-sized organization pays for 5-8 engineers whose entire job is keeping the deployment machinery running. Not building features. Not serving customers. Managing the gap between code and production.

Where This Complexity Comes From

This is not accidental. The complexity has three structural sources, each one a consequence of architectural decisions made so long ago that they feel like laws of nature. They are not.

The Monolith Turned Inside Out

A microservices system is a monolith turned inside out. Every internal interaction -- a method call, a shared data structure, a module boundary -- transforms into infrastructure configuration. What was a function call within a single process becomes a network call that needs discovery, routing, serialization, timeout handling, retry logic, and circuit breaking. What was an internal module boundary becomes a deployment boundary with its own pipeline, versioning, and rollout policy.

The problem is not microservices as a concept. The problem is that there are no predefined patterns or limits on how services interact. The infrastructure must be infinitely flexible to accommodate every possible communication topology. Infinite flexibility means every single interaction path must be configured -- sometimes multiple times in different places. A call from the order service to the inventory service touches ingress rules, network policies, service discovery, load balancing, timeout configuration, and retry policy. Each one configured separately. Each one a potential source of misconfiguration.

A 30-service system with 50-100 service-to-service interactions does not have 30 configuration problems. It has a combinatorial configuration problem that grows with the interaction graph, not with the service count.

This creates an inherent contradiction. The ideal service boundary is determined by the business domain -- by cohesion, coupling, and team ownership. But the configuration and operational cost of each additional service is so high that it becomes a technical factor in the decomposition decision. Teams merge services that should be separate to avoid operational overhead, or keep services together that should be split because nobody wants to set up another pipeline. The result is almost inevitably a suboptimal split -- service boundaries driven by infrastructure cost rather than domain structure.

And there is a human cost too. Every service boundary is a communication boundary. Two services owned by two teams means coordination meetings, API contracts, versioning negotiations, shared testing environments, deployment ordering discussions. Conway's Law works in reverse here -- the architecture forces organizational communication patterns that would not exist if the split were different. The more services, the more cross-team coordination. The more coordination, the slower the delivery. The very thing microservices promised to fix -- team independence -- is undermined by the infrastructure overhead of maintaining the boundaries between them.

The Substrate-Application Disconnect

Kubernetes runs containers. It starts a binary, monitors a health endpoint, restarts it if it fails. That is the extent of the relationship. Once the binary is running, it is on its own.

This creates a two-way blindness. The application cannot trust the environment -- it must assume that any network call can fail, any service can be unavailable, any response can be delayed. So the application implements its own retries, its own circuit breakers, its own service discovery, its own health reporting. All of this requires configuration.

The blindness goes the other direction too. The substrate knows nothing about the application. It does not know which services talk to each other, what constitutes a meaningful health check for this specific business logic, which services must be deployed before others, or whether a particular service's "healthy" status actually means it can process requests. The cluster is fault-tolerant at the container level, but the application gets no benefit from that -- it must build its own fault tolerance on top.

The result: the application carries infrastructure concerns that the runtime should handle, and the runtime cannot provide services that would require understanding the application. Both sides are doing extra work because neither side can see the other.

There is a particularly painful consequence of this disconnect: the application and its infrastructure share a lifecycle. Every microservice bundles its own web server, serialization library, HTTP client, connection pool, metrics agent, and retry framework. When any of these components needs a security patch -- a CVE in Netty, a vulnerability in Jackson, an update in the connection pool -- the business logic must be rebuilt, retested, repackaged, and redeployed. All 30 services. Zero changes to business logic. Pure infrastructure maintenance.

This is not a deployment -- it is a tax. A Netty CVE means 30 rebuilds, 30 pipeline runs, 30 test suites, 30 rollouts. Each one risks introducing regressions in business logic that nobody touched. The operational burden scales with the service count, and the trigger has nothing to do with the business. The application and the runtime are monolithically coupled inside every single service, even as the services themselves are distributed.

The Tool Multiplication Effect

Because the substrate and application are disconnected, the gap between them must be filled. Each gap spawns a tool:

Routing and mTLS between services? Service mesh.
TLS certificate lifecycle? Certificate manager.
Configuration across environments? Config service.
Database schema evolution? Migration tool.
Connection management? Connection pooler.
Metrics and tracing? Observability agents.
Deployment orchestration? GitOps controller.
Secret management? Vault or cloud secrets integration.

Each tool has its own configuration language, its own upgrade cycle, its own failure modes, and its own operational surface. Each tool solves a real problem -- but the problem only exists because the substrate and application cannot communicate.

A 30-service system on managed Kubernetes typically depends on 9-12 distinct operational tools beyond Kubernetes itself. Each one was added to solve a legitimate gap. Together, they are the gap. The complexity is not in any single tool -- it is in the interaction between all of them. A certificate renewal that breaks a service mesh sidecar that causes a health check failure that triggers a cascading restart -- this class of incident exists only because the tools operate independently, each with partial knowledge, none with the full picture.

What If the Gap Didn't Exist?

The three sources of complexity share a root cause: the application and the runtime are strangers. The runtime starts a binary and watches a health endpoint. The binary assumes a hostile environment and brings its own infrastructure. The gap between them fills with tools. The tools fill with configuration. The configuration fills with inconsistencies. The inconsistencies fill incident postmortems.

What changes if the runtime understands the application?

Unification: From Multiplication to Addition

In a Kubernetes-based system, configuration complexity is multiplicative. Each service multiplied by each environment multiplied by each configuration surface produces the 580-820 number we saw earlier. Every new service adds a full column of config. Every new environment multiplies the entire matrix.

This multiplication exists because nothing is shared. Each service configures its own database connection, its own TLS, its own retries, its own health checks, its own metrics, its own log format. Even when two services use the same database, they each carry their own connection configuration -- independently managed, independently misconfigured.

A unified runtime changes the math. When the runtime handles TLS, there is one TLS configuration -- not 30. When the runtime handles database connections, there is one database configuration per database -- not one per service. When the runtime handles metrics, there is one observability configuration -- not 30 agents with 30 scrape configs.

The dependency structure changes from a product of factors to a sum of components. 30 slices sharing 3 databases, 1 TLS configuration, and 1 observability setup produce roughly 35 configuration surfaces -- not 340. The complexity scales with the number of distinct resources, not with the number of services that use them.

Integration: The Cluster Becomes Service-Aware

When the application is embedded into the runtime -- not just started by it -- the two-way blindness disappears.

The runtime knows what slices exist, what resources they need, which slices communicate with each other, and what "healthy" means for each one. It knows because the application declared it: this slice needs a database, that slice publishes to a stream, this slice depends on that one. The declarations are not configuration files scattered across repositories. They are part of the application itself -- compiled in, type-checked, deployed as a single artifact.

From the application's perspective, the environment becomes trustworthy. Retries, circuit breaking, load balancing, service discovery -- these are not application concerns anymore. The runtime handles them because the runtime knows the topology. When slice A calls slice B, the runtime knows where B lives, which instances are healthy, how to route the request, and what to do if it fails. The application code is a method call. Everything between the call and the response is the runtime's responsibility.

This is not a framework providing libraries. It is a managed runtime providing services -- the way an operating system provides networking and storage to applications. The application does not implement TCP. It calls an API. The same principle, applied one level up.

The Communication Fabric

The deepest integration point is inter-slice communication. In a microservices system, service-to-service calls cross process boundaries, network boundaries, and trust boundaries. Each crossing adds latency, failure modes, and configuration.

When slices run inside the runtime, the communication fabric is built in. A call from one slice to another is a typed method invocation. The runtime resolves the target, handles serialization, routes the request -- potentially to the same node (microsecond latency, zero network overhead) or to a remote node (transparent, with automatic retry and failover). The slice developer writes inventory.check(items) and gets back a Promise<Availability>. The infrastructure between the call and the response is invisible.

This is not RPC dressed up as a method call. The type system guarantees that the caller and callee agree on the contract at compile time. There are no surprise serialization failures, no version mismatches discovered in production, no "the other service changed its API and nobody told us." The contract is a Java interface. The compiler enforces it.

The same fabric carries pub/sub, streaming, and scheduled task execution. All inter-slice communication -- synchronous, asynchronous, event-driven -- flows through the same runtime-managed infrastructure. One communication model, one set of guarantees, one thing to understand.

Resource Provisioning: Declare, Don't Configure

In the traditional model, the application includes its dependencies and configures them. A service that needs a database brings a connection pool library, configures the URL, credentials, pool size, timeouts, and retry behavior. A service that needs messaging brings a client library, configures the broker address, topics, serialization, and consumer groups. Each dependency is another library, another config surface, another thing to upgrade.

In a unified runtime, the application declares what it needs. A slice annotated with @Sql gets a database connection -- provisioned, pooled, health-checked, and monitored by the runtime. A slice that declares a stream gets a stream -- partitioned, replicated, persistent. The slice does not know or care how the database connection is managed. It declares intent. The runtime delivers.

This is why 30 slices do not produce 30× configuration. The resources are shared by design. Three slices using the same database share one connection pool. Ten slices publishing to the same stream share one stream configuration. The configuration count tracks resources, not consumers.

Different Tradeoffs: Splitup Without Penalty

When the operational cost of each additional slice is zero -- no pipeline, no deployment descriptor, no config set, no monitoring surface -- the decomposition decision changes fundamentally.

In a microservices system, splitting a service in two is an infrastructure project: new repository, new pipeline, new deployment config, new monitoring, new network policies, new on-call surface. This cost discourages splitting, leading to oversized services that bundle unrelated logic because nobody wants to pay the operational tax of separation.

When slices are the unit, splitting is a code decision. Extract an interface, annotate it with @Slice, implement the business logic. The runtime handles deployment, routing, scaling, and monitoring automatically. There is no operational penalty for having 50 slices instead of 10. The only consideration is the domain: does this logic belong together, or should it be independent?

This aligns perfectly with vertical slicing. Each slice is a complete vertical: an interface (the contract), an implementation (the logic), and resource declarations (what it needs). No horizontal layers spread across packages. No shared mutable state between slices. Each slice is independently deployable, independently scalable, and independently understandable.

The scaling is linear -- in development, not just in production. Adding a new slice to the system does not require understanding the deployment topology, the network configuration, or the CI/CD pipeline. It requires understanding the business domain. Write the interface. Implement the logic. Deploy.

JBCT: Structure That Carries Across Boundaries

This is where the code methodology meets the runtime. JBCT's six structural patterns -- Sequencer, Fork-Join, Condition, Iteration, Aspects, Leaf -- are not just coding rules. They are the structural language of business processes. A Sequencer is a sequence of dependent steps. A Fork-Join is parallel independent operations. A Condition is a routing decision. These map directly to BPMN constructs -- the same notation business analysts use to describe processes.

When every slice follows the same six patterns, several things happen at once:

The code becomes the specification. A business analyst who understands the process can review the code structure and verify that it matches the intended workflow. Not because the code is simple -- because the structure is familiar. The patterns are the same shapes they draw on whiteboards.

AI-assisted development becomes predictable. The six patterns constrain the generation space. An AI that produces JBCT code generates variations of known structures, not arbitrary architectures. The mechanical rules mean less manual correction, less review overhead, less accumulated drift.

Developer onboarding compresses. A developer who learns the six patterns can read and contribute to any slice in the system. There is no per-service learning curve, no "this team does it differently." The patterns are the same everywhere.

The entire stack speaks the same language. The business process is described in BPMN. The code implements it in JBCT patterns that mirror the BPMN structure. The runtime deploys and operates it without configuration. From business requirement to production, the structure is consistent. No translation layers. No impedance mismatches. No "we need a meeting to explain what the code does."

Independent Lifecycles

Remember the Netty CVE problem -- 30 rebuilds, 30 pipelines, 30 rollouts, zero business logic changes?

When the application and the runtime are separate layers, their lifecycles decouple completely. The runtime handles web serving, TLS, connection pooling, serialization, metrics, retry logic. The application handles business logic. When Netty needs a patch, the runtime updates -- once, across all nodes, without touching a single slice. When business logic changes, the slice deploys -- without rebuilding the runtime.

Update the runtime: roll out new nodes, slices continue serving. Update a slice: deploy a new version, the runtime handles routing. Update the database driver: runtime concern, not application concern. Update Java itself: runtime update, slices are unaffected.

Two independent update cadences. Two independent test surfaces. Two independent rollout schedules. The security patch that used to trigger 30 rebuilds is now a single runtime update that applications never see.

Aether: What This Looks Like in Practice

Everything described above is not a thought experiment. It is a working system called Aether.

Here is what the 30-slice e-commerce application looks like in practice.

The Application

A slice is a Java interface:

@Slice
public interface OrderService {
    Promise<OrderResult> placeOrder(PlaceOrderRequest request);

    static OrderService orderService(InventoryService inventory,
                                     PricingService pricing) {
        return request -> inventory.check(request.items())
                                   .flatMap(pricing::calculate)
                                   .map(OrderResult::placed);
    }
}

That is the entire service. The interface is the contract. The factory method parameters are the dependencies. The implementation is the business logic. There is no framework, no annotations for routing or serialization or retry, no configuration file. The runtime handles all of it.

The Deployment

The blueprint is a TOML file that describes the desired state:

id = "org.example:commerce:1.0.0"

[[slices]]
artifact = "org.example:order-service:1.0.0"
instances = 3

[[slices]]
artifact = "org.example:inventory-service:1.0.0"
instances = 5

# ... remaining slices

The Maven plugin packages the blueprint automatically -- along with database schema migration scripts and application configuration -- into a single deployable JAR. The entire build-to-production workflow:

# Build and install to local Maven repository
mvn install

# Push artifacts from local Maven repo to production cluster
aether artifact push org.example:commerce:1.0.0

# Deploy
aether deploy org.example:commerce:1.0.0

Three commands. The runtime resolves artifacts, runs schema migrations, distributes slice instances across nodes, registers routes, and starts serving traffic. No Docker images, no Helm charts, no deployment descriptors, no pipeline configuration.

The Cluster

[deployment]
type = "aws"
region = "eu-west-1"

[deployment.instances]
core = "m5.large"

[cluster]
name = "production"
core.count = 5

[cluster.auto_heal]
enabled = true

aether cluster bootstrap --config cluster.toml

Five nodes. Auto-healing. TLS derived from a shared secret -- no external certificate authority, no cert-manager. Service discovery via consensus -- no Consul, no etcd. Metrics and tracing built in -- no Prometheus scrape configs, no observability agents. QUIC transport with mandatory TLS 1.3 between all nodes.

Scaling

aether cluster scale --core 7

Two additional nodes join the cluster automatically -- same binary, same config. Worker nodes can scale independently via gossip protocol, adding capacity without touching the consensus layer. A 5-node cluster grows to 50 nodes without architecture changes. The runtime includes a reactive scaling controller that adjusts capacity based on CPU, latency, queue depth, and error rate.

Local Development

# Build your slices
mvn install

# Start a 5-node cluster on your laptop with your application deployed
aether-forge --blueprint org.example:commerce:1.0.0

A full cluster on your laptop. Real consensus, real routing, real failure scenarios. Web dashboard with live metrics. Kill a node, watch recovery. Deploy a new slice version, watch traffic shift. The same runtime that runs in production runs on your machine -- not a simulation, not a mock, the actual system. When it works in Forge, it works in production.

The Numbers

For the same 30-slice e-commerce application:

Configuration sets (production): 260-340 on Kubernetes. ~15 on Aether.
Configuration sets (all environments): 580-820 on Kubernetes. ~18 on Aether.
Platform components: 12-18 per environment on Kubernetes. 1 binary on Aether.
Deployment: 30 independent pipelines on Kubernetes. 3 commands on Aether.
Runtime security patch: 30 rebuilds on Kubernetes. 1 rolling update on Aether.
Operational team: 5-8 dedicated engineers on Kubernetes. 1 person on Aether.

One person does not mean zero operational work. Monitoring the cluster, watching for bottlenecks, checking alerts, reviewing scaling behavior, planning capacity -- that is enough work for one person. But it is one person, not eight. And that person spends time on operational judgment, not on managing the configuration machinery that connects 12 tools to 30 services across 3 environments.

Running Java should be as easy as writing it.

With Aether, it is.

pragmaticalabs.io

Previously: Introduction to Pragmatic Functional Java (2019) | We Should Write Java Code Differently (2021) | We Should Write Java Code Differently: Let's Get Practical (2026)

We Should Write Java Code Differently: Let's Get Practical

Sergiy Yevtushenko — Sun, 22 Mar 2026 21:54:48 +0000

We Should Write Java Code Differently: Let's Get Practical

A few years ago I wrote about why we should write Java code differently. The core argument: most of what slows us down is not the amount of code — it's the amount of context we lose while writing it. Nullable variables, business exceptions, framework magic — each one eats information that should have been explicit.

That article diagnosed the problem. This one delivers the tools.

Three types — Option, Result, and Promise — cover virtually every return value in a Java backend. They compose with the same map/flatMap vocabulary you already know from Streams. Once you internalize them, the code you write becomes shorter, safer, and — this is the part that surprised me — significantly easier to read months later.

Option: A Value That Might Not Be There

If you've used Streams, you already understand the core mechanic — transform the value inside, chain transformations, extract at the end. Option applies the same thinking to absent values.

findUser(id).flatMap(user -> findAddress(user.addressId())
            .map(address -> new Profile(user, address)));

If any step returns Option.none(), the whole chain short-circuits. No null checks, no early returns, no branching. The absent-value case propagates automatically.

Where does Option come from? At adapter boundaries — wrapping nullable external APIs:

Option<String> name = Option.option(request.getParameter("name"));

Inside business logic, Option is the container for everything genuinely optional. The type makes the absence visible in the signature, not hidden in a javadoc comment.

A few things that make Option practical:

// Pattern matching with sealed types
switch (option) {
    case Option.Some(var value) -> process(value);
    case Option.None() -> handleAbsence();
}

// Convert to Result when absence is an error
option.toResult(NOT_FOUND);

// Combine multiple Options — all must be present
Option.all(firstName, lastName, email)
      .map(Contact::new);

The conversion methods matter. Option is not an island — it flows into Result and Promise when the context demands it.

Result: Errors Without Exceptions

This is where things change fundamentally.

Consider typical Java error handling:

public User registerUser(RegistrationRequest request) {
    if (request.email() == null || request.email().isBlank()) {
        throw new ValidationException("Email is required");
    }
    if (userRepository.existsByEmail(request.email())) {
        throw new DuplicateEmailException(request.email());
    }
    try {
        String hash = passwordHasher.hash(request.password());
        return userRepository.save(new User(request.email(), hash));
    } catch (HashingException e) {
        throw new RegistrationFailedException("Password hashing failed", e);
    }
}

The method signature says it returns User. It lies. It can throw three different exceptions, and the compiler won't tell you about any of them. The caller has no idea what to catch. The next developer reading this code has to trace every path to understand what can go wrong.

With Result:

public Result<User> registerUser(RegistrationRequest request) {
    return Email.email(request.email())
                .flatMap(this::ensureUnique)
                .flatMap(email -> hashAndCreateUser(email, request.password()))
                .flatMap(userRepository::save);
}

private Result<Email> ensureUnique(Email email) {
    return userRepository.existsByEmail(email)
           ? EMAIL_ALREADY_EXISTS.result()
           : Result.success(email);
}

private Result<User> hashAndCreateUser(Email email, String password) {
    return passwordHasher.hash(password)
                         .map(hash -> new User(email, hash));
}

The return type tells the truth — this operation can fail. Every failure path is visible in the chain. No exceptions thrown, no exceptions caught. The compiler enforces that the caller handles the Result.

How Errors Work

Errors are values, not exceptions. They implement the Cause interface:

public sealed interface RegistrationError extends Cause {
    enum General implements RegistrationError {
        EMAIL_ALREADY_EXISTS("Email already registered"),
        TOKEN_GENERATION_FAILED("Token generation failed");

        private final String message;

        General(String message) { 
            this.message = message; 
        }
        @Override 
        public String message() { 
            return message; 
        }
    }
}

Fixed messages become enum constants. Dynamic messages become records. All are sealed — the compiler knows every possible failure. Pattern matching works:

switch (result) {
    case Result.Success(var user) -> sendWelcome(user);
    case Result.Failure(var cause) -> logAndRespond(cause);
}

Composition

The real power shows in composition. Result.all() collects independent validations:

record ValidRegistration(Email email, Password password, PhoneNumber phoneNumber) {
    public static Result<ValidRegistration> validRegistration(Registration raw) {
        return Result.all(Email.email(raw.email()),
                          Password.password(raw.password()), 
                          PhoneNumber.phoneNumber(raw.phone()))
                     .map(ValidRegistration::new);
    }    
}

All three validations run. All failures are collected — not just the first one. The map only executes if all three succeed. One line replaces the usual cascade of if-checks-and-early-returns.

Interfacing with Legacy Code

The world throws exceptions. lift() catches them at the boundary:

Result.lift(DatabaseError::new, () -> legacyDao.findById(id));

Exception goes in, Result comes out. The boundary is explicit. Business logic stays clean.

Promise: Result, But Async

Promise is Result where the answer hasn't arrived yet. Same map, same flatMap, same mental model — just non-blocking:

public Promise<EnrichedUser> loadEnriched(UserId userId) {
    return findUser(id).flatMap(this::loadUserWithOrders);
}

private Promise<EnrichedUser> loadUserWithOrders(User user) {
    return findOrders(user.id()).map(orders -> new EnrichedUser(user, orders));
}

If findUser fails, the chain short-circuits — just like Result. If loadUserWithOrders fails, same thing. Errors are Cause values, same as in Result. The only difference: the chain executes asynchronously.

Parallel Operations

Independent operations run in parallel with Promise.all():

record Dashboard(Profile profile, List<Order> orders, List<Notification> notifications) {}

public Promise<Dashboard> loadUserDashboard(UserId userId) {
    return Promise.all(fetchProfile(userId), 
                       fetchOrders(userId), 
                       fetchNotifications(userId))
                  .map(Dashboard::new);
}

Three async calls, all independent, all in parallel. Result combined when all complete. If any fails, the whole thing fails — with a meaningful Cause.

For "first success wins" semantics:

Promise<Value> fetch(Key key) {
    return Promise.any(fetchFromPrimaryCache(key), 
                       fetchFromReplicaCache(key), 
                       fetchFromDatabase(key));
}

Side Effects

Promise distinguishes between dependent and independent actions:

findUser(id).flatMap(this::validateAccess)       // dependent — runs in sequence
            .flatMap(this::loadProfile)          // dependent — runs after validation
            .onSuccess(metrics::recordAccess)    // independent — runs async, doesn't block chain
            .onFailure(logger::warn);            // independent — runs async on failure

Dependent actions (map, flatMap) execute in order and can fail the chain. Independent actions (onSuccess, onFailure) run asynchronously and never affect the chain's outcome. This distinction eliminates an entire class of bugs where logging or metrics accidentally break the business flow.
There are also dependent side effects, for the cases when ordering matters:

findUser(id).flatMap(this::validateAccess)       // dependent — runs in sequence
            .flatMap(this::loadProfile)          // dependent — runs after validation
            .withSuccess(metrics::recordAccess)  // dependent — runs on success, in order like map/flatMap
            .withFailure(logger::warn);          // dependent — runs on failure, in order like map/flatMap

Timeouts and Recovery

fetchFromRemoteService(request).timeout(timeSpan(5).seconds())
                               .recover(cause -> cachedFallback(request));

If the remote call doesn't resolve in 5 seconds, it fails. recover converts the failure back to success using a fallback. Clean, composable, no try-catch.

The Three Types Together

The real picture emerges when all three work together. Consider a realistic operation — processing an incoming order:

public Promise<OrderConfirmation> processOrder(RawOrderRequest raw) {
    return ValidOrder.validOrder(raw)              // Result<ValidOrder> — sync validation
                     .async()                      // → Promise<ValidOrder>
                     .flatMap(this::enrichOrder)
                     .flatMap(orderRepository::save)
                     .onSuccess(eventBus::publishOrderCreated);
}

private Promise<EnrichedOrder> enrichOrder(ValidOrder order) {
    return Promise.all(inventoryService.check(order.items()),
                       pricingService.calculate(order.items()),
                       customerService.find(order.customerId()))
                  .map((availability, pricing, customer) ->
                           new EnrichedOrder(order, availability, pricing, customer));
}

What happens here:

Validation — ValidOrder.validOrder() returns Result<ValidOrder>. Parse, don't validate. If the input is malformed, a Cause explains why. No exception.
Sync to async — .async() lifts the Result into a Promise. From here, everything is non-blocking.
Parallel fetch — enrichOrder calls three independent services simultaneously. All must succeed.
Enrichment — results combined into EnrichedOrder. The map only runs if all three calls succeed.
Persistence — saved to repository. Returns Promise<OrderConfirmation>.
Side effect — event published asynchronously. Does not affect the response.

No try-catch. No null checks. No if (result == null) return error. Every failure path handled by the type system. Every step clearly visible.

The Decision Tree

Choosing the right type is mechanical:

Can this operation fail?
├── NO: Can the value be absent?
│   ├── NO → return T
│   └── YES → return Option<T>
└── YES: Is it async/IO?
    ├── NO → return Result<T>
    └── YES → return Promise<T>

Four return kinds. No judgment calls. The decision tree covers every method in a Java backend.

One allowed combination: Result<Option<T>> — when the value is genuinely optional but validation can still fail. Example: an optional referral code that, if provided, must match a specific format.

One forbidden combination: Promise<Result<T>> — double error channel. Promise already carries failure semantics. Nesting Result inside it means two places to check for errors.

What Changes In Practice

After a few weeks of writing code this way, something shifts. You stop thinking about error handling as a separate concern. It's not something you add after the happy path — it's embedded in the types. The compiler catches what used to be runtime surprises.

Code reviews get faster. When every method returns one of four types, the shape of the code becomes predictable. You don't need to trace exception paths through five layers. The return type tells you everything.

Testing simplifies. Each step in a chain is independently testable. Failures are values you can assert on — not exceptions you have to catch. Mock a dependency to return EMAIL_ALREADY_EXISTS.result() and verify the chain handles it correctly.

And the types compose. A Result from validation flows into a Promise for async processing, which fans out into parallel Promise.all(), which combines back into a single response. Each piece connects to the next with flatMap. The vocabulary is always the same.

Naming That Scales

Types solve the "what can happen" question. But there's another source of friction — naming. Every code review has that moment: "should this be fetchUser or loadUser or getUser?" The debate is real, and it wastes time because there's no shared vocabulary.

Zone-based naming eliminates this. The idea, adapted from Derrick Brandt's systematic approach to clean code: verbs belong to abstraction levels. Use the wrong verb at the wrong level, and the name signals something misleading.

Zone 2 — orchestration steps. These coordinate other operations. They don't touch databases or parse bytes. They organize.

Verb	When to use
`validate`	Checking rules and constraints
`process`	Transforming or interpreting data
`load`	Retrieving data for use
`save`	Persisting changes
`resolve`	Determining ambiguous cases
`build`	Assembling complex objects
`notify`	Informing others of events

Zone 3 — leaf operations. These do the actual work. One responsibility, specific and concrete.

Verb	When to use
`fetch`	Pull from external source
`parse`	Break down structured input
`format`	Build structured output
`calculate`	Perform computation
`hash`	Cryptographic transformation
`send`	Transmit over network
`extract`	Pull piece from larger structure

The pattern:

// Zone 2 — step interface, orchestration verb
interface LoadUserProfile {
    Promise<UserProfile> apply(UserId id);
}

// Zone 3 — leaf, implementation verb
private Promise<User> fetchFromDatabase(UserId id) { ... }
private Option<CachedUser> extractFromCache(UserId id) { ... }

If you see fetch on a step interface — something's wrong. If you see process on a leaf — same thing. The verb tells you the abstraction level before you read the parameters.

This matters for the same reason the four return types matter: it makes code predictable. A developer scanning an unfamiliar codebase can tell from the name alone whether they're looking at orchestration or implementation. No need to open the method body.

Getting Started

If your codebase currently uses exceptions for business errors and null for absent values, you don't need to rewrite everything. Start at the boundaries:

Pick one new feature. Write it with Result returns instead of exceptions.
Wrap legacy calls with Result.lift() and Option.option() at the adapter boundary.
Let the types propagate. Once one method returns Result, its callers naturally follow.

The types are available in Pragmatica Core — a focused library with no transitive dependencies.

This is the foundation that JBCT (Java Backend Coding Technology) builds on. Six structural patterns, four return kinds, mechanical rules that make code deterministic and AI-friendly. But the types come first. Everything else follows from getting the types right.

Previously: Introduction to Pragmatic Functional Java (2019) | We Should Write Java Code Differently (2021)

No Framework, No Pain: Writing Aether Slices

Sergiy Yevtushenko — Thu, 19 Feb 2026 10:08:28 +0000

No Framework, No Pain: Writing Aether Slices

The previous article introduced Aether's philosophy: return Java to managed runtimes, let the runtime handle infrastructure, and let developers handle business logic. This article shows what that looks like in practice -- what you actually write, how dependencies work, how testing works, and how existing code migrates in.

Your Microservice Is Just an Interface

Here's an entire deployable service:

@Slice
public interface OrderService {
    Promise<OrderResult> placeOrder(PlaceOrderRequest request);

    static OrderService orderService(InventoryService inventory,
                                     PricingEngine pricing) {
        return request -> inventory.check(request.items())
                                   .flatMap(pricing::calculate)
                                   .map(OrderResult::placed);
    }
}

That's not a simplified example. That's the actual thing. The annotation processor sees @Slice, reads the factory method signature and generates the wiring code, the proxy for remote calls, and the deployment metadata. You write one interface. You get a service that scales, fails over, and routes transparently across a distributed cluster.

No @Autowired. No application.yml. No @Configuration class. No @Bean method. No component scan. No service locator. No dependency injection container at all.

The factory method is dependency injection. Its parameters are the declared dependencies. The compiler verifies them. The annotation processor wires them. Nothing to configure, nothing to forget, nothing to debug at 2 AM.

Notice what the factory returns: a lambda. No implementation class. The interface has one method, so the factory returns a lambda that implements it directly. Business logic as a function. For slices with multiple methods, a private record captures the dependencies and implements the interface -- still no separate Impl class, no file to maintain, and no indirection to trace.

Two Rules, Zero Boilerplate

Every slice follows two rules:

1. The factory method declares dependencies. What the slice needs from the outside world appears in one place: the factory method signature.

static OrderService orderService(InventoryService inventory,
                                 PricingEngine pricing) {
    return request -> inventory.check(request.items())
                               .flatMap(pricing::calculate)
                               .map(OrderResult::placed);
}

Read the factory; know the dependencies. No configuration file can contradict it. No runtime surprise can introduce a dependency the compiler hasn't seen.

2. Promise return types. Every method returns Promise<T>. This isn't a stylistic choice -- it's what makes transparent distribution possible. Whether the call is in-process or cross-network, the caller sees the same type.

That's it. Two rules. Everything else follows from them.

The Magic Is in the Factory Method

The annotation processor looks at each factory parameter and classifies it automatically:

What the processor sees	What it does
`@PrimaryDb SqlConnector db`	Resource -- provisions from config
`InventoryService inventory`	External slice -- generates a network proxy
`OrderValidator validator`	Local interface with factory -- calls the factory directly

You don't configure this. You don't annotate dependencies with @Inject or @Qualifier (except for infrastructure resources). You just list what you need, and the processor figures out how to provide it.

Consider what this means. A parameter annotated with @ResourceQualifier is infrastructure -- a database connection, an HTTP client, or a message queue. The processor provisions it from configuration:

@ResourceQualifier(type = SqlConnector.class, config = "database.primary")
public @interface PrimaryDb {}

@Slice
public interface OrderRepository {
    Promise<OrderResult> findOrder(FindOrderRequest request);

    static OrderRepository orderRepository(@PrimaryDb SqlConnector db) {
        return request -> db.query(request.orderId())
                            .map(OrderResult::fromRow);
    }
}

A parameter that's a @Slice interface from another package is a remote dependency. The processor generates a proxy record that delegates to the runtime's invocation fabric. Your code calls inventory.check(request) as a method call. The proxy handles serialization, routing, retry, and failover.

A parameter that's a plain interface with a static factory method is local. The processor calls the factory directly. No proxy, no network, no overhead.

All three categories coexist in one factory:

static LoanService loanService(@PrimaryDb SqlConnector db,
                               CreditBureau creditBureau,
                               RiskCalculator riskCalculator) {
    return request -> riskCalculator.assess(request)
                                    .flatMap(risk -> creditBureau.check(request.applicant()))
                                    .flatMap(credit -> persistDecision(db, request, credit));
}

Database from config. Credit bureau via network proxy. Risk calculator instantiated locally. One line declares it all. The processor handles the rest.

Errors Without Exceptions

Frameworks train you to throw exceptions. Spring converts them to HTTP status codes. Jackson serializes error responses. Exception handlers map types to messages. It works until someone throws an unexpected exception, and the generic 500 response tells the caller nothing.

Slices use sealed Cause hierarchies:

public sealed interface OrderCause extends Cause {
    OrderCause EMPTY_ORDER = new EmptyOrder("Order must have items");
    OrderCause INSUFFICIENT_STOCK = new InsufficientStock("Insufficient stock");

    static OrderCause insufficientStock(StockStatus stock) {
        return new InsufficientStock("Insufficient stock: " + stock);
    }

    record EmptyOrder(String message) implements OrderCause {}
    record InsufficientStock(String message) implements OrderCause {}
}

Every failure mode is a type. The compiler knows all of them. Pattern matching handles them exhaustively. No surprise NullPointerException masquerading as a business error. No catch (Exception e) swallowing context.

When something fails, you return a failed promise using fluent style:

return inventory.checkStock(stockRequest)
                .flatMap(this::verifyAvailability);

private Promise<StockStatus> verifyAvailability(StockStatus stock) {
    return stock.sufficient()
        ? completeOrder(stock)
        : OrderCause.insufficientStock(stock).promise();
}

The runtime propagates the Cause across the network. The caller gets a typed failure, not a string message. The error handling contract is part of the API, not an afterthought in a @ControllerAdvice.

Testing: It's Just Java

No test containers to spin up. No mock server to configure. No @SpringBootTest annotation that loads half the universe. No mocking frameworks either -- dependencies are interfaces, so you pass lambdas that return exactly what you need:

class OrderServiceTest {
    @Test
    void placeOrder_succeeds_whenInventoryAvailable() {
        InventoryService inventory = request -> Promise.success(new StockResult("RES-123", true));
        PricingEngine pricing = request -> Promise.success(new PriceResult("ORD-456", 99.99));

        var service = OrderService.orderService(inventory, pricing);

        service.placeOrder(request)
               .await()
               .onFailure(Assertions::fail)
               .onSuccess(result -> assertEquals("ORD-456", result.orderId()));
    }

    @Test
    void placeOrder_fails_whenInventoryUnavailable() {
        InventoryService inventory = request -> OrderCause.INSUFFICIENT_STOCK.promise();
        PricingEngine pricing = request -> Promise.success(new PriceResult("ORD-456", 99.99));

        var service = OrderService.orderService(inventory, pricing);

        service.placeOrder(request)
               .await()
               .onSuccess(Assertions::fail);
    }
}

Dependencies are interfaces. Pass lambdas that return success; pass lambdas that return failure. The factory method wires them in. No reflection, no classpath scanning, no context initialization. No Mockito, no when(...).thenReturn(...), no verify(...).

Test startup is instant because there's nothing to start. No container. No framework. No bean resolution. Just objects calling objects.

Slices at Any Granularity

A single Maven module can contain as many slices as make sense:

commerce/
  src/main/java/org/example/
    order/
      OrderService.java       # @Slice
    payment/
      PaymentService.java     # @Slice
    shipping/
      ShippingService.java    # @Slice

Each @Slice generates its own factory, its own API artifact, its own deployment metadata. The Maven plugin packages them separately. They deploy and scale independently. But they develop together -- shared domain types, shared build, and one repository.

A slice can be as small as a single method. There's no operational overhead for small slices -- no container to configure, no load balancer to provision, and no monitoring to set up per service. This enables granular scaling that would be operationally insane with traditional microservices: one slice serving 50 instances during peak load while another idles at minimum. With Aether, it's the default.

What's Actually Happening

Let's trace what the annotation processor generates for a simple slice with one external dependency:

@Slice
public interface OrderService {
    Promise<OrderResult> placeOrder(PlaceOrderRequest request);

    static OrderService orderService(InventoryService inventory) {
        return request -> inventory.check(request.items())
                                   .map(OrderResult::fromAvailability);
    }
}

The processor sees InventoryService is from a different package and has @Slice annotation -- external dependency. It generates:

A proxy record that implements InventoryService and delegates every method call to the runtime's SliceInvokerFacade. Your code calls inventory.check(request). The proxy serializes the request, routes it to a node hosting InventoryService, deserializes the response, and returns it as a Promise.
A factory class that accepts an Aspect and the SliceInvokerFacade, creates the proxy, and wires everything together.
Deployment metadata in META-INF/slice/ -- the slice name, its methods, its dependencies. The runtime reads this to build the dependency graph and determine deployment order.

All generated. All verified at compile time. All invisible to your business logic.

Your Existing Code Is Already Halfway There

You don't need to start from scratch. Any existing Java code becomes a slice with one line:

// Your existing Spring service
@Service
public class OrderService {
    @Autowired private InventoryRepository inventory;
    @Autowired private PricingService pricing;

    @Transactional
    public OrderResult processOrder(OrderRequest request) {
        var availability = inventory.checkAvailability(request.getItems());
        if (!availability.isAvailable()) {
            return OrderResult.outOfStock(availability.getMissingItems());
        }
        var quote = pricing.calculateQuote(request.getItems(), request.getCustomerId());
        // ... payment, order creation, notification ...
        return OrderResult.success(order);
    }
}

Wrap it:

@Slice
public interface OrderProcessor {
    Promise<OrderResult> processOrder(OrderRequest request);

    static OrderProcessor orderProcessor() {
        var legacyService = createLegacyService();
        return request -> Promise.lift(() -> legacyService.processOrder(request));
    }
}

Promise.lift() wraps the synchronous call, catches any exception, and returns a proper Promise with a typed failure instead of a stack trace.
Your legacy code runs unchanged inside. The slice deploys to the Aether runtime (initially as a one-process cluster called Ember) alongside your existing application -- same JVM, no new risk. Move to a full Aether cluster when ready. That's a configuration change, not a code change.

The Peeling Pattern

The wrapped slice works, but it's a black box. The peeling pattern opens it up incrementally -- one layer at a time, working code at every step.

Peel the outer structure. Replace the opaque lift() with a Sequencer where each step is still wrapped:

return Promise.lift(() -> legacyCheckInventory(request))
              .flatMap(inv -> Promise.lift(() -> legacyCalculatePricing(inv)))
              .flatMap(quote -> Promise.lift(() -> legacyProcessPayment(quote)))
              .flatMap(payment -> Promise.lift(() -> legacyCreateOrder(payment)));

Now the pipeline is visible. You can see the steps, test them individually, and reason about the flow.

Peel one step deeper. Take the hottest lift() and expand it:

private Promise<Availability> checkInventory(OrderRequest request) {
    return Promise.all(Promise.lift(() -> legacyCheckWarehouse(request)),
                       Promise.lift(() -> legacyCheckSupplier(request)))
                  .map(this::combineAvailability);
}

The outer call is now clean JBCT. The inner calls are still wrapped. Tests pass at every step. Stop anywhere -- mixed JBCT and legacy code works fine. The remaining lift() calls mark exactly where legacy code lives. When they're all gone, you have a clean slice. But there's no deadline. Each peeling step delivers value on its own.

The full migration walkthrough covers the complete path -- from initial wrapping through fault tolerance to clean JBCT code.

The Shift

Traditional microservice development is a negotiation with frameworks. You learn their abstractions, their lifecycle hooks, their configuration DSLs, their annotation model, their error-handling conventions, and their testing utilities. The framework becomes the center of gravity. Your business logic orbits around it.

Slices invert this. Business logic is the center. The interface defines the contract. The factory method declares dependencies. The implementation is a lambda. Everything else -- serialization, routing, scaling, failover, and configuration -- is the runtime's problem.

You don't learn a framework. You write Java interfaces and implement them. Two rules. The rest is just your domain.

No framework. No pain.

Pragmatica Aether -- distributed Java runtime
GitHub Repository -- source code
Slice Development Guide -- full reference

Pragmatica Aether: Let Java Be Java

Sergiy Yevtushenko — Fri, 13 Feb 2026 14:38:14 +0000

The Aberration

We build Java applications like Go or Rust programs. Fat JARs. Docker images. Kubernetes deployments. Everyone does it, so it looks normal.

It contradicts Java's design DNA.

Java has always been a language for managed environments. Applets ran inside browsers. Servlets ran inside application servers. EJBs ran inside containers like JBoss and WebLogic. OSGi bundles ran inside runtime containers like Eclipse Equinox. In every generation, the pattern was the same: a managed runtime hosts the application. The application handles business logic. The runtime handles infrastructure.

The fat-jar era threw that away. We stopped letting Java be Java. We started bundling web servers, serialization frameworks, service discovery clients, configuration management, health checks, metrics libraries, and logging frameworks into every application. Then we wrapped the result in a Docker container and deployed it to an orchestration platform that reimplements — poorly — the infrastructure management that Java runtimes used to provide natively.

This article introduces Pragmatica Aether: a distributed runtime that returns Java to its natural habitat. Application handles business logic. Runtime handles infrastructure. This isn't radical — it's returning to what Java was designed for.

The Problem: Infrastructure Wearing a Business Logic Mask

Think of what a typical Java microservice carries. A web server (Tomcat, Netty, Undertow). A serialization framework (Jackson, Gson). A dependency injection container (Spring, Guice). A service discovery client (Eureka, Consul). Health check endpoints. Configuration management (Spring Cloud Config, Consul KV). A metrics library (Micrometer, Dropwizard). A logging framework (Logback, Log4j2). Retry logic (Resilience4j). Circuit breakers. HTTP client configuration. The application is wearing a heavy winter coat of infrastructure, armed to the teeth to survive in a hostile environment.

Now consider the coupling this creates.

Update Java version — rebuild and test every service. Change your message broker from RabbitMQ to Kafka — modify, rebuild, and redeploy every application that touches messaging. Add a new observability tool — update dependencies in every microservice. Switch cloud providers — rewrite configuration, SDK calls, and deployment manifests across the entire fleet. Each change ripples through dozens or hundreds of services because infrastructure is entangled with business logic at the dependency level.

This is the coupling trap. Your application's pom.xml doesn't distinguish between business dependencies and infrastructure dependencies. They compile together, deploy together, and break together. A security patch in Netty requires a new build of every service that embeds a web server — which is all of them.

Framework lock-in makes this worse. It isn't a vendor problem — it's an architecture problem. Spring's dependency injection fights with Kubernetes service mesh for control over service routing and circuit breaking. The framework's configuration system overlaps with Consul KV and Kubernetes ConfigMaps. Your cloud SDK's retry logic conflicts with Resilience4j. Every layer claims authority over the same cross-cutting concerns, and the conflicts surface as subtle bugs in production — not during development.

This is an architecture problem. Architecture problems have architectural solutions.

Aether: The Core Idea

What you write: an interface annotated with @Slice, plus business logic implementation.

@Slice
public interface OrderService {
    Promise<OrderResult> placeOrder(PlaceOrderRequest request);

    static OrderService orderService(InventoryService inventory, PricingEngine pricing) {
        return request -> inventory.check(request.items())
                                   .flatMap(available -> pricing.calculate(available))
                                   .map(priced -> OrderResult.placed(priced));
    }
}

What you don't write: everything else.

No HTTP clients — inter-slice calls are direct method invocations via generated proxies. No service discovery — the runtime tracks where every slice instance lives. No retry logic — built-in retry with exponential backoff and node failover. No circuit breakers — the reliability fabric handles failure automatically. No serialization code — request/response types are serialized transparently.

A method call via imported interface is the only visible contract. The only hint that the actual call might be remote is a design requirement: slice methods should be idempotent. This isn't a limitation — it's what enables retry, scaling, and fault tolerance to work transparently. The same request, processed by any available instance, producing the same result. Most read operations are naturally idempotent. For writes, standard patterns like idempotency keys and conditional writes handle it cleanly.

Everything else is the environment's job: resource provisioning, scaling, transport, discovery, retries, circuit breakers, configuration, observability, logging, tracing, monitoring, security. None of these are application concerns and none should be handled at the business logic level.

The JBCT Leaf pattern serves two purposes here: it documents the design ("what we expect from an external implementation") and encourages exactly one interface per dependency. Different implementations may have different technical properties — performance, latency, memory consumption — but as long as they're compatible with the interface, business logic works unchanged.

You write basically pure business logic that scales from your local computer to a global multi-zone distributed deployment, transparently.

Under The Hood: What Makes It Work

Five architectural decisions make this possible.

Consensus KV Store. A single source of truth for all configuration, deployment state, and service discovery. Based on the Rabia protocol — a crash-fault-tolerant, leaderless consensus algorithm published in 2021. Any node can propose; agreement is reached through a two-round voting protocol with a fast path when super-majority agrees in round one. No external config servers. No etcd. No Consul. Configuration changes propagate through consensus and take effect cluster-wide.

Built-in Artifact Repository. DHT-based storage with configurable replication — 3 replicas with quorum reads/writes in production, full replication in development. Artifacts are chunked into 64KB pieces, distributed across nodes via consistent hashing, and integrity-verified with MD5 and SHA-1 on every resolve. No external Nexus or Artifactory needed. During development, slices resolve from your local Maven repository. In production, the cluster is self-contained.

ClassLoader Isolation. Each slice runs in its own SliceClassLoader with child-first delegation. Two slices can use different versions of the same library without conflict. Shared dependencies like Pragmatica Lite core are loaded once in a parent classloader. No dependency conflicts. No classpath hell between slices.

Declarative Deployment. Blueprints — TOML files — describe the desired state: which slices, how many instances.

id = "org.example:commerce:1.0.0"

[[slices]]
artifact = "org.example:inventory-service:1.0.0"
instances = 3

[[slices]]
artifact = "org.example:order-processor:1.0.0"
instances = 5

Apply with one command: aether blueprint apply commerce.toml. The cluster resolves artifacts, loads slices, distributes instances across nodes, registers routes, and starts serving traffic. The cluster converges to the desired state automatically.

Infrastructure Independence. Aether nodes are identical — there's only one deployment artifact to manage at the infrastructure level. Node updates and application deployments run on completely independent schedules. Update Java — roll it out across nodes without touching applications. Update the Aether runtime — same. Update business logic — deploy new slice versions without touching infrastructure. Each independently, each without downtime. This is the fundamental benefit of proper separation: when layers don't share a deployment unit, they don't share a deployment schedule.

Fault Tolerance: The 50% Rule

The system survives failure of less than half the nodes. Performance may degrade until replacements spin up, but functionality remains intact — actual redundancy, not just graceful degradation. A 5-node cluster tolerates 2 simultaneous failures. A 7-node cluster tolerates 3. The same request, processed by any available node, producing the same result. Quorum requires (N/2) + 1 nodes — as long as a majority is alive, the cluster operates normally.

Leader failover is consensus-based and near-instant. Node replacement happens automatically — the Cluster Deployment Manager detects the deficit and provisions a replacement through the NodeProvider interface. The entire recovery sequence — from failure detection through state restoration to serving traffic — completes without human intervention.

When a node fails, the recovery is automatic. Requests to slices on the failed node are immediately retried on healthy nodes. A replacement node is provisioned. It connects to peers, restores consensus state from a cluster snapshot, re-resolves artifacts from the DHT, and re-activates assigned slices. Dead nodes are automatically removed from routing tables. The new leader reconciles stale state. No human intervention required.

Rolling updates leverage this fault tolerance for zero-downtime deployments with weighted traffic routing:

aether update start org.example:order-processor 2.0.0 -n 3
aether update routing <id> -r 1:3    # 25% to v2, 75% to v1
aether update routing <id> -r 1:1    # 50/50
aether update complete <id>          # 100% to v2, drain v1

Deploy during business hours. Shift traffic gradually — 10% canary, then 25%, 50%, 75%, 100%. Monitor health metrics at each step. If health degrades — error rate exceeds thresholds, latency spikes — instant rollback with one command: aether update rollback <id>. Traffic immediately shifts back to the old version. The 3 AM pager alert becomes an audit log entry.

For Every Project: Legacy, Greenfield, And Everything Between

Legacy Migration

Your legacy Java system doesn't need a complete rewrite. It needs a path forward.

Pick a relatively independent part of your system — something hitting limits, something with clear boundaries. Extract an interface. Annotate it with @Slice. Wrap the legacy implementation:

private Promise<Report> generateReport(ReportRequest request) {
    return Promise.lift(() -> legacyReportService.generate(request));
}

One line to enter the Aether world. Promise.lift() wraps the legacy call, catches exceptions, and returns a proper Result inside a Promise. Your legacy code keeps running. Call sites don't change. You haven't added risk — the initial deployment in Ember runs in the same JVM as your existing application, which means it's no worse than what you have today. You've laid the foundation for removing risk, not adding it. Moving from Ember to a full Aether cluster is a configuration change, not a code change — and that's when the 50% rule starts to apply.

From there, it's the strangler fig pattern. Extract a hot path, deploy it as a slice, route traffic, repeat. Each extracted slice can be gradually refactored using the peeling pattern: first wrap everything in Promise.lift(), then decompose into a Sequencer with each step still wrapped, then peel individual steps into clean JBCT patterns. Tests pass at every step. The lift() calls mark exactly where legacy code remains, making progress visible and remaining work obvious.

No rewrite required. No big bang migration. One sprint to first slice in production. The migration article covers the full path in detail — from initial wrapping through gradual peeling to clean JBCT code.

Greenfield Development

For new projects, slices enable a granularity that's impossible with traditional microservices.

Each slice can be as lean as a single method — and that's the recommended approach. There are no operational or complexity tradeoffs for small slices because Aether handles all the infrastructure overhead. No container to configure, no load balancer to provision, no monitoring to set up per service. You get per-use-case scaling: one slice serving 50 instances during peak load while another idles at minimum. That kind of granularity would be operationally insane with traditional microservices — each needing its own container, load balancer, monitoring, and deployment pipeline. With Aether, it's the default.

JBCT patterns — Leaf, Sequencer, Fork-Join, Condition, Iteration, Aspects — compose naturally within slices. Each slice method is a data transformation pipeline: parse input, gather data, process, respond. The patterns provide consistent structure within slices. Slices provide consistent boundaries between them.

The Spectrum

Same slice model, different granularity. A service slice wraps an entire legacy component. A lean slice implements a single method. Both coexist in the same cluster, deployed and scaled independently.

Slice is the executable unit. It can be big or small as necessary and convenient. The architecture accommodates both monolith migration and greenfield development simultaneously. Your legacy system gains fault tolerance while new features get maximum deployment flexibility.

Scaling: Two Levels, Three Tiers of Intelligence

Two-Level Horizontal Scaling

Aether scales in two dimensions independently:

Slice scaling: Spin up more instances of a specific slice on existing nodes. Classes are already loaded — scaling takes milliseconds, not seconds.
Node scaling: Add more machines to the cluster. The node connects, restores state, and begins accepting work.

Independent controls, combined effect. Each node hosts at most one instance of a given slice, so scaling a slice beyond the current node count requires adding nodes first. Add 2 more nodes to a 3-node cluster, then scale a hot slice to 5 instances — one per node. No coordination between the two dimensions required.

Three-Tier Decision System

Tier 1 — Decision Tree (1-second intervals). Instant reactive decisions based on CPU utilization, request latency, queue depth, and error rate. CPU above 70%? Add an instance. Below 30% sustained? Remove one (if above minimum). Latency exceeding P95 threshold? Scale up. Error rate above 1% due to timeouts? Scale up. Deterministic, predictable, fast. Handles routine load changes with configurable cooldown periods — 30 seconds for scale-up, 5 minutes for scale-down — to prevent oscillation.

Tier 2 — TTM Predictor (60-second intervals). An ONNX-based machine learning model (Tiny Time Mixers) analyzing a 60-minute sliding window of metrics — CPU usage, request rate, P95 latency, active instances. Forecasts load and adjusts the Decision Tree's thresholds preemptively. If TTM predicts a load increase, it lowers the scale-up CPU threshold by 20% so the reactive tier responds earlier. The cluster scales before the spike arrives, not after. The key design principle: the cluster always survives on Tier 1 alone. TTM enhances; it doesn't replace. If TTM fails — model load error, insufficient data, inference failure — the Decision Tree continues with default thresholds. The error is logged and recorded in metrics. No scaling disruption.

Tier 3 — LLM-based (planned). Long-term capacity planning and cluster health monitoring. Seasonal pattern prediction, maintenance window planning, anomaly investigation. This tier is not yet implemented — the current system operates with Tiers 1 and 2.

Fault tolerance makes preemptible instances viable for burst scaling. If a spot instance gets reclaimed, the cluster survives — it was designed for nodes to disappear.

You don't need a PhD in distributed systems or a dedicated platform team. The scaling system manages itself.

Development Experience: From Laptop To Production

Three Environments, Zero Code Changes

Ember. Single-process runtime with multiple cluster nodes running in the same JVM. Fast startup, simple debugging. Deploy your slices alongside your existing application — slices call each other directly in-process. No network overhead. Standard debugger breakpoints work as expected. Perfect for local development and unit testing.

Forge. A 5-node cluster simulator running on your laptop. Real consensus. Real routing. Real failure scenarios. Kill nodes, crash the leader, trigger rolling restarts — and watch the cluster recover in real time through a web dashboard with D3.js topology visualization, per-node metrics (CPU, heap, leader status), and event timeline. Configurable load generation with TOML-based multi-target configuration lets you stress-test realistic scenarios — set request rates, define body templates, and run duration-limited load tests. Chaos operations include node kill, leader kill, and rolling restart. Forge validates the entire dependency graph before starting anything.

Aether. Production cluster. Same slices, same code, different scale. Your code doesn't know which environment it's running in. Whether inter-slice calls are in-process or cross-network is transparent.

Tooling

37 CLI commands cover deployment, scaling, updates, artifacts, observability, controller configuration, and alerts — in both single-command and interactive REPL modes. A web dashboard streams real-time metrics via WebSocket — no polling. 30+ REST management endpoints enable full programmatic control of everything the CLI can do. Prometheus-compatible metrics export (/metrics/prometheus) integrates with existing monitoring stacks. Metrics are push-based at 1-second intervals, with zero consensus overhead — they bypass the consensus protocol entirely. Per-method invocation tracking with P50/P95/P99 latency and configurable slow-invocation detection strategies (fixed threshold, adaptive, per-method, composite) surfaces performance issues before users notice. Dynamic aspects let you toggle LOG/METRICS/LOG_AND_METRICS modes per method at runtime via REST API, without redeployment.

Test realistic failure scenarios on your laptop. Deploy to production with a config change, not a code change.

Maturity

Aether is a working system, not a concept paper.

81 end-to-end tests run against real 5-node clusters in Podman containers, validating cluster formation, quorum establishment, slice deployment and scaling, blueprint application with topological ordering, multi-instance distribution, artifact upload and cross-node resolution with integrity verification, leader failure and recovery, node restart with state restoration, and orphaned state cleanup after leader changes.

The recovery and fault tolerance claims come from automated tests against real clusters, not marketing slides.

Let Java Be Java

Java's lineage leads here. From applets managed by browsers, through servlets managed by application servers, through EJBs managed by enterprise containers, through OSGi managed by runtime frameworks — to Aether, managed by a distributed runtime.

The fat-jar era was a detour. An understandable one — when Docker emerged, it offered a universal packaging format, and the industry standardized on it regardless of language. Java adopted the patterns of languages that were designed to produce standalone binaries. We started treating Java applications like Go programs with a heavier runtime. But it was never the destination. Java was designed for managed environments. The JVM makes it possible. The runtime manages the application. That's the lineage. Aether continues it.

Two entry points exist today. Wrap your legacy monolith behind a @Slice interface in one sprint and gain fault tolerance without rewriting anything. Or start fresh with maximum clarity — lean slices, explicit contracts, per-use-case scaling. Both paths converge on the same runtime, the same cluster, the same operational model. Both paths can coexist — legacy service slices and new lean slices running side by side.

Fault tolerance is not an afterthought — it's the foundation. Scaling is not your problem — it's the environment's. Infrastructure is not your code — it's the runtime's. The heavy winter coat comes off. The application breathes.

Pragmatica Aether — project site
GitHub Repository — source code

Let Java be Java. Let infrastructure be infrastructure. Write business logic that scales from your laptop to global deployment without changing a line of code.

Why Interface + Factory? The Java Pattern That Makes Everything Replaceable

Sergiy Yevtushenko — Sat, 07 Feb 2026 21:39:17 +0000

Why Interface + Factory? The Java Pattern That Makes Everything Replaceable

The Pattern

Every component — use case, processing step, adapter — is defined as an interface with a static factory method:

public interface ProcessOrder {
    record Request(String orderId, String paymentToken) {}
    record Response(OrderConfirmation confirmation) {}

    Result<Response> execute(Request request);

    interface ValidateInput {
        Result<ValidRequest> apply(Request raw);
    }
    interface ReserveInventory {
        Result<Reservation> apply(ValidRequest req);
    }
    interface ProcessPayment {
        Result<Payment> apply(Reservation reservation);
    }
    interface ConfirmOrder {
        Result<Response> apply(Payment payment);
    }

    static ProcessOrder processOrder(ValidateInput validate,
                                     ReserveInventory reserve,
                                     ProcessPayment processPayment,
                                     ConfirmOrder confirm) {
        return request -> validate.apply(request)
                                  .flatMap(reserve::apply)
                                  .flatMap(processPayment::apply)
                                  .flatMap(confirm::apply);
    }
}

Four steps. Each is a single-method interface. The factory method accepts all dependencies as parameters and returns a lambda implementing the use case. The body reads exactly like the business process: validate, reserve, process payment, confirm.

This isn't arbitrary convention. There are three specific reasons this structure exists.

Reason 1: Substitutability Without Magic

Anyone can implement the interface. No framework. No inheritance hierarchy. No annotations.

Testing becomes trivial:

@Test
void order_fails_when_inventory_insufficient() {
    var useCase = ProcessOrder.processOrder(
        request -> Result.success(new ValidRequest(request)),  // always valid
        req -> INSUFFICIENT_INVENTORY.result(),                // always fails
        reservation -> { throw new AssertionError("unreachable"); },
        payment -> { throw new AssertionError("unreachable"); }
    );

    useCase.execute(new Request("order-1", "tok_123"))
           .onSuccess(Assertions::fail);
}

No mocking framework. No @Mock annotations. No when().thenReturn() chains. The test constructs the exact scenario it needs with plain lambdas.

Stubbing incomplete implementations during development is equally straightforward:

// Payment gateway isn't ready yet? Stub it.
var useCase = ProcessOrder.processOrder(
    realValidator,
    realInventoryService,
    reservation -> Result.success(new Payment("stub-" + reservation.id(), Money.ZERO)),
    realConfirmation
);

The team working on inventory doesn't need to wait for the payment team. Each step is independently implementable.

Reason 2: Implementation Isolation

Each implementation is self-contained. No shared base classes. No abstract methods to override. No coupling between implementations whatsoever.

Compare with the typical abstract class approach:

// The abstract class trap
public abstract class AbstractOrderProcessor {
    protected final Logger log = LoggerFactory.getLogger(getClass());

    public final Result<Response> execute(Request request) {
        log.info("Processing order: {}", request.orderId());
        var result = doExecute(request);
        log.info("Order result: {}", result);
        return result;
    }

    protected abstract Result<Response> doExecute(Request request);
    protected abstract Result<ValidRequest> validate(Request request);

    // "Shared utility" that every subclass now depends on
    protected Result<Money> calculateTotal(List<LineItem> items) {
        // 47 lines of logic that one subclass needed once
    }
}

Now every implementation is coupled to the base class. Change calculateTotal and you need to understand every subclass. Add logging to execute and every implementation gets it whether appropriate or not. The base class becomes a gravity well — accumulating shared code that creates invisible dependencies between implementations that should have nothing in common.

With interface + factory, there is no shared implementation code. Period. Each intersection between implementations is unnecessary coupling with corresponding maintenance overhead — up to needing deep understanding of two projects instead of one, with zero benefit.

// Implementation A: uses database
static ProcessPayment databasePayment(PaymentRepository repo) {
    return reservation -> repo.charge(reservation.paymentToken(), reservation.total())
                              .map(Payment::fromRecord);
}

// Implementation B: uses external API
static ProcessPayment stripePayment(StripeClient client) {
    return reservation -> client.createCharge(reservation.total(), reservation.paymentToken())
                                .map(Payment::fromStripe);
}

These implementations don't know about each other. They don't share code. They don't share a base class. They share a contract — the interface — and nothing else.

Reason 3: Disposable Implementation

Here's the subtle one. The factory method returns a lambda or local record. It can't be referenced externally by class name.

static ProcessOrder processOrder(ValidateInput validate,
                                 ReserveInventory reserve,
                                 ProcessPayment processPayment,
                                 ConfirmOrder confirm) {
    return request -> validate.apply(request)          // this lambda IS the implementation
                              .flatMap(reserve::apply)
                              .flatMap(processPayment::apply)
                              .flatMap(confirm::apply);
}

No code anywhere says new ProcessOrderImpl(). No code depends on the implementation class. The implementation is replaceable by definition — because nothing can reference it.

The interface is the design artifact. The implementation is incidental.

This might sound academic until you need to:

Replace a synchronous implementation with an async one
Swap a database adapter for an API adapter
Add a caching layer around an existing step
Completely rewrite a step's internals

In each case, the interface stays. The factory method signature stays. The implementation — which nothing references — gets replaced. No downstream changes. No adapter layers. No "backwards compatibility."

The Compound Effect

Each reason is valuable on its own. Together, they create a system where:

Testing is configuration. You assemble the exact combination of real and stubbed components you need. No mocking framework overhead. No "mock everything" test fragility.

Refactoring is safe. Replacing an implementation can't break other implementations because they don't share code. The compiler enforces the contract through the interface.

Complexity is bounded. Understanding one implementation requires understanding only that implementation and the interfaces it consumes. Not a base class hierarchy. Not shared utilities. Not other implementations.

Incremental development is natural. Stub what's not ready. Replace stubs with real implementations one at a time. Each step can be developed, tested, and deployed independently.

When Does This Not Apply?

When there genuinely is one implementation and always will be. Pure utility functions, mathematical computations, simple data transformations — these don't need the interface + factory treatment. A static method is fine.

The pattern pays for itself when there's any possibility of multiple implementations — including the test implementation, which almost always exists.

The Shift

Most Java codebases default to classes. Interface extraction happens later, reluctantly, when testing forces it or when the second implementation appears.

Flip this. Start with the interface. Define the contract. The implementation follows naturally — and when it needs to change, nothing else does.

The interface is what you design. The implementation is what you happen to write today.

Fail-Safe Your Legacy Java in One Sprint

Sergiy Yevtushenko — Tue, 27 Jan 2026 12:24:03 +0000

Fail-Safe Your Legacy Java in One Sprint

The Scaling Wall

Your Java system works. It's been working for years. But lately, it's showing strain. Response times creep up during peak hours. That batch job that used to finish overnight now runs into morning operations. Users notice.

The conventional answer is microservices. Decompose the monolith, deploy to Kubernetes, hire a platform team. Eighteen months, significant budget, and a team with specialized skills you don't have. Meanwhile, every deployment feels like Russian roulette. One bad release, one server failure, and the business stops.

For middle-sized businesses, this isn't a technology problem. It's a survival problem. The system that runs your operations is both essential and fragile. You can't afford to replace it, and you can't afford to lose it.

The 50% Rule

What if half your servers could fail and users wouldn't notice?

Aether, the runtime behind the slice architecture, provides exactly this guarantee. When your code runs across a cluster, failure of less than half the nodes affects only performance, not functionality. Requests automatically route to surviving nodes. No manual intervention, no pager alerts at 3 AM.

This isn't eventual consistency or graceful degradation. It's actual redundancy. The same request, processed by any available node, producing the same result. Your business keeps running while you fix the failed hardware.

For a C-level executive, this translates simply: business continuity without enterprise budget. The system that runs your operations becomes the system that survives failures.

The Simplest Migration Path

Here's how to start. Pick a relatively independent part of your system. Something that's already hitting limits. Something with clear boundaries.

Step 1: Extract an interface. This is mechanical. Any Java developer can do it. The interface defines what the component does, not how.

@Slice
public interface ReportGenerator {
    Promise<Report> generateReport(ReportRequest request);
}

Step 2: Make it idempotent. The same request should produce the same result, even if processed multiple times. Pragmatica Lite provides built-in support for this pattern. For most code, it's a small change.

Step 3: Deploy Ember. Ember runs multiple cluster nodes in the same JVM as your existing application. Your legacy code calls the interface exactly as before. No changes to call sites.

That's it. Your first slice is running.

Important caveat: This initial step is not fault-tolerant. You're still running in a single JVM, which means a single point of failure. But here's the key insight: it's no worse than what you have today. You haven't added risk. You've laid the foundation for removing it.

From Foundation to Fault Tolerance

The foundation is in place. Now you can build on it.

Moving from Ember to full Aether deployment is a configuration change, not a code change. Your slices, your interfaces, your business logic—all unchanged. You're just telling the runtime to distribute across multiple machines instead of running in-process.

Now the 50% rule applies. Your report generator runs on three nodes. One dies. The other two handle the load. You fix the failed node when convenient, not when panicked.

Each step in this path delivers value:

Ember in-JVM: Foundation laid, no new risk
Ember multi-node: Development and testing environment
Aether cluster: Production fault tolerance

You control the pace. Extract another slice when ready. Expand the cluster when needed. The architecture grows with your confidence.

The Peeling Pattern

Once your slice is running, you have a choice: leave the internals as-is, or gradually refactor them. The peeling pattern lets you do the latter without risk.

Phase 1: Wrap everything. Your initial slice wraps the entire legacy method:

private Promise<Report> generateReport(ReportRequest request) {
    return Promise.lift(() -> legacyReportService.generate(request));
}

Phase 2: Peel the outer layer. Refactor into a Sequencer, but keep each step wrapped:

private Promise<Report> generateReport(ReportRequest request) {
    return validateRequest(request)
        .flatMap(valid -> Promise.lift(() -> legacyFetchData(valid)))
        .flatMap(data -> Promise.lift(() -> legacyProcess(data)))
        .flatMap(result -> Promise.lift(() -> legacyFormat(result)));
}

Phase 3: Peel deeper. Take one wrapped step and expand it:

private Promise<RawData> fetchData(ValidRequest request) {
    return Promise.all(
        Promise.lift(() -> legacyFetchFromDb(request)),
        Promise.lift(() -> legacyFetchFromApi(request))
    ).map(this::combineData);
}

Each phase keeps the code working. Tests pass at every step. You can stop anywhere—the system runs fine with mixed JBCT and wrapped legacy code. The lift() calls mark exactly where legacy code remains, making progress visible and the remaining work obvious.

What You Don't Need

Traditional modernization projects require capabilities most middle-sized businesses don't have. Aether is different.

No Kubernetes expertise. Aether manages its own clustering. You don't need to learn pod configurations, service meshes, or container orchestration.

No platform team. The runtime handles deployment, discovery, and failover. Your existing operations team can manage it.

No new infrastructure. Start with Ember in your existing JVM. Add machines only when you're ready for fault tolerance.

No retraining. Same Java. Same IDE. Same debugging. Your developers write slice interfaces exactly like they write any other interface. The patterns are familiar; only the deployment model changes.

The migration path is designed for teams that have a business to run, not a technology transformation to execute.

The Path Forward

Once the foundation is working, possibilities open up.

More slices mean more of your system becomes fault-tolerant. The relatively independent parts you migrated first are now proven. You understand the pattern. The next extraction is faster.

Aether's operational model scales beyond manual management. A three-tier control system handles increasingly complex decisions:

Decision trees handle routine scaling—deterministic, predictable, fast
TTM (predictive models) detect patterns and scale preemptively
LLM agents (planned) handle capacity planning and anomaly investigation

You're not just surviving anymore. You're building toward a system that manages itself.

Conclusion

The legacy Java system running your business doesn't need a complete rewrite. It needs a path forward that doesn't bet the company on an 18-month transformation project.

Start with one slice. Run it in Ember alongside your existing code. Prove it works. Then decide: add fault tolerance, extract another slice, or pause and let the system prove itself in production.

The 50% rule isn't a promise for someday. It's a capability you can reach in weeks, not years. Your business deserves infrastructure that survives failures. Now there's a path to get there.

Part of Java Backend Coding Technology - a methodology for writing predictable, testable backend code.

Slices: The Right Size for Microservices

Sergiy Yevtushenko — Sun, 18 Jan 2026 21:49:19 +0000

Slices: The Right Size for Microservices

The Granularity Trap

Every team that adopts microservices eventually hits the same wall: how big should a service be?

Go too small and you drown in network calls, distributed transactions, and deployment complexity. Your simple "get user profile" operation now involves five services, three of which are just proxies for database tables. Latency compounds. Debugging becomes archaeology.

Go too large and you're back to the monolith. Different teams step on each other. Deployments require coordination. The "micro" in microservices becomes ironic.

The standard advice—"one service per bounded context" or "services should be independently deployable"—sounds reasonable but provides no actionable guidance. Where does one context end and another begin? What exactly makes something "independently deployable"?

Teams oscillate between extremes, refactoring services that are "too small" into larger ones, then splitting services that grew "too large." The cycle repeats because the fundamental question remains unanswered: what determines the right boundary?

Boundaries Before Size

The problem isn't size. It's boundaries.

A well-defined boundary has specific properties:

Clear contract: callers know exactly what they can request and what they'll receive
Explicit dependencies: the component declares what it needs from outside
Internal freedom: implementation details can change without affecting callers

Size follows from boundaries, not the other way around. A component is the right size when it fully owns its boundaries—when everything needed to fulfill its contract lives inside, and everything outside is accessed through explicit dependencies.

This is where most microservice designs fail. They draw boundaries based on technical layers (API gateway, business logic, database access) or organizational structure (team ownership). Neither approach produces stable boundaries because neither focuses on the actual contracts between components.

What Is a Slice?

A slice is a deployable unit defined by its contract. You write an interface with a single annotation:

@Slice
public interface OrderService {
    Promise<OrderResponse> createOrder(CreateOrderRequest request);
    Promise<OrderResponse> getOrder(GetOrderRequest request);
    Promise<Unit> cancelOrder(CancelOrderRequest request);
}

That's it. The annotation processor generates everything else—factory methods, dependency wiring, deployment metadata. You define the contract; the tooling handles the infrastructure.

This interface is the boundary:

Methods define the contract: each takes a request, returns a promise of response
Request/response types are explicit: no hidden parameters, no ambient context
Async by default: Promise<T> handles both success and failure paths

The implementation lives behind this interface. It might be simple or complex. It might call other slices or be completely self-contained. The boundary doesn't care.

Aether and Forge: Development Made Simple

Slices run on Aether, a distributed runtime designed around slice contracts. You don't configure service discovery, serialization, or inter-slice communication—Aether handles it based on what the slice interfaces declare. Every inter-slice call eventually succeeds if the cluster is alive; the runtime manages retries, failover, and recovery transparently.

Forge provides a development environment for testing slices under realistic conditions—load generation, chaos injection, backend simulation. Instead of deploying to staging to see how your slices behave under pressure, you run Forge locally and observe.

The development experience stays simple: write @Slice interfaces, implement them, test with Forge, deploy to Aether. The annotation processor generates all the boilerplate—factories, dependency wiring, routing metadata.

Dependencies That Don't Lie

Traditional service architectures bury dependencies in configuration files, environment variables, or runtime discovery. You find out what a service needs by reading its code, tracing its network calls, or waiting for it to fail in production.

Slices declare dependencies in the interface:

@Slice
public interface OrderService {
    Promise<OrderResponse> createOrder(CreateOrderRequest request);
    // Other methods...

    // Factory method declares dependencies explicitly
    static OrderService orderService(InventoryService inventory, PaymentService payment) {
        return OrderServiceFactory.orderService(Aspect.identity(), inventory, payment);
    }
}

The annotation processor generates the factory that wires everything:

public final class OrderServiceFactory {
    private OrderServiceFactory() {}

    public static OrderService orderService(
            Aspect<OrderService> aspect,
            InventoryService inventory,
            PaymentService payment) {
        return aspect.apply(new OrderServiceImpl(inventory, payment));
    }
}

The factory method signature declares dependencies. No service locators, no runtime discovery, no configuration files that might or might not match reality. Dependencies are visible at compile time and verified before deployment.

This explicitness matters. You can trace the dependency graph by reading code. You can test with substitutes by passing different implementations. Forge validates the entire graph before starting anything.

Same Code, Different Environments

The same slices run unchanged across three runtime modes:

Ember: Single-process runtime with multiple cluster nodes. Fast startup, simple debugging. Perfect for local development.
Forge: Ember plus load generation and chaos injection. Test how slices behave under pressure without deploying anywhere.
Aether: Full distributed cluster. Production deployment with all the resilience guarantees.

Your code doesn't know which mode it's running in. Slice interfaces, implementations, and dependencies stay identical. The runtime handles the difference—whether inter-slice calls are in-process or cross-network is transparent.

This changes the development workflow. You write and debug in Ember. You stress-test in Forge. You deploy to Aether. At no point do you modify slice code to accommodate the environment.

Right-Sized by Definition

With boundaries explicit and deployment flexible, the "right size" question dissolves.

A slice is the right size when:

Its interface captures a coherent set of operations
Its dependencies accurately reflect what it needs
Its implementation can fulfill its contract

There's no minimum or maximum. An authentication slice might have two methods. An order processing slice might have twenty. Size follows from the domain, not from arbitrary rules about lines of code or team structure.

More importantly, getting it wrong is recoverable. Split a slice that grew too complex? The boundary changes, but callers just see a new interface. Merge slices that were artificially separated? Same story. Refactoring slices is refactoring code, not rewriting infrastructure.

The JBCT Connection

Slices are where JBCT patterns live.

Each slice method is a data transformation pipeline:

Parse input (validated request types)
Gather data (dependencies, other slices)
Process (business logic)
Respond (typed response)

The six patterns—Leaf, Sequencer, Fork-Join, Condition, Iteration, Aspects—compose within and across slice methods. A slice is simply the deployment boundary around a set of related transformations.

This is why the combination works. JBCT gives you consistent structure within slices. Slices give you consistent boundaries between them. Together, they eliminate the two sources of architectural entropy: inconsistent implementation patterns and unclear service boundaries.

Conclusion

The microservices granularity problem persists because it asks the wrong question. "How big should a service be?" has no good answer. "What are the contracts between components?" has a precise one.

Slices shift focus from size to boundaries. Define the interface. Declare dependencies explicitly. Let deployment topology adapt to operational needs rather than dictating code structure.

The result: boundaries that are clear by construction, dependencies that are visible by design, and deployment flexibility that doesn't require rewriting code.

Part of Java Backend Coding Technology - a methodology for writing predictable, testable backend code.

The Six Patterns That Cover Everything

Sergiy Yevtushenko — Wed, 14 Jan 2026 23:12:12 +0000

The Six Patterns That Cover Everything

The Complete Vocabulary

Every data transformation you'll ever write falls into one of six patterns:

Leaf - One thing. No substeps. Atomic.
Sequencer - This, then that. Output becomes input.
Fork-Join - These together, then combine. Independent operations merging.
Condition - Which path? Route based on value.
Iteration - Same thing, many times. Transform a collection.
Aspects - Wrap it. Add retry, timeout, logging around an operation.

That's it. Six patterns. They cover everything.

Not "cover most cases." Not "work well for common scenarios." Everything. Every piece of request processing logic you'll ever write is one of these six, or a composition of them.

Why Only Six?

These aren't design patterns someone invented. They're the fundamental ways data can flow:

Transform a value (Leaf)
Chain dependent transforms (Sequencer)
Combine independent transforms (Fork-Join)
Choose between transforms (Condition)
Apply transform to many values (Iteration)
Enhance a transform (Aspects)

There's no seventh option. Data either transforms, chains, combines, branches, iterates, or gets wrapped. That's the complete set of possibilities.

This is why learning six patterns gives you everything. Not because JBCT is comprehensive - because reality is constrained.

The Strange Coincidence

Here's what's remarkable: these same six patterns describe every business process.

Think about any workflow in your domain:

Leaf: "Validate the email format" - one check, atomic
Sequencer: "First verify identity, then check permissions, then grant access" - dependent chain
Fork-Join: "Get user profile, account balance, and recent transactions, then build the dashboard" - independent data gathering
Condition: "If premium user, apply discount; otherwise, standard pricing" - routing
Iteration: "For each item in cart, calculate tax" - collection processing
Aspects: "Log every payment attempt" - cross-cutting concern

Business processes and code patterns use the same vocabulary. This isn't coincidence. It's because both describe how information flows and transforms. Business logic IS data transformation - we just use different words for it.

The Common Language

This equivalence creates something powerful: a shared language between developers and business stakeholders.

Watch the precision gain:

Before: "Get the user's stuff and show it"

After: "Fork-Join: fetch profile, preferences, and history in parallel, then combine into dashboard view"

Same requirement. One is vague. One is implementable.

When a developer asks "Can these operations run in parallel?" they're really asking "Do these steps depend on each other's results?"

When business says "First we verify, then we process, then we notify" - that's a Sequencer. Directly translatable to code.

When business says "We need the user's profile, their preferences, and their history to show the dashboard" - that's a Fork-Join. Three independent fetches, one combined result.

The translation becomes mechanical:

"Check if..." → Leaf → Single validation
"First... then... then..." → Sequencer → .flatMap() chain
"Get X and Y and Z, then..." → Fork-Join → Promise.all()
"If... otherwise..." → Condition → Ternary/switch
"For each..." → Iteration → .map() / loop
"Always log/retry/timeout..." → Aspects → Wrapper function

No translation layer. No impedance mismatch. The same six concepts, different vocabulary.

Gap Detection

Here's where it gets interesting. When you model business processes using these patterns, gaps become visible.

Missing validation:
You're building a Sequencer: verify -> process -> notify. But what validates the input before "verify"? The pattern demands something produces the input for step one. If nothing does, you've found a gap.

Unclear dependencies:
Business describes five things that need to happen. Are they a Sequencer (dependent chain) or Fork-Join (independent operations)? If they can't tell you which outputs feed which inputs, the process isn't fully defined.

Missing error handling:
Every Leaf can fail. Every step in a Sequencer can fail. When you map business process to patterns, you naturally ask: "What happens when this fails?" If they don't know, you've found a gap.

Inefficient flows:
Business describes a sequential process: get A, then get B, then get C, then combine. But if A, B, and C don't depend on each other, this should be Fork-Join, not Sequencer. The pattern reveals the inefficiency.

The patterns don't just implement requirements - they validate them.

The Right Questions

Once you think in patterns, the right questions emerge naturally:

At the start (Leaf/Validation):

"How do we know this request is valid?"
"What makes an email/phone/amount valid in your domain?"
"What's the first thing we need to verify?"

For sequences (Sequencer):

"What do we need from step 1 to perform step 2?"
"Can step 3 ever happen if step 2 fails?"
"Is this order fixed, or could steps be reordered?"

For parallel work (Fork-Join):

"Do these operations depend on each other?"
"Can we fetch user profile while also fetching their orders?"
"What do we do if one succeeds and another fails?"

For branching (Condition):

"What determines which path we take?"
"Are these paths mutually exclusive?"
"Is there a default path?"

For collections (Iteration):

"Do we process all items or stop at first failure?"
"Does order matter?"
"Can items be processed independently (in parallel)?"

For cross-cutting concerns (Aspects):

"Should we retry on failure? How many times?"
"Is there a timeout?"
"What needs to be logged/measured?"

You're not inventing questions. The patterns generate them. Each pattern has a fixed set of things that must be defined. If they're not defined, you ask.

From Patterns to Process Design

The flow works both ways.

Forward: Business describes a process -> you identify patterns -> you implement code

Backward: You see the patterns -> you notice gaps -> you ask questions -> business clarifies -> process improves

This backward flow is underrated. Developers who think in patterns become process consultants. They don't just implement what they're told - they improve what they're told by making implicit assumptions explicit.

"You said first A, then B, then C. But B doesn't use A's output. Can B and A happen at the same time? That would be faster."

"You said validate the request. What exactly are we validating? Email format? Email exists in system? User is active? Each is a separate check."

"You said handle the error. Which error? Network timeout? Invalid data? User not found? Each might need different handling."

The patterns force precision. Vague requirements become concrete when you have to place them in one of six boxes.

The Result

When developers and business share this vocabulary:

Requirements discussions become technical design sessions
Gaps surface during conversation, not during implementation
Code structure mirrors business process (because they're the same thing)
Changes in business process map directly to code changes
New team members understand both business and code faster

Six patterns. Complete coverage. Shared language. Gap detection built in.

This is why pattern-based thinking isn't just a coding technique. It's a communication framework that makes the implicit explicit and the vague precise.

The irony? You'll spend an hour asking the right questions. The coding takes 30 seconds. Turns out the "coding technology" is mostly about not coding.

Part of Java Backend Coding Technology - a methodology for writing predictable, testable backend code.

Previous: The Underlying Process of Request Processing

The Underlying Process of Request Processing

Sergiy Yevtushenko — Mon, 12 Jan 2026 21:36:33 +0000

The Underlying Process of Request Processing

Beyond Languages and Frameworks

Every request your system handles follows the same fundamental process. It doesn't matter if you're writing Java, Rust, or Python. It doesn't matter if you're using Spring, Express, or raw sockets. The underlying process is universal because it mirrors how humans naturally solve problems.

When you receive a question, you don't answer immediately. You gather context. You retrieve relevant knowledge. You combine pieces of information. You transform raw data into meaningful understanding. Only then do you formulate a response. This is data transformation--taking input and gradually collecting necessary pieces of knowledge to provide a correct answer.

Software request processing works identically.

The Universal Pattern

Every request follows these stages:

Parse - Transform raw input into validated domain objects
Gather - Collect necessary data from various sources
Process - Apply business logic to produce results
Respond - Transform results into appropriate output format

This isn't a framework pattern. It's not a design choice. It's the fundamental nature of information processing. Whether you're handling an HTTP request, processing a message from a queue, or responding to a CLI command--the process is the same.

Input → Parse → Gather → Process → Respond → Output

Each stage transforms data. Each stage may need additional data. Each stage may fail. The entire flow is a data transformation pipeline.

Why Async Looks Like Sync

Here's the insight that changes everything: when you think in terms of data transformation, the sync/async distinction disappears.

Consider these two operations:

// "Synchronous"
Result<User> user = database.findUser(userId);

// "Asynchronous"
Promise<User> user = httpClient.fetchUser(userId);

From a data transformation perspective, these are identical:

Both take a user ID
Both produce a User (or failure)
Both are steps in a larger pipeline

The only difference is when the result becomes available. But that's an execution detail, not a structural concern. Your business logic doesn't care whether the data came from local memory or crossed an ocean. It cares about what the data is and what to do with it.

When you structure code as data transformation pipelines, this becomes obvious:

// The structure is identical regardless of sync/async
return userId.all(
    id -> findUser(id),        // Might be sync or async
    id -> loadPermissions(id), // Might be sync or async
    id -> fetchPreferences(id) // Might be sync or async
).map(this::buildContext);

The pattern doesn't change. The composition doesn't change. Only the underlying execution strategy changes--and that's handled by the types, not by you.

Parallel Execution Becomes Transparent

The same principle applies to parallelism. When operations are independent, they can run in parallel. When they depend on each other, they must run sequentially. This isn't a choice you make--it's determined by the data flow.

// Sequential: each step needs the previous result
return validateInput(request)
    .flatMap(this::createUser)
    .flatMap(this::sendWelcomeEmail);

// Parallel: steps are independent
return Promise.all(
    fetchUserProfile(userId),
    loadAccountSettings(userId),
    getRecentActivity(userId)
).map(this::buildDashboard);

You don't decide "this should be parallel" or "this should be sequential." You express the data dependencies. The execution strategy follows from the structure. If operations share no data dependencies, they're naturally parallelizable. If one needs another's output, they're naturally sequential.

This is why thinking in data transformation is so powerful. You describe what needs to happen and what data flows where. The how--sync vs async, sequential vs parallel--emerges from the structure itself.

The JBCT Patterns as Universal Primitives

Java Backend Coding Technology captures this insight in six patterns:

Leaf - Single transformation (atomic)
Sequencer - A → B → C, dependent chain (sequential)
Fork-Join - A + B + C → D, independent merge (parallel-capable)
Condition - Route based on value (branching)
Iteration - Transform collection (map/fold)
Aspects - Wrap transformation (decoration)

These aren't arbitrary design patterns. They're the fundamental ways data can flow through a system:

Transform a single value (Leaf)
Chain dependent transformations (Sequencer)
Combine independent transformations (Fork-Join)
Choose between transformations (Condition)
Apply transformation to many values (Iteration)
Enhance a transformation (Aspects)

Every request processing task--regardless of domain, language, or framework--decomposes into these six primitives. Once you internalize this, implementation becomes mechanical. You're not inventing structure; you're recognizing the inherent structure of the problem.

Optimal Implementation as Routine

When you see request processing as data transformation, optimization becomes straightforward:

Identify independent operations → They can parallelize (Fork-Join)
Identify dependent chains → They must sequence (Sequencer)
Identify decision points → They become conditions
Identify collection processing → They become iterations
Identify cross-cutting concerns → They become aspects

You're not making architectural decisions. You're reading the inherent structure of the problem and translating it directly into code.

This is why JBCT produces consistent code across developers and AI assistants. There's essentially one correct structure for any given data flow. Different people analyzing the same problem arrive at the same solution--not because they memorized patterns, but because the patterns are the natural expression of data transformation.

The Shift in Thinking

Traditional programming asks: "What sequence of instructions produces the desired effect?"

Data transformation thinking asks: "What shape does the data take at each stage, and what transformations connect them?"

The first approach leads to imperative code where control flow dominates. The second leads to declarative pipelines where data flow dominates.

When you make this shift:

Async stops being "harder" than sync
Parallel stops being "risky"
Error handling stops being an afterthought
Testing becomes straightforward (pure transformations are trivially testable)

You're no longer fighting the machine to do what you want. You're describing transformations and letting the runtime figure out the optimal execution strategy.

Conclusion

Request processing is data transformation. This isn't a paradigm or a methodology--it's the underlying reality that every paradigm and methodology is trying to express.

Languages and frameworks provide different syntax. Some make data transformation easier to express than others. But the fundamental process doesn't change. Input arrives. Data transforms through stages. Output emerges.

JBCT patterns aren't rules to memorize. They're the vocabulary for describing data transformation in Java. Once you see the underlying process clearly, using these patterns becomes as natural as describing what you see.

The result: any processing task, implemented in close to optimal form, as a matter of routine.

Part of Java Backend Coding Technology - a methodology for writing predictable, testable backend code.

From Subjective Opinions to Systematic Analysis: Pattern-Based Code Review

Sergiy Yevtushenko — Sun, 21 Dec 2025 14:38:34 +0000

From Subjective Opinions to Systematic Analysis: Pattern-Based Code Review

How structural patterns transform code review from art into engineering

The Problem with Traditional Code Review

Code review discussions often devolve into debates about style, naming preferences, and subjective "readability." Two experienced developers can look at the same function and have completely opposite opinions about whether it's "clean" or "messy."

This subjectivity creates real problems:

Review quality depends on reviewer mood and experience
Feedback is inconsistent across team members
Discussions become defensive rather than constructive
Junior developers struggle to internalize vague guidance like "make it more readable"

What if code review could be as systematic as running a test suite?

The Key Insight: Patterns Enable Decomposition

When code follows well-defined structural patterns, something remarkable happens: functions become decomposable into discrete, analyzable parts.

Consider a function that follows no particular pattern. To review it, you must:

Hold the entire function in your head
Trace all possible execution paths
Infer the author's intent from implementation details
Make subjective judgments about "complexity"

Now consider a function that implements exactly one pattern from a known catalog. Suddenly you can:

Immediately recognize the structure
Apply pattern-specific review criteria
Verify each component independently
Make objective assessments against clear standards

Patterns transform code review from holistic judgment into component analysis.

The Pattern Catalog: A Reviewer's Toolkit

Every function implements exactly one of these patterns:

1. Leaf

The atomic unit -- a function that does one thing with no internal steps.

Business Leaf: Pure computation, no I/O

public Money calculateDiscount(Money price, double discountRate) {
    return price.multiply(discountRate);
}

Adapter Leaf: I/O operation that bridges to external systems

public User findByEmail(String email) throws DatabaseException {
    try (var conn = dataSource.getConnection();
         var stmt = conn.prepareStatement(FIND_BY_EMAIL_SQL)) {
        stmt.setString(1, email);
        var rs = stmt.executeQuery();
        return rs.next() ? mapToUser(rs) : null;
    } catch (SQLException e) {
        throw new DatabaseException("Failed to find user by email", e);
    }
}

2. Sequencer

A chain of 2-5 dependent steps where each step's output feeds the next.

public OrderConfirmation processOrder(OrderRequest request) {
    ValidatedOrder validated = validateOrder(request);
    InventoryReservation reservation = reserveInventory(validated);
    PaymentResult payment = processPayment(reservation);
    return confirmOrder(payment);
}

3. Fork-Join

Parallel independent operations combined into a single result.

public Dashboard loadDashboard(Long userId) {
    CompletableFuture<UserProfile> profileFuture = 
        CompletableFuture.supplyAsync(() -> userService.getProfile(userId));
    CompletableFuture<List<Order>> ordersFuture = 
        CompletableFuture.supplyAsync(() -> orderService.getRecentOrders(userId));
    CompletableFuture<List<Notification>> notificationsFuture = 
        CompletableFuture.supplyAsync(() -> notificationService.getUnread(userId));

    CompletableFuture.allOf(profileFuture, ordersFuture, notificationsFuture).join();

    return new Dashboard(
        profileFuture.join(),
        ordersFuture.join(),
        notificationsFuture.join()
    );
}

4. Condition

Branching based on a discriminator -- if/else or switch.

public double calculateShippingRate(Order order) {
    if (order.isPremiumCustomer()) {
        return calculatePremiumRate(order);
    } else if (order.getWeight() > HEAVY_THRESHOLD) {
        return calculateHeavyItemRate(order);
    } else {
        return calculateStandardRate(order);
    }
}

5. Iteration

Collection processing via loops or streams.

public List<OrderSummary> getPendingOrderSummaries(List<Order> orders) {
    return orders.stream()
        .filter(Order::isPending)
        .map(this::toSummary)
        .collect(Collectors.toList());
}

Pattern-Based Review: The Checklist Approach

Once you recognize a function's pattern, you apply pattern-specific review criteria. This replaces vague "is it readable?" with concrete checklists.

Reviewing a Leaf

Check	Question
Single Responsibility	Does it do exactly one thing?
Purity (Business)	No side effects? Same inputs -> same output?
Error Handling (Adapter)	Are low-level exceptions wrapped in domain exceptions?
Naming	Does the name describe the transformation?
Size	Small enough to understand at a glance?

Reviewing a Sequencer

Check	Question
Step Count	2-5 steps? (More suggests extraction needed)
Dependency	Does each step genuinely depend on the previous?
Single Pattern	No hidden Fork-Join or Condition inside steps?
Abstraction Level	Are all steps at the same abstraction level?
Error Flow	Is it clear what happens when each step fails?

Reviewing a Fork-Join

Check	Question
Independence	Are branches truly independent? No shared mutable state?
Thread Safety	Are all inputs immutable or thread-safe?
Completeness	Does the combiner handle all branch results?
Error Handling	What happens if one branch fails?
Infrastructure	Any hidden dependencies (DB locks, rate limits, connection pools)?

Reviewing a Condition

Check	Question
Exhaustiveness	Are all cases covered? Is there a sensible default?
Balance	Are branches roughly equal in complexity?
Extraction	Should complex branches be extracted to named methods?
Nesting	Are conditions nested too deeply? (Max 2 levels)

Reviewing an Iteration

Check	Question
Transformation Clarity	Is the mapping operation obvious?
Filter Predicate	Is the filter condition clear or should it be a named method?
Side Effects	No side effects inside map/filter/forEach?
Null Safety	Are null elements handled?

The Meta-Review: Pattern Violations

Beyond pattern-specific checks, reviewers should watch for structural violations:

Mixed Patterns

A function that starts as a Sequencer but contains an inline Fork-Join:

// BAD: Mixed patterns -- Sequencer contains inline Fork-Join
public OrderResult processOrder(OrderRequest request) {
    ValidatedOrder validated = validateOrder(request);

    // Suddenly doing parallel work inline
    CompletableFuture<User> userFuture = 
        CompletableFuture.supplyAsync(() -> userService.getUser(validated.getUserId()));
    CompletableFuture<Product> productFuture = 
        CompletableFuture.supplyAsync(() -> productService.getProduct(validated.getProductId()));
    CompletableFuture.allOf(userFuture, productFuture).join();

    OrderContext context = new OrderContext(userFuture.join(), productFuture.join());
    return finalizeOrder(context);
}

Review feedback: "Extract the parallel fetch into a separate method like fetchOrderContext()."

// GOOD: Clean -- Sequencer with extracted Fork-Join
public OrderResult processOrder(OrderRequest request) {
    ValidatedOrder validated = validateOrder(request);
    OrderContext context = fetchOrderContext(validated);  // Fork-Join hidden here
    return finalizeOrder(context);
}

private OrderContext fetchOrderContext(ValidatedOrder validated) {
    // Fork-Join pattern in its own method
    CompletableFuture<User> userFuture = 
        CompletableFuture.supplyAsync(() -> userService.getUser(validated.getUserId()));
    CompletableFuture<Product> productFuture = 
        CompletableFuture.supplyAsync(() -> productService.getProduct(validated.getProductId()));
    CompletableFuture.allOf(userFuture, productFuture).join();

    return new OrderContext(userFuture.join(), productFuture.join());
}

Violated Abstraction Levels

Mixing high-level orchestration with low-level details:

// BAD: Mixed abstraction levels
public void processUserRegistration(RegistrationRequest request) {
    // High-level step
    User user = createUser(request);

    // Suddenly low-level details
    String welcomeHtml = "<html><body><h1>Welcome " + user.getName() + "!</h1>"
        + "<p>Your account has been created.</p>"
        + "<a href='" + baseUrl + "/verify?token=" + user.getVerificationToken() + "'>Verify</a>"
        + "</body></html>";

    emailService.send(user.getEmail(), "Welcome!", welcomeHtml);

    // Back to high-level
    auditService.logRegistration(user);
}

Review feedback: "Extract email content generation to a separate method or template."

// GOOD: Clean -- consistent abstraction level
public void processUserRegistration(RegistrationRequest request) {
    User user = createUser(request);
    sendWelcomeEmail(user);
    auditService.logRegistration(user);
}

private void sendWelcomeEmail(User user) {
    String content = emailTemplates.renderWelcome(user);
    emailService.send(user.getEmail(), "Welcome!", content);
}

Incorrect Pattern Choice

Using Sequencer when Fork-Join is appropriate (sequential operations that are actually independent):

// BAD: Sequential when parallel is possible
public ReportData gatherReportData(Long userId) {
    UserProfile profile = userService.getProfile(userId);      // 200ms
    List<Order> orders = orderService.getOrders(userId);       // 300ms  
    AccountBalance balance = accountService.getBalance(userId); // 150ms
    // Total: 650ms sequential

    return new ReportData(profile, orders, balance);
}

Review feedback: "These fetches are independent -- use parallel execution to reduce latency."

// GOOD: Parallel execution for independent operations
public ReportData gatherReportData(Long userId) {
    CompletableFuture<UserProfile> profileFuture = 
        CompletableFuture.supplyAsync(() -> userService.getProfile(userId));
    CompletableFuture<List<Order>> ordersFuture = 
        CompletableFuture.supplyAsync(() -> orderService.getOrders(userId));
    CompletableFuture<AccountBalance> balanceFuture = 
        CompletableFuture.supplyAsync(() -> accountService.getBalance(userId));

    CompletableFuture.allOf(profileFuture, ordersFuture, balanceFuture).join();
    // Total: ~300ms parallel

    return new ReportData(
        profileFuture.join(), 
        ordersFuture.join(), 
        balanceFuture.join()
    );
}

The "God Method" -- Multiple Patterns Jumbled Together

// BAD: Multiple patterns mixed together
public Invoice generateInvoice(Long orderId) {
    Order order = orderRepository.findById(orderId);  // Leaf
    if (order == null) {                              // Condition starts
        throw new OrderNotFoundException(orderId);
    }

    List<InvoiceLine> lines = new ArrayList<>();      // Iteration starts
    for (LineItem item : order.getItems()) {
        Product product = productService.getProduct(item.getProductId());  // Another Leaf
        if (product.isTaxable()) {                    // Nested Condition
            lines.add(createTaxableLine(item, product));
        } else {
            lines.add(createNonTaxableLine(item, product));
        }
    }

    double subtotal = 0;                              // Another Iteration
    for (InvoiceLine line : lines) {
        subtotal += line.getAmount();
    }

    if (order.hasDiscount()) {                        // Another Condition
        subtotal = applyDiscount(subtotal, order.getDiscount());
    }

    return new Invoice(order.getId(), lines, subtotal);
}

Review feedback: "This method mixes at least 4 patterns. Extract: fetchOrder(), buildInvoiceLines(), calculateSubtotal(), applyDiscountIfPresent()."

// GOOD: Clean -- one pattern per method, composed as Sequencer
public Invoice generateInvoice(Long orderId) {
    Order order = fetchOrder(orderId);
    List<InvoiceLine> lines = buildInvoiceLines(order);
    double subtotal = calculateSubtotal(lines);
    double finalAmount = applyDiscountIfPresent(subtotal, order);
    return new Invoice(order.getId(), lines, finalAmount);
}

private Order fetchOrder(Long orderId) { /* Leaf */ }
private List<InvoiceLine> buildInvoiceLines(Order order) { /* Iteration */ }
private double calculateSubtotal(List<InvoiceLine> lines) { /* Iteration */ }
private double applyDiscountIfPresent(double subtotal, Order order) { /* Condition */ }

Practical Review Workflow

Step 1: Pattern Recognition

Before reading implementation details, identify the pattern:

See sequential method calls with data passing between them? -> Sequencer
See CompletableFuture.allOf() or parallel streams? -> Fork-Join
See if/else or switch as the main structure? -> Condition
See loops or stream operations? -> Iteration
None of the above, just one operation? -> Leaf

Step 2: Count the Patterns

If you identify more than one pattern in a single method, that's already a finding. Flag it for extraction.

Step 3: Apply Pattern Checklist

Use the appropriate checklist. Check each criterion mechanically.

Step 4: Verify Abstraction Consistency

Read through the method body. Are all statements at the same level of abstraction? High-level orchestration shouldn't mix with low-level implementation details.

Step 5: Check Error Handling Consistency

Are exceptions handled at the right level?
Is null checking consistent?
Are edge cases covered?

Common Review Comments by Pattern

Having a vocabulary of pattern-based feedback makes reviews faster and more actionable:

Pattern	Common Issue	Review Comment
Leaf	Does too much	"This leaf has multiple responsibilities. Extract X into a separate method."
Leaf	Side effects in business logic	"This calculation method logs/saves data. Extract side effects."
Sequencer	Too many steps	"This has 8 steps. Group related steps into higher-level methods."
Sequencer	Independent steps	"Steps 2 and 3 don't depend on each other. Consider parallel execution."
Fork-Join	Shared mutable state	"These parallel branches share mutable state. Make inputs immutable."
Fork-Join	Missing error handling	"What happens if one future fails? Add error handling strategy."
Condition	Deep nesting	"3+ levels of nesting. Extract inner conditions to named methods."
Condition	Unbalanced branches	"The else branch is 50 lines. Extract to a method."
Iteration	Side effects in loop	"This forEach modifies external state. Consider using reduce or extract the mutation."
Mixed	Multiple patterns	"This method contains Sequencer + Condition + Iteration. Extract each pattern."

Benefits of Pattern-Based Review

For Reviewers

Faster reviews: Pattern recognition is instant; checklists are mechanical
Consistent feedback: Same criteria applied every time
Objective discussions: "This violates single-pattern rule" vs. "I don't like this"

For Authors

Clear expectations: Know what reviewers will check before submitting
Actionable feedback: "Extract this Fork-Join" vs. "make it cleaner"
Faster iteration: Fix specific issues, not vague concerns

For Teams

Shared vocabulary: "That's a Sequencer with a mixed-pattern violation"
Onboarding acceleration: New developers learn patterns, not tribal knowledge
Reduced conflict: Debates about style become discussions about patterns

Implementing Pattern-Based Review

Start Small

Introduce the five patterns in a team meeting
Start identifying patterns in PR descriptions: "This method is a Sequencer with 4 steps"
Use pattern vocabulary in review comments

Create Team Standards

Document your pattern catalog with examples from your codebase
Agree on step count limits (e.g., Sequencers have 2-5 steps)
Define what "same abstraction level" means for your domain

Build Into Process

Add pattern checklist to PR template
Include pattern identification in code review training
Create IDE snippets/templates for each pattern

Evolve and Refine

Collect common violations and create team-specific guidelines
Build a library of "before/after" examples from real PRs
Consider tooling: static analysis rules for obvious violations

Conclusion

Traditional code review asks: "Is this code good?" -- a question with infinite subjective answers.

Pattern-based code review asks: "Is this a valid Sequencer? Does this Fork-Join have independent branches? Is this Leaf truly atomic?" -- questions with objective, verifiable answers.

When you recognize structural patterns, review transforms from art appreciation into engineering inspection. Every function has a recognizable shape. Every shape has specific criteria. Every criterion has a clear pass/fail answer.

The result: faster reviews, better feedback, and code that improves systematically rather than accidentally.

The patterns aren't new -- you've been writing Sequencers, Fork-Joins, and Iterations your whole career. What's new is naming them, recognizing them explicitly, and using that recognition to make code review objective and systematic.

Want to dive deeper into pattern-based code structure? Check out Java Backend Coding Technology for a complete methodology built on these principles.

Java Should Stop Trying To Be Like Everybody Else

Sergiy Yevtushenko — Thu, 18 Dec 2025 23:12:26 +0000

Java Should Stop Trying To Be Like Everybody Else

The Wrong Competition

Java is losing the container wars. A typical Spring Boot microservice ships as a 70-200 MB fat JAR, stuffed into a container image that easily crosses 300 MB. Go produces a 10-15 MB static binary. Rust often beats that. The industry response has been predictable: GraalVM native images, Alpine base images, multi-stage Docker builds, endless optimization of the wrong thing.

Here's what nobody talks about: the actual business logic in that 200 MB artifact - the code your developers write - typically weighs 2 to 500 kilobytes. The rest is framework code, an embedded web server, a JSON library, logging infrastructure, and a bundled JVM. All of it duplicated across every single service in your fleet.

One team using WildFly Swarm's skinny packaging took their application from 45 megabytes down to 2,243 bytes. That's not a typo. Two kilobytes. A 20,000x reduction by removing everything that wasn't their code.

The question isn't how to make Java containers smaller. The question is: why are we packaging this way at all?

Java's Forgotten DNA

Java was never designed to produce self-contained binaries. This is not a weakness - it's a fundamental design decision that the industry has been fighting against for a decade.

The original target platform wasn't servers. It was set-top boxes and web consoles - managed environments where a runtime handled lifecycle, security, and resource allocation. This heritage shows everywhere in the language:

Dynamic class loading - classes can be loaded, unloaded, and replaced at runtime
The module system (JPMS) - explicit dependency boundaries and encapsulation
Hot-swapping - update code without restarting the process
OSGi - an entire ecosystem built around dynamic module deployment

These aren't accidents or legacy baggage. They're capabilities that most languages would kill for. And we've abandoned all of them to stuff JVMs into containers like it's 2014 and we just discovered Docker.

The current deployment model actively fights Java's strengths. We take a language optimized for dynamic, managed execution and freeze it into static artifacts. We take a runtime designed to host multiple applications efficiently and spin up one instance per service. We pay the JVM's startup cost - optimized for long-running processes - on every container spawn.

Turn the Model Inside-Out

What if we stopped packaging the JVM with every service? What if we deployed just the business logic and let the environment handle everything else?

This isn't a hypothetical. It's how Java EE worked for two decades. The application server provided HTTP handling, connection pooling, transaction management, security. Your WAR file contained your code and nothing else. We called it "heavyweight" and ran away to microservices - but we replaced one 200 MB application server with forty 200 MB fat JARs, and called it progress.

The insight isn't "go back to Java EE." It's to recognize what Java EE got right: separation of application logic from infrastructure concerns.

A modern realization of this principle:

What moves to the environment:

HTTP request handling and routing
Authentication and authorization
Logging, metrics, and tracing
Service discovery and load balancing
Connection management for databases and external APIs
Lifecycle management and health checking

What stays in the artifact:

Business logic
Domain models
That's it

Your deployment artifact becomes a thin module - kilobytes, not megabytes. The runtime environment provides everything else, configured once, updated independently, consistent across all services.

The Payoff: Instant Scaling

When your deployment unit drops from 200 MB to 200 KB, everything changes.

Sub-millisecond startup. A thin module loads in microseconds. No framework initialization, no classpath scanning, no connection pool warmup - the environment already has all that running. With some pre-warming tricks, startup becomes virtually instant.

Effortless horizontal scaling. The environment can spin up new instances as fast as it can allocate memory. Scaling from 1 to 100 instances isn't a capacity planning exercise - it's a configuration value. Scale-to-zero becomes practical because cold start doesn't exist.

Resource efficiency at fleet scale. Instead of running 40 JVMs (one per service) each consuming 200-500 MB of heap, you run a handful of environment instances that host all your modules. The shared runtime, shared libraries, and shared connection pools dramatically reduce total memory footprint.

Simplified operations. No more "works on my machine." The environment is the same everywhere - dev, staging, production. Infrastructure upgrades (JVM version, security patches, library updates) happen once, at the environment level, not per-service.

Transparent Distribution (Almost)

Here's where it gets interesting. When the environment controls service lifecycle and inter-service communication, it can provide guarantees that are impossible in conventional deployments.

Calls between modules become environment-managed. If your module instance is alive, calls to other modules succeed - the environment handles routing, retries, and failover transparently. No more debugging whether the circuit breaker configuration matches the load balancer timeout matches the container health check interval.

Location transparency. Modules don't know or care where other modules run. The environment distributes them across available resources and handles all the networking. Moving a module to a different node requires zero code changes.

Lifecycle notifications. When the environment needs to drain a node or rebalance load, it notifies affected modules. Graceful shutdown becomes a first-class concept, not something you bolt on with preStop hooks and SIGTERM handlers.

There's one constraint: externally visible entry points must be idempotent. Without this property, the environment can't safely retry operations during network hiccups or instance migration. But this isn't really a new constraint - it's already a best practice for any distributed system. You're just making it explicit.

Native CI/CD

The deployment model collapses to something surprisingly simple.

You publish. Your artifact goes to a Maven repository - local, organization-wide, or public. This is already your artifact format. No container registry, no Dockerfile, no image layers to optimize.

Environment deploys. It watches the repository (or receives a webhook), pulls the new artifact, and rolls it out according to your configured strategy - canary, blue-green, rolling, whatever you need. The deployment strategy is configuration, not pipeline code.

That's it. No docker build. No image push. No kubectl apply. No Helm chart templating. No ArgoCD sync. Just publish to Maven and watch it deploy.

The environment itself can run containerized if you need to deploy to existing Kubernetes infrastructure or cloud container services. But your applications don't know or care. They're just modules in a repository.

I've been exploring what this would look like in practice. The results are promising enough to be worth sharing - but that's a topic for another post.

The Strategic Question

Java's current trajectory is clear: keep chasing Go and Rust on their terms. Smaller native images. Faster startup through ahead-of-time compilation. More aggressive dead code elimination. Each step is a partial solution that fights the language's design.

There's another path: stop competing on binary size and cold start, and instead leverage what Java actually does well. Dynamic runtime. Hot deployment. Mature module systems. The most sophisticated JIT compiler in existence, which needs long-running processes to reach peak performance.

This isn't about nostalgia for application servers. It's about recognizing that the current model - every service is an isolated container with its own JVM - creates massive operational overhead while abandoning Java's genuine advantages.

The infrastructure to do this properly is starting to emerge. The pieces exist: Java's module system is mature, the JVM's dynamic capabilities never went away, and the operational pain of container-per-service is now obvious enough that people are looking for alternatives.

Whether this comes from a new runtime, a framework evolution, or a rethinking of how we use existing tools - the direction is clear. Java shouldn't try to be a better Go. It should be a better Java.

Pragmatica Lite

Sergiy Yevtushenko — Wed, 08 Oct 2025 16:56:30 +0000

Functional style library for Java
https://github.com/siy/pragmatica-lite

This library is a core part of Java Backend Coding Technology: https://pragmatica.dev/

This is a submission for the 2025 Hacktoberfest Writing Challenge: Maintainer Spotlight