damai: a Damai ticketing clone built to show what a real high concurrency order path looks like

A project whose stated purpose is a portfolio, not a product

The README is unusually direct about why the project exists, and that framing should come first in any evaluation.

It describes itself as a high concurrency ticketing microservice project for enterprise use, covering the full business loop from browsing shows, choosing seats, through payment orders and high concurrency governance. The project background explains the motivation in terms of the Java job market: interview competition is intense, memorising interview answers used to be enough, and now interviewers look at real design projects, asking how complex the architecture is, what was worth highlighting, and which valuable problems were solved.

The description on the repository makes the same pitch, calling the project a choice for interviews, for employment, and for improving one's skills, with the selling point being that the high concurrency solutions are said to be verified in real production environments rather than being simple demos, and that the customised refinements for problems actually encountered in production are said to be there because there is no complete ready made material on the internet for them.

None of that makes the code less interesting. It changes what you are evaluating. You are evaluating a curriculum and a portfolio piece, not a ticketing system you could run for a venue. The README itself says the project serves graduates, people early in their careers, and people with years of experience who want to level up their skills, and it lists what each group should take away: what a production microservice structure actually looks like, what to watch out for in interface calls, how to design and encrypt request and response parameters against attacks, advanced concurrency patterns such as custom thread pools and deep ThreadLocal design, and the real landing solutions for cache penetration, cache breakdown and cache avalanche.

The open source notice in the README is that opening source is not easy, and asks for a star if the project helps. That is a reasonable request and it also tells you the audience.

The business domain, which is a thin layer over a concurrency story

The functional scope is deliberately small, and that is what makes the concurrency work legible.

The system lets a user register, log in, then choose a show and seats, buy a ticket, pay, and query their own orders. The show categories named are concerts, theatre and opera, sports competitions, and children and parent activities.

What the project actually emphasises is the second half of that sentence. The stated user perception of ticketing, especially for a popular artist's concert, is that tickets are hard to get and vanish in an instant, and the project is built to solve not just the purchase function but that hard to get problem, which is the high concurrency problem in common speech.

So when you read the module names, you are reading the curriculum. The top level listing is a set of framework modules, and each one is a topic:

damai-common/ for shared code, damai-spring-cloud-framework/ for the Spring Cloud and Alibaba wiring, damai-redis-tool-framework/ for the Redis layer, damai-redisson-framework/ for the distributed lock work, damai-thread-pool-framework/ for the concurrency programming content, damai-id-generator-framework/ for distributed IDs, damai-elasticsearch-framework/ for the search side, damai-captcha-manage-framework/ for the graphic captcha, damai-server/ for the backend services and damai-server-client/ for the client stubs, plus a vue3/ directory for the front end, an sql/ directory for the schema, and a spotless/ directory for formatting.

The naming makes the point plainly. This is a repository where the framework directories are the point, and the ticketing domain is the excuse that makes them coherent.

Redis used as more than a cache, which is where the lessons are

The technical structure section is where the actual claims live, and the Redis entry is the most interesting.

The README says Redis is used not only as a cache but also with advanced features such as Lua scripts, delay queues and the Stream message queue. That is the difference between using Redis as a lookup table and using it as part of the concurrency control design.

A Lua script is the standard answer to the problem of a read-modify-write across several keys, because Redis executes it atomically on the server. A delay queue, usually built on a sorted set with a score as the delivery time, is the standard answer to work that must happen later without a scheduler holding state. The Stream structure is the answer when you need a log of messages that can be consumed by groups, which is a different guarantee from a pub/sub channel.

So the Redis layer here is doing three distinct jobs, and each one has a reason to exist under load that a plain GET and SET does not cover.

The other layers follow the same pattern of being named for the failure they handle. Nacos is the service registry, so a service instance can find its peers. Kafka is the message middleware, and SpringBootAdmin is the monitoring and notification for services. The ELK stack records logs, and Elasticsearch provides search and display. Sentinel and Hystrix form the circuit breaker protection layer. ShardingSphere implements sharding across databases to store large volumes of data.

The stated purpose of the whole set is to achieve the capacity for high concurrency and high throughput, storage of massive data, and monitoring of service state. Each component is a response to a specific bottleneck, which is the correct way to read a stack like this: not as a shopping list, but as a sequence of problems.

Four versions of order creation, which is the actual teaching device

One detail in the README deserves more attention than anything else in the project background.

The order generation feature alone has four versions, and the stated reason is pedagogical. It is to explain how to think under high concurrency about what should be optimised and in what order, showing that each step should be progressively refined.

That is a teaching design, and it is a good one. A single optimised implementation teaches nothing about why the optimisation is there. A sequence from the naive version to the version with a distributed lock, to the version with a reservation counter and a pre heat of the data, to the version with a multi level cache, tells you the reasoning and lets you stop at the version your actual problem needs.

