advanced-java is an index of interview questions, and four of them have no answer file

The GitHub page is an index, and the answers live in a VitePress site

The repository page for this project is 307 words of links, and that is the shape of the project rather than an unfinished landing page. The top level holds docs/, images/, Main.java, package.json, tsconfig.json, a .npmrc and a pnpm lockfile, which describes a documentation site, not a library you consume. Every answer sits in its own Markdown file under docs/, wired together by the site configuration and served at java.doocs.org. So the repository tells you which topics exist and nothing about how long or how careful any individual answer is.

That has a direct effect on how you evaluate it. If you are choosing between this and another question bank, the index is the only thing you can compare from the page, because the prose sits one click away and is not visible from GitHub at all. The practical consequence is that you should read the files rather than the index when you care about depth. Clone the repository and grep the answers offline, or read them on the site, because nothing on the project page summarises what is inside them.

Four high-availability questions ship as bare text with no file behind them

Most entries in the availability chapter are links into files under docs/high-availability/. Four are not. How to design a high-availability system, how to do circuit breaking, which circuit-breaking frameworks exist and how they work internally, and how to do degradation all appear as plain question text with no linked answer. Every neighbouring line in the same chapter, from the Hystrix introduction through thread pool isolation, semaphore isolation, request cache, fallback, timeout and the entry on choosing between Sentinel and Hystrix, does carry a file.

That asymmetry is the useful signal. The linked entries were written and filed, and these four were queued and never written. If you are revising for a system design or resilience interview, this is exactly where you should expect the index to stop, and circuit breaking and degradation are the two topics most likely to be raised in the same conversation. Nothing on the page marks the gap as unfinished, so you have to notice the missing links yourself, and a reader who assumes every bullet has an article behind it will be disappointed twice in one sitting.

The microservices chapter is labelled unfinished in the index itself

The microservices section does not open with a normal entry. It opens with a note saying that the whole chapter is an extra addition, that updates will come later, and that readers are invited to contribute the missing material. Read that as a status label rather than a description of the content.

The pages it does list, an introduction to the architecture, migrating from a monolith, event-driven data management, and choosing a deployment strategy, are recent additions to a knowledge base whose other chapters predate them. The high-concurrency, distributed-system and availability material is the older core. The consequence for a reader is that the two halves of this index carry different levels of finish, and only one of them says so out loud. If microservices is the subject you are studying, treat that chapter as a draft and check its answers against the projects it describes, because the project itself is asking for help finishing it.

One release tagged in 2021, prose edited on 2026-09-24

The repository has a single tagged release, v2.0, dated 2021-10-21. The last push to the default branch main was on 2026-09-24, and the repository is not archived. Nothing in between carries a version.

The consequence is that there is no artefact to pin. You cannot say which revision of an answer you read, and there is no changelog to diff when an answer is rewritten underneath you. For a dependency that would be an ordinary release cadence problem. For prose it is quieter and harder to notice, because a silently edited answer still reads as authoritative once someone has copied it into a team wiki. If you intend to quote from this index, record the commit you read, the same way you would for any vendored documentation that carries no releases.

Self-hosting the site means an alpha VitePress and five pinned transitives

There is no install command on the project page because there is no package to consume. The site is built with pnpm and VitePress, and the entire toolchain is declared in package.json. Two of those declarations decide whether a build works at all: the package manager is pinned, and the VitePress dependency is a prerelease.

  "packageManager": "[email protected]",
  "engines": {
    "node": "^20.19.0 || >=22.12.0"
  },
  "scripts": {
    "docs:dev": "vitepress dev docs",
    "docs:build": "vitepress build docs",
    "docs:preview": "vitepress preview docs",
    "typecheck": "tsc --noEmit"
  },

The VitePress entry is version 2.0.0-alpha.20, and pnpm then holds five transitive packages at exact versions through an overrides block, so the graph is pinned from outside the dependency that asks for them:

  "pnpm": {
    "overrides": {
      "vite": "8.3.0",
      "esbuild": "0.28.2",
      "postcss": "8.5.28",
      "nanoid": "3.3.19"
    },
    "onlyBuiltDependencies": [
      "esbuild"
    ]
  }

Only esbuild appears in onlyBuiltDependencies, so it is the single package permitted to run install scripts. There is no test script; typecheck is the only check on the content, and it checks TypeScript rather than prose. The three commands that matter are:

pnpm docs:dev
pnpm docs:build
pnpm typecheck

The consequence for anyone hosting their own build is that you inherit an alpha and five hand-pinned transitives at once. A security update to any of those five means editing package.json rather than bumping a dependency, and the two Vite and esbuild pins are the ones most likely to collide with a future release of the alpha.

The stack it names is Dubbo, Hystrix and Redis, and Spring Boot never appears

Read the index and the stack it assumes becomes legible. The distributed-service chapter is entirely Dubbo: how it works, what happens when the registry is down, its serialization protocols including Hessian and Protocol Buffers, load balancing, cluster fault tolerance, dynamic proxying, its SPI approach, and how to design a similar RPC framework yourself. The availability chapter is largely Hystrix, down to thread pool isolation, semaphore isolation, circuit breaker internals, request cache, local cache fallback and timeout, with one entry on choosing between Sentinel and Hystrix. Caching is Redis throughout, covering the single-threaded model, data types, expiration policies, master and slave replication, Sentinel, cluster addressing, persistence, rehash and CAS, alongside MySQL read-write separation and Elasticsearch cluster deployment. Message queues get their own treatment, with the advantages and disadvantages of Kafka, ActiveMQ, RabbitMQ and RocketMQ.

Spring Boot appears nowhere in that list. If your day job runs on Spring Boot, treat this as background theory for interviews rather than as a guide to your own service, because the answers will not map onto your framework, your configuration or your failure modes. That gap is not a defect in the writing; it is a scope decision, and it is worth knowing before you spend an evening on it.

Most of the answers are credited to 中华石杉 under a share-alike licence

The project states that most of the material comes from 中华石杉, that the copyright belongs to that author, and that the doocs maintainers have organised it for study and reference. The repository's licence is CC-BY-SA-4.0.

Two consequences follow for anyone who plans to reuse an answer. The first is attribution. The credit names an individual author rather than the organisation hosting the repository, so a slide deck or an internal wiki page that reproduces an answer should carry that name. The second is the share-alike term, which is what the SA in the licence identifier means: a derivative has to be distributed under the same licence, so pasting an answer into a document you then publish under different terms is not a neutral act. Read the LICENSE file in the repository before you copy anything out of it. This is a pointer to the two documents you have to reconcile, the credit line and the licence text, not an interpretation of either.

Editorial conclusion

Use this index when you are revising distributed-systems and caching questions and you want the answers in one place, and do not expect it to map onto the framework you actually run. Two things to check before you rely on it: the four high-availability questions whose file was never written, and the commit you read, because the only release is v2.0 from 2021-10-21 while the default branch was pushed on 2026-09-24. If you copy an answer into something you publish, carry the 中华石杉 attribution and the CC-BY-SA-4.0 share-alike term with it.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes