sogou/workflow: a C++ engine for pairing network calls with compute in one task graph

What sogou/workflow is meant to replace in a C++ back end

Most C++ services end up with two scheduling systems that do not know about each other. One handles sockets, timeouts and reconnects; the other handles thread pools for CPU work. sogou/workflow puts both into a single task model. The README states it supports almost all back-end C++ online services of Sogou, including search services, the cloud input method and online advertisements, and that it handles more than 10 billion requests every day. That is a vendor's own operational figure, not a third-party benchmark, but it tells you the design target: long-running services with a complex relationship between computing and networking, which is the phrasing the README itself uses.

The audience is narrower than the tagline suggests. You need a compiler that supports C++11, and you need to be comfortable owning a native build. In exchange you get a framework that does not depend on boost or asio, and that treats a Redis command, a MySQL query, a Kafka produce and a matrix multiplication as the same kind of object. If your service is a thin HTTP wrapper around one database, this is more machinery than you need.

Tasks, series, parallel and DAG: the actual execution model

The unit of work is a task. The README groups them into networking tasks, computing tasks, timer and counter tasks, resource pools and asynchronous file IO tasks, and states that all types of tasks can be put into the same flow. Composition is explicit: series and parallel structures are supported, and any DAG structure is supported as well, with docs/en/tutorial-11-graph_task.md as the reference.

That last point is where the framework differs from a thread-pool-plus-callback design. In a DAG you declare dependencies, and a node runs when its predecessors finish, so a chain that fetches from Redis, calls an upstream HTTP service and then runs a local computation does not need a hand-written state machine. The README frames the whole thing as a programming paradigm: Program = Protocol + Algorithm + Workflow. Protocol covers the built-in HTTP, Redis, MySQL and Kafka clients plus user-defined protocols; Algorithm is your computation; Workflow is the graph that sequences them.

Two supporting pieces matter in practice. The README lists service governance and load balancing as built-in features, with docs/en/about-service-governance.md and docs/en/about-upstream.md as the documentation. Connection context is documented separately, which suggests per-connection state is a first-class concept rather than something you thread through manually. The README does not, in the text available here, describe the failover policy of the load balancer or the consistency model of the upstream registry.

Installing sogou/workflow on Debian, Ubuntu or Fedora

There are two supported paths. The README gives a source build for Linux and macOS, and distribution packages for Debian, Ubuntu 22.04 and Fedora. The source route is the one that gets you the tutorial programs.

Run the clone and the two make invocations from the README. The first builds the library, the second builds the tutorial binaries.

git clone https://github.com/sogou/workflow
cd workflow
make
cd tutorial
make

On Debian or Ubuntu the packaged route separates the development headers from the runtime library. Install libworkflow-dev when you are compiling against it, and libworkflow1 on machines that only run the resulting binary.

sudo apt-get install libworkflow-dev
sudo apt-get install libworkflow1

Fedora uses dnf with different package names for the same split.

dnf install workflow-devel
dnf install workflow

The README also points to docs/en/xmake.md for an xmake build, and to the srpc tools repository for an SRPC-based toolchain.

For a first real program, the README's own example is a complete HTTP server. It registers a lambda that appends a body to the response, starts on port 8888, and stops when you press Enter.

#include <stdio.h>
#include "workflow/WFHttpServer.h"

int main()
{
    WFHttpServer server([](WFHttpTask *task) {
        task->get_resp()->append_output_body("<html>Hello World!</html>");
    });

    if (server.start(8888) == 0) {
        getchar();
        server.stop();
    }

    return 0;
}

Compile it against the library and the header directory you just built or installed, run it, and curl port 8888. You should see the HTML string back. The tutorial directory contains the same shape of program for wget, Redis, MySQL, Kafka, parallel wget, file IO and user-defined protocols, so the fastest way to learn the API is to read those files rather than the header set.

Where the framework pushes cost onto you

The dependency story is clean until you touch Kafka. The README states the master branch requires OpenSSL 1.1 or above, that BoringSSL is fully compatible, and that a nossl branch exists if you do not want SSL at all. It then says there are no other dependencies, with one exception: the Kafka protocol needs lz4, zstd and snappy installed. So a build that is dependency-free for HTTP and Redis becomes a build with three compression libraries the moment Kafka enters the picture.

The Windows situation is a real constraint rather than a footnote. The README says the Windows version is released as an independent branch that uses iocp for asynchronous networking, and that all user interfaces are consistent with the Linux version. Consistent interfaces are not the same as a single codebase. If you ship on both Linux and Windows you are tracking two branches, and the release tags listed for this repository do not tell you whether the Windows branch is at the same revision. Verify that yourself before planning a cross-platform release.

The documentation gap worth naming is service governance. The README advertises built-in service governance and load balancing, and links to two documents, but the text available here does not describe how an upstream list is refreshed, what happens when a node is unhealthy, or how the load balancer chooses. Teams that need that behaviour specified before adoption should read docs/en/about-service-governance.md and docs/en/about-upstream.md first, and treat anything not covered there as work they will own. The README also does not document rollback for a failed upgrade, so pinning a version is the safer default.

srpc is the sibling project, not a drop-in substitute

The closest alternative named in the README is srpc, which the README describes as an independent open source project built on top of sogou/workflow that supports srpc, brpc, trpc and thrift protocols. The difference is one of layer. sogou/workflow gives you tasks, protocols and the graph that sequences them, and leaves the RPC contract, IDL and generated stubs to you; the README explicitly lists implementing a client/server on a user-defined protocol and building your own RPC system as a use case. srpc takes that same engine and supplies the RPC layer and the tooling around it.

So the choice is not which is faster. It is whether you want to define the wire contract yourself. If you already have a protocol, or your service talks HTTP and Redis rather than RPC, adding srpc buys you a code generation step you did not ask for. If you are starting a new service-to-service system and want thrift or brpc compatibility, starting at the workflow layer means writing the layer srpc already ships.

Licence and the cost of staying current

The project is Apache-2.0, and the repository root contains both LICENSE and LICENSE_GPLV2. That second file is worth a look rather than an assumption: the presence of a GPLv2 text alongside the Apache-2.0 licence normally indicates that some component or directory is offered under different terms. Nothing in the README identifies which parts those are, so if you are distributing a binary, check the file headers of the sources you actually compile. This is a factual observation about the repository layout, not legal advice.

Upgrade cost is low on the surface. Releases are tagged, the last push was on 2026-08-10, and v1.1.0 was tagged the same day. The distribution packages mean a Debian or Fedora host can track the library through the system package manager instead of vendoring source. The catch is the C++11 ABI and the OpenSSL floor: moving to a new release can change what your build hosts need, and the README's nossl and Windows branches mean the version you pin is branch-specific. Pin a tag, build your own binary, and treat the compression libraries as build-time requirements only if you use Kafka.

Editorial conclusion

Adopt sogou/workflow if your service is already C++11 and you want HTTP, Redis, MySQL or Kafka calls and CPU work scheduled in one graph without adding boost or asio. Skip it if your stack is Go, Java or Python, or if you need a fully documented service-governance story before committing: the README points to wiki and docs pages for upstream and service governance rather than spelling out the operational model. Before adopting, build the tutorial targets from a clone, confirm OpenSSL 1.1 or above is present on your build hosts, and read docs/en/about-exit.md because it governs how a process with running tasks shuts down.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. sogou/workflow on GitHub