due models a game server as a container of components

The performance claim and its origin

due is presented as an out-of-the-box, lightweight and high-performance distributed game server framework developed in Go, built on a complete native cluster solution that it says easily delivers 430K TPS on a single thread, battle-proven in multiple enterprise-level game projects with stability fully guaranteed. The TPS number is the project's own claim, and the README repeats it in the advantages list as something an ordinary machine achieves easily with a single thread. What the claim is attached to is meaningful. A distributed game server has to accept a connection, decode a packet, run the game logic and send a response, and the number that matters is how many of those round trips a single core can complete. The module design is said to draw on the modular design philosophy of kratos, with the aim of providing a complete, efficient, elegant and standardised solution for game server development, and the framework is MIT licensed, free and open source.

Component and Container

The framework abstracts the gate, the node, the mesh and the cluster client, along with logging, HTTP and pprof capabilities, into components whose lifecycle is orchestrated uniformly by a container. The whole abstraction is this interface:

type Component interface {
    Name() string // component name
    Init()        // initialize the component
    Start()       // start the component
    Close()       // close the component
    Destroy()     // destroy the component
}

func main() {
    container := due.NewContainer() // create a container
    container.Add(component)        // add a component; can be called multiple times
    container.Serve()               // start the container and wait for system signals
}

The order of operations during Serve is specified precisely. It prints framework information, calls Init on each component in order, calls Start on each component in order, writes the PID file, waits for system signals, closes the components concurrently, destroys them concurrently, and then cleans up the PID file and the global modules. Two details matter for anyone writing a component. Signal handling differs by platform, with Windows listening for os.Interrupt and other systems listening for SIGINT, SIGQUIT, SIGABRT and SIGTERM. And the shutdown is bounded, with the Close phase controlled by the etc.shutdownMaxWaitTime setting while the Destroy phase has a fixed five second timeout.

Graceful restart, semaphores and the registry

The rolling update story is built into the lifecycle rather than bolted on. During the Close phase, the Gate, Node and Mesh set their own state to hang and refresh the instance state in the registry, so that new traffic no longer enters the instance while it waits for existing sessions to finish. The advantages list calls this smoothness and attributes it to semaphores that control the service registry. Scalability comes from a graceful route-dispatch mechanism, which the README says theoretically enables unlimited horizontal scaling, and the word theoretically is doing real work there, since that is a design claim rather than a measurement. The combination is a coherent one for a live game server, where taking a node out of rotation and letting its players finish before killing it is the difference between a clean deploy and a wave of disconnects.

A menu of backends for everything pluggable

The feature list is best read as a table of swappable backends, because almost every entry is a set of alternatives. The gateways support tcp, kcp, ws and quic. Logging comes in console, file, aliyun and tencent flavours. The service registries are etcd, consul, nacos and polaris. The wire protocols are json, protobuf, msgpack, xml, yaml and toml, and the configuration centres are file, etcd, consul, nacos and polaris, with file formats of json, yaml, toml and xml. Communication and microservice layers are covered by grpc and rpcx, and the event bus has process, redis, nats and kafka implementations. Caching and distributed locking both come in redis and memcache variants. Encryption covers rsa and ecc. The architecture options are monolithic and distributed, so the same code can run as one process or as a cluster, and there is a fiber server for HTTP with swagger documentation. The due-cli project is the scaffolding toolbox for building cluster projects, and an actor model solution is included.

Four roles in a cluster

The component list names the roles a deployment is made of. A gate is the edge, the server that clients connect to. A node is a game server instance. A mesh is the layer that connects nodes to each other, which is what makes a distributed game world coherent rather than a set of isolated rooms. A cluster client is the piece that talks to the service registry and to the other nodes. Every one of these is a component, which is the neat part of the design, because a component is just something with the five method lifecycle, so a custom registry client or a custom mesh is written the same way as the built-in ones. The event bus and the admin APIs sit alongside them, and the framework also exposes tcp, kcp, ws and quic clients for independent end-to-end debugging, so you can drive a gateway by hand without a game client in the loop.

The repository is a catalogue of infrastructure

The top level of the repository is the clearest description of the scope, because each directory is a subsystem. There are cache/, cluster/, codes/, component/, config/, core/, crypto/, encoding/, env/, errors/, eventbus/, flag/, internal/, locate/, lock/, log/, mode/, network/, packet/, registry/, session/, task/, transport/ and utils/, alongside container.go and due.go at the root, a container_test.go, and directories for docker/ and benchmark/ with a benchmark.md. The benchmark directory and the benchmark document are worth noting, since the README's performance claim is the sort of number that a reader will want to check, and the repository at least has somewhere to look. The framework also ships a .harness/ directory, a codes/ directory and an AGENTS.md, which suggests the project is set up for automated tooling over the codebase, and a tidy.sh script for housekeeping.

The dependency list tells you what it borrowed

The module file shows a Go 1.27.0 requirement and a module path of github.com/dobyte/due/v2, so the project is on its second major version. The direct dependencies are telling. The bytedance sonic library is a fast JSON implementation, which is what you would reach for if message encoding is on the hot path. The ants worker pool library gives a bounded pool for goroutines rather than an unbounded one. The dario.cat mergo library merges configuration structures, and the jinzhu copier library copies between structs, which are the two things a configuration system needs. The shamaton msgpack package is the message pack codec, google.golang.org/protobuf and gopkg.in/yaml.v3 cover the other wire formats, BurntSushi/toml covers toml, fsnotify covers configuration watching, petermattis/goid covers goroutine identifiers and mattn/go-runewidth handles text width for a terminal. The direct dependency count is small for a framework this broad, which is a sign that the breadth comes from interfaces rather than from packages.

Editorial conclusion

due fits a team building a multiplayer server that needs several transport protocols, a choice of service registry and a clean shutdown path, since the container model gives all of that in one interface and the plugin list covers the usual choices. It does not fit a project that needs an independently verified performance figure, because the 430K TPS number is the project's own claim rather than an independently verified figure. It does not fit a team that wants a small dependency surface, since the module pulls in a wide set of infrastructure libraries. Before you adopt it, read the container lifecycle in the documentation, because the ordering of Init, Start, Close and Destroy is what your components have to tolerate, and note the release state, with v2.6.2 published on 2026-10-07 and the last push on 2026-10-14.

Frequently asked questions

Official sources

1. dobyte/due on GitHub
2. License: MIT
3. Project website
4. README
5. Releases