Applying Reactive Asynchronous Non‑Blocking Architecture to a Video Object Creation Service with Dubbo and RxJava

For backend developers the common goal is to achieve sufficient performance with minimal resources; the article starts by stating that asynchronous and concurrent programming are essential tools for Java developers to meet this goal.

The existing PUGC video‑object‑creation interface, dating back to 2013, suffered from long, tangled business logic, uncontrolled concurrency, missing exception handling and heavy code duplication, making it hard to maintain and scale.

By analysing the service, the authors split the workflow into five stages: data validation, object creation, correlated data creation, CDN dispatch, and completion. Each stage requires coordination of multiple upstream services.

Because the workflow is IO‑bound, has many sequential steps and extensive parallelism, the team chose a reactive, asynchronous, non‑blocking architecture. Core components include RxJava (ReactiveX), Vert.x WebClient, CacheCloud reactive client, and a Dubbo reactive client.

To adapt the synchronous Dubbo RPC (version 2.6.5) to reactive streams, they first show the traditional synchronous injection using @Reference , then the asynchronous version with @Reference(async = true) returning a Future<VideoInfo> . The goal is to keep the familiar annotation‑based injection while enabling reactive usage.

A ReactiveReference<Service> interface is introduced with two methods: @NotNull Maybe<T> maybe(@NotNull Function<Service, T> f); @NotNull Single<Optional<T>> single(@NotNull Function<Service, T> f);

The implementation RxJavaReactiveReferenceImpl wraps a Dubbo call into a Maybe or Single . A DubboSubscription<T> bridges Dubbo's FutureAdapter with the Reactive Streams Subscription , handling cancellation and error propagation.

Usage is demonstrated in DubboReactiveExample where the service is injected as ReactiveReference<VideoInfoService> and two reactive methods are provided: Maybe<VideoInfo> maybeVideoInfo(long vid) { return videoInfoService.maybe(s -> s.getVideoInfo(vid)); } Single<Optional<VideoInfo>> singleVideoInfo(long vid) { return videoInfoService.single(s -> s.getVideoInfo(vid)); }

The main creation flow is expressed as a chain of RxJava Single operations: create starts with Single.fromCallable(() -> PassObj.builder().args(inputArgs).build()) and then sequentially invokes checkStage , createVideoObjectStage , createCorrelateObjectStage , and cdnDispatchStage , handling success and errors with doOnSuccess and doOnError . Each stage contains detailed implementations for validation, object persistence, and optional side‑effects such as video metadata creation and transcoding.

After the refactor the service achieved a clearer, declarative representation of the business flow, and the average response time of the video‑object‑creation API dropped from 256 ms to 146 ms, demonstrating the performance benefits of the reactive non‑blocking approach.