Systemizer lets you push data through a diagram of your own architecture

A diagram you can push data through

Systemizer is described as a system design tool used to create and simulate large scale distributed systems. The simulation part is what separates it from a drawing tool, and the README describes the loop in three steps: select a component, which can be an API, a Client or a Message Queue, create customizable endpoints and connect the components together, then send data to endpoints and watch the data flow of your system.

That last clause is the product. In a conventional architecture diagram, arrows mean an intention. In Systemizer they mean a message that has a payload and a destination, so the diagram becomes a thing you can run rather than a thing you can argue about. A design review can move from a whiteboard to a running sketch of the proposed service boundaries, with data visibly arriving or not arriving where it should.

The component types are deliberately generic. API, Client and Message Queue are named as examples, and the phrase that follows them is the important part, you name it. Nothing in the README restricts the vocabulary, which is what makes the tool usable for an architecture that has databases, caches, workers or third-party services in it.

Endpoints are customizable rather than fixed, which is the second mechanism that makes the simulation meaningful. Whether a particular endpoint accepts a body, what shape it takes, and how components are chained are decisions the person drawing the diagram makes, and those decisions are exactly the ones a design review is supposed to surface.

Running it locally versus using the hosted demo

There are two ways in, and the hosted one is the faster route. The README says Systemizer is currently hosted on GitHub Pages, with the site linked from the project page, and an animated GIF shows the tutorial flow. A hosted copy is enough to see whether the interaction model suits you before spending time on a local checkout.

The local route is five steps, and the install is unusually simple for an Angular project because the dependencies are already declared:

npm install
npm run start

The README lists the full sequence as cloning the repository to your local machine, opening a terminal and changing into the repository folder, running npm install, running npm run start, and then, in its own words, systemizing. The start script maps to the Angular development server:

    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"

What you should expect is the standard Angular developer server, with the application served locally and hot reloading during development. The scripts cover the usual ground, including unit tests, linting and an end-to-end target.

The repository layout confirms a conventional Angular application rather than anything unusual: an angular.json file, a src directory, separate tsconfig files for the app, the base configuration and the spec build, a karma.conf.js for the test runner, and a tslint.json. The docs directory holds the documentation site. Documentation is also available in the wiki section of the repository, with a separate how to contribute page there, and the issues tracker is pointed at for anything else.

The dependency set reveals the age of the stack

The package manifest is worth reading closely, because it dates the project precisely. The Angular packages sit at version 15.2.x, the Angular component kit and CDK at 15.2.9, and TypeScript at roughly 4.9.5. RxJS is pinned at 6.6.7, zone.js at 0.11.4, and the test stack is Jasmine with Karma and Protractor, the last of which is the clearest sign of the generation this code was written in.

For a tool being used in a browser, that is not automatically a problem. Angular 15 runs in every current browser and the tool's job is to draw boxes and move messages between them, which is not demanding. The cost of an older stack is not runtime performance but maintenance: a contributor arriving today has to work with a dependency tree whose test runner and linting tooling have all moved on since, and the Protractor end-to-end target in particular sits on a toolchain that upstream has since replaced.

Two dependencies hint at what the tool does under the hood. object-hash provides a stable hash of an object, and ts-md5 provides an MD5 implementation, and both are the kind of utility you reach for when you need to identify a message or a data structure so you can tell whether what arrived on the other end is the thing you sent. A colour picker component, ngx-color-picker, and until-destroy, an Angular lifecycle helper, round out the list.

The MIT versus GPL question is worth separating from these. The project is licensed GPL-3.0, which is a copyleft licence, and the top-level LICENSE file is where the terms are. For a tool you run internally that is usually workable, but for a tool whose code you embed into something you distribute, GPL-3.0 obligations travel with the derivative work, and that is a question for the licence text rather than for this review.

What the simulation cannot tell you

The limitation is structural and worth stating in plain terms: everything Systemizer shows you is data you typed in. There is no connection to a running system, no traffic capture and no instrumentation. The picture on screen is a faithful rendering of your model of the architecture, and the quality of the answer is bounded by the quality of the model.

That cuts both ways. For the question it is built for, which is whether a proposed design makes sense before you build it, the tool is a good instrument. For the question it is often asked, which is why production is slow, the tool answers nothing at all, because the model it would need is the thing you do not have yet.

A second limitation is that a diagram is a simplification by construction. A real service has retries, timeouts, partial failures, backpressure, rate limits and idempotency rules, and the tool's component and endpoint model does not claim to represent all of them. A user who draws a clean line from a client to an API has learned something about the topology and nothing about the failure modes, which are usually where the design work actually is.

The right way to use it, then, is as a thinking tool in a room with other people, where the disagreements surface as soon as someone tries to draw the message that has to cross the boundary. The wrong way to use it is to produce a picture and present it as evidence.

Where the project stands

The repository is not archived, and the last push was on 2026-09-10. There are no GitHub releases, so there is no tagged version to pin to, and the version field in the package manifest reads 0.0.0, which is the conventional placeholder for a private application package rather than a shipped release number.

The hosted demo is the reason the project is still easy to try. A GitHub Pages deployment means someone can open a URL and start drawing without installing Node, and for a tool whose value is the interaction, that matters more than the code.

The documentation arrangement is split in a way that reflects the project's stage. The wiki holds the documentation and the contribution guide, the issues tracker is where questions and bugs go, and the README is a short index that points outward rather than trying to describe the tool in place. The top-level entries also carry a docs directory for the documentation site and an .editorconfig, which is a small sign that the surrounding conventions are in place even though the tool itself has not shipped a versioned release.

For anyone evaluating it, the useful next step is not to install it. It is to open the hosted demo, draw one request path through a system you already know, and see whether the simulation raises anything you had not already argued about.

Editorial conclusion

Systemizer suits an engineer or a team that wants to argue about a service design with something more concrete than a whiteboard, and who is comfortable drawing the system before it exists. It is the wrong tool for a team that needs live traffic facts, because everything the tool shows is data you typed in, and for a design that involves protocols and semantics it cannot represent. Before you adopt it, sketch one realistic request path through your proposed architecture in the tool, check the diagram against the latency and failure behaviour you actually care about, and read the GPL-3.0 licence at the repository root, because that copyleft has real consequences for a tool you intend to embed in internal tooling.

Frequently asked questions

Official sources

1. honzaap/Systemizer on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README