durl splits a short link service into four independently scaled Go modules

Four modules that share nothing, so you scale only the redirect path

The structural idea of durl is that a short link service is really two very different workloads. Redirects are frequent, read heavy and latency sensitive. Everything else, creating links, editing them, administering a blacklist, serving a home page, is rare and does not need to scale the same way. durl therefore splits into four modules with different jobs. The portal is the home page where a user generates a short link, usable by people inside or outside the company. The openApi module exposes create, read, update and delete operations, and the README notes it is generally deployed for internal network access only. The jump module does nothing but serve redirects, and it is described as a dedicated jump service that can be scaled out horizontally when a single machine is not enough. The backend is the admin interface for managing short links and a blacklist, which the README suggests can be embedded as a module in an internal company system. The stated reason for the split is deployment: deploy the module you need. Because the four modules are not coupled to each other, the README says you can add pods freely to raise capacity. That claim is the design's main selling point, and it is also the thing to test first, because horizontal scaling of the jump module is only useful if a link created through one node is visible to every other node.

The cache sits in front of MySQL, and the database is the real limit

The stack is stated as five numbered characteristics and the fourth is the one that decides your sizing. The web framework is beego, persistence is xorm with MySQL as the tested database, and the in-memory cache is mcache, from github.com/songangweb/mcache. The README then says that because the in-memory cache is used as the cache pool, the performance bottleneck in real use is more often the database itself, with a single machine reaching tens of thousands of queries per second. That is a candid statement and a useful one. It means the cache is doing the work on the read path and that scaling the jump module alone will not help once the cache is warm and the database is the constraint. The fifth characteristic says memory consumption is mostly the cache, and that memory size can be limited through a configuration file. The module path is named durl, and the go.mod file lists the dependencies directly, including beego v2.3.3, the MySQL driver at v1.8.1, json-iterator, the xorm ORM and the builder package, and the mcache module pinned to a pseudo version dated 2022-04-01.

module durl

go 1.23.4

So the database tier is a single MySQL instance in the described architecture, with the cache absorbing the read traffic. There is no replication or sharding described anywhere in the documentation.

Getting it running is three steps and one SQL file

The usage section describes a docker-compose experience path with three steps. First you import the database file, with the file address given as durl/doc. Second you modify the configuration information for each module in the durl/build/durl directory. Third you run docker-compose up -d from that same durl/build/durl directory. The system deployment path is separate: the durl/build directory provides a dockerfile demo containing all the modules, which you can modify as needed before deploying. That directory structure, with a demo compose file and a per-module Dockerfile set, is the practical shape of the project. The update log also gives a hint about the operational state. Version 1.1.0 updated the dependency project versions, switched to go mod for dependency updates, and added a MySQL image for testing. Version 1.0.1 fixed bugs and updated docker-compose and the sub images, and version 1.0.0 was the release that fixed bugs and updated the SQL file to durl_2022-05-03.sql. That last name is the one detail worth pinning down in your own notes, because the database file is versioned and the SQL you import should match the code you run.

The documentation lives in a wiki, and it is in Chinese

This is the biggest practical obstacle for an English speaking team, and it is worth confronting early rather than late. The README itself is written in Chinese, and so is the linked reference documentation. The project explains itself through two wiki pages: an Explain page described as mandatory reading for anyone wanting to understand durl in detail, and an Api page for the interface documentation. There is also a configuration file reference link that appears in the README as a commented out link, meaning the author left the markdown link disabled. The project description itself is bilingual, with an English fragment and Chinese text about a distributed high performance short link service. The community channels are also Chinese language: a WeChat contact image, an email address, and a request to star the repository. The maintenance history is short. The changelog stops at version 1.1.0, the repository publishes no GitHub releases, and the last push was on 2026-07-09. None of that makes the code unusable, but it does mean you are adopting a project whose operational knowledge lives in a language and a wiki rather than in issues and a changelog you can search.

What the short link is actually solving for

The README gives three use cases for a short link, and they are worth reading because they explain why the jump module is the performance critical one. The first is character limits on social platforms, with Weibo and Twitter both cited as having a 140 character limit, so sharing a long URL easily exceeds it. The second is marketing SMS, where an over long message is both unattractive and charged at a higher rate for the extra characters. The third is QR codes: the raw link for a QR code is too long, and a complicated code with low pixel density cannot be scanned by some phones with low resolution screens. Each of these is a case where the redirect has to work reliably for a reader who has no context about what is behind it. That shapes the design priorities. The jump module has to answer fast and often. The portal and the admin backend do not. The same split also explains why the blacklist and the API are described as internal-facing: the system is presented as a company internal service for shortening links for campaigns and messages, not as a public consumer redirector at internet scale.

A hosted redirect service differs on control, not on features

The obvious alternative for a team that only needs short links is a hosted service with its own dashboard and analytics, and the difference in approach is about where the data and the failure modes live. A hosted service gives you an admin UI, click analytics, link expiry and abuse handling without anyone writing code, and it keeps a redirector running on someone else's infrastructure. A self-hosted durl gives you the opposite: your own database, your own blacklist, your own deployment, and four modules you can place on separate machines so the redirect path scales on its own. What you give up is the managed layer, since there is no reference implementation for abuse prevention, rate limiting or click tracking in the documentation, and the documentation itself does not mention analytics at all. The dependency list in go.mod does include the Prometheus client libraries as indirect requirements, which suggests metrics are wired in somewhere, but the README does not describe a metrics endpoint. If the requirement is internal link shortening with a controllable deployment, durl fits. If the requirement is public link shortening with reporting and abuse controls, it is the wrong shape of tool.

Editorial conclusion

Adopt durl when you want a self-hosted short link service in Go whose redirect path can be scaled horizontally on its own, and when a team can read the Chinese documentation and wiki pages. Do not adopt it if you need a maintained release line, since the repository publishes no GitHub releases and the last push was on 2026-07-09, or if you want a database independent design, because the README states the performance bottleneck sits in the database once the memory cache is warm. Verify first by running docker-compose up -d from the durl/build/durl directory after importing the SQL file from durl/doc, and check the go.mod requirement on github.com/songangweb/mcache, which is a fork rather than a widely versioned dependency.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. toolsetlink/durl on GitHub