The README also lists the specific dimensions along that path, and they are the usual ones, stated plainly. Optimising the locking strategy, so that local locks and distributed locks are used with an understanding of whether the lock is taken inside or outside the method, whether a plain lock() call is enough, how a transaction interacts with the lock, and how annotations interact with other aspects. Multi level cache management, so that under very high concurrency the design of caching and of data consistency is addressed rather than assumed. Data pre heating, so the data is ready before the request arrives. And precise quota limiting, so that traffic beyond the capacity is turned away deliberately rather than allowed to consume the system.

The point about limits is the one that separates a real ticketing system from a demo. The failure mode of a naive implementation is not a slow response, it is a system that accepts every order it receives and then cannot fulfil them. A quota turns that into a fast rejection, which is both cheaper and honest.

Documentation that lives on a site, and an online demo to compare against

The README is a landing page rather than a manual, and it points at four places.

The official documentation is at javaup.chat under the damai section, and the links given are the project introduction, the quick start guide for prerequisites, and the core architecture page. There is a separate online demo at damai-javaup.chat, and a detailed explanation of the project linked from the introduction page.

That structure tells you something about the intended workflow. The code is the reference implementation and the site is the explanation, and the demo is the way to see the intended behaviour before you read the code. For a project whose selling point is that it shows a real high concurrency path, having a running instance to compare against is more useful than another diagram.

The architecture diagrams are hosted as images on a separate asset host, one animated diagram for the project architecture with dynamic optimisation, one static image for the business architecture. The business diagram is described as covering service configuration, technology selection, core business, design components, middleware usage, monitoring approach and the high concurrency strategies, which is a reasonable map of the things a reader wants to orient themselves in.

The limitations of this arrangement are real. The diagrams are not in the repository, so they are not versioned with the code, and a reader without access to the site is left with a fairly rich README and a module list. The quick start prerequisites page is where the actual bring up instructions live, which means the repository alone does not tell you how to run it, and for a project that ships a SQL directory, a Vue front end and seven middleware dependencies, the environment setup is the part most likely to consume your afternoon.

The technology selection table in the README does list the full stack with links: Spring Boot as the web framework, Spring Cloud for microservices, Spring Cloud Alibaba, Spring Cloud Gateway as the microservice gateway, Nacos, Sentinel, Log4j2, MySQL, MyBatis-Plus as the ORM, MyBatisGenerator as the data layer code generator, and AJ-Captcha for the graphic captcha.

What you inherit when you clone it

The practical cost of adopting this as a reference is worth stating before anyone starts.

The project is a Maven multi module build, as the README badge says, and the root pom.xml sits alongside the module directories. It requires Java 17 or newer. The front end is a separate Vue 3 application in its own directory, so getting the whole thing running means building a Java stack and a Node stack.

Then there is the infrastructure. Nacos for registry and configuration, Redis, Kafka, MySQL with a schema you import from the sql/ directory, Elasticsearch with the ELK logging stack, and the gateway. That is not a set of dependencies you install and configure in a few minutes, and the quick start page is where the sequencing is documented, which means the order of operations matters and getting it wrong produces errors that are hard to read.

Two smaller signals are worth noticing. The repository carries a spotless/ directory, so code formatting is enforced by a build tool rather than by convention, which tells you the project is maintained with some discipline. And the theme is clearly teaching material, in a way that is worth naming because it affects how you read the code: the README talks about the project helping you write a resume line, and about how it would look to an interviewer who has not seen the project before. That framing leads to code that is annotated for teaching, sometimes in several versions of the same function, and code written for a portfolio is not the same artefact as code written for a system with a nine year service life.

So the reasonable way to use this repository is as a set of annotated reference implementations to read and compare, with the online demo for the behaviour, rather than as a codebase you fork and ship.

Editorial conclusion

damai fits a Java developer who wants to read a realistic order path under load, particularly the parts that are hard to learn from framework documentation: how a lock is scoped, where a cache layer is added, how a reservation count is turned down instead of letting the database fall over, and how an order creation path changes as the numbers get larger. It does not fit a team looking for a ticketing product to deploy, because the project is explicitly a demonstration built for study and for portfolios, and it does not fit a team without the middleware it assumes, since Nacos, Redis, Kafka, Elasticsearch, MySQL and the ELK stack are not optional parts of the story. Check three things first. Check that the components in the stack are the ones you want to learn, because the choice of Sentinel and Hystrix, Spring Cloud Gateway and ShardingSphere is the curriculum. Check the documentation, because the README delegates the setup to a quick start guide and an online demo rather than giving you a one command bring up. And check the size of the dependency surface, because a Maven multi module project with a Vue 3 front end directory and a SQL directory is a substantial checkout for a code reading exercise. The last push was on 2026-10-19 and the license is Apache-2.0.

Frequently asked questions

Official sources

1. Issues
2. java-up-up/damai on GitHub
3. License: Apache-2.0
4. Project website
5. README