Building Blocks
Chinilla uses 7 blocks to build anything: software, restaurants, hospitals, factories, supply chains. Same 7 blocks, no jargon.
The 7 blocks
Section titled “The 7 blocks”| Block | Default icon | What it is |
|---|---|---|
| Person | User | Someone involved (user, customer, worker) |
| Step | Cog | Something that happens (cook, validate, ship) |
| Storage | Database | A place things live (database, fridge, inventory) |
| Decision | GitBranch | A fork in the road (approved? in stock?) |
| Trigger | Zap | Something that kicks off the flow (timer, new order, alarm) |
| Tool | Wrench | Outside help (Stripe, oven, an email service) |
| Channel | ArrowLeftRight | How things move between blocks (email, API call, in person) |
These map to whatever you’re designing. A “Step” can be a service, a kitchen station, or one stage of an assembly line. A “Person” can be a user, a nurse, or a driver. The AI fills in the domain-specific details when you describe what you’re building.
Icons are just decoration. Each block has a default icon, but you can swap it for any from the library — coffee cup, squirrel, lightbulb, anything that fits. Click Custom in the icon picker to browse 120+ icons across 12 categories. The icon doesn’t change how the block runs; that’s the Behavior and the numbers on the Simulate tab.
What you can set on a block
Section titled “What you can set on a block”Every block has these:
- Name — what shows on the canvas.
- Description — text that pops up when you hover.
- Numbers — rate, capacity, time per item (see below).
- Requirements — framework, language, runtime, OS, hardware, dependencies.
- Cost — monthly cost and setup cost.
- Infrastructure — protocol (HTTP, gRPC, WebSocket, AMQP, Kafka, TCP, UDP, GraphQL, MQTT) and scaling (min instances, max instances, when to scale).
- Behavior — how the block handles items (see Behaviors).
- Subsystem — zoom inside the block to design what it contains.
The three numbers
Section titled “The three numbers”These three numbers shape what the simulator does and what the AI suggests.
| Number | What it means | Examples |
|---|---|---|
| Rate (per second) | How many items the block handles per second at normal load | API: 500, Database: 1000, Human: 2 |
| Capacity | How many items can be in flight or waiting at once | Queue: 100, Server: 50, Worker: 5 |
| Time per item | How long one item takes from start to finish | Cache hit: 5ms, API call: 200ms, ML guess: 2s, FPGA logic: 5ns, PCI hop: 2μs |
The simulator uses these to push items through and figure out where things back up. The AI uses them too when it writes code (thread-pool sizes from capacity, time.sleep() from time per item).
How to think about each:
- Rate is the steady speed. “How many per second does this handle when nothing’s broken?”
- Capacity is the ceiling. “How many can be in flight before stuff queues up or drops?”
- Time per item is the wait. “How long does one item take, beginning to end?”
Real-world examples:
| Block | Rate | Capacity | Time per item |
|---|---|---|---|
| Coffee register | 2 / sec | 1 | 500ms |
| REST API | 500 / sec | 100 | 50ms |
| Postgres database | 1000 / sec | 200 | 10ms |
| ML prediction service | 20 / sec | 5 | 2000ms |
| Kafka queue | 10000 / sec | 500 | 2ms |
| Human reviewer | 0.1 / sec | 1 | 10000ms |
Tips:
- Leave numbers at
0if you don’t know yet. The AI can suggest values based on the block’s description. - Use round numbers to start (100 / sec, 50ms). Tune after a sim run.
- Compare numbers across blocks to spot bottlenecks. If your API handles 500 / sec but your database only handles 100, the database is the bottleneck.
Time units. The simulator accepts any of these and converts them all to the same internal scale, so you can mix them freely on one canvas:
ps(picoseconds),ns(nanoseconds),μs/us(microseconds) — for hardware, FPGA, silicon designsms(milliseconds),s(seconds) — for software, services, networksmin,h,d,w,y— for business, manufacturing, supply chainHz,kHz,MHz,GHz— frequency form (e.g. “1 GHz” parses as 1ns per op)- Throughput form too: “500 drinks/hr”, “10 / sec”, “1k/min”
A design that mixes a 5ns flip-flop, a 2μs PCI hop, and a 20ms network call on the same canvas works as expected — every duration keeps its real ratio.
Infrastructure
Section titled “Infrastructure”The Infrastructure section says how a block talks and how it scales.
Protocol is the main way the block talks. This shapes the code the AI writes (right client libraries) and the Python export (right imports).
| Protocol | Used for |
|---|---|
| HTTP | REST APIs, web services |
| gRPC | Service-to-service calls |
| WebSocket | Live two-way streams |
| AMQP | Message broker (RabbitMQ) |
| Kafka | Event streaming |
| TCP / UDP | Low-level network |
| GraphQL | Query-based APIs |
| MQTT | IoT devices |
Scaling sets how many copies of the block run, and when more get added:
- Min instances — the baseline (always at least this many).
- Max instances — the ceiling (no more than this many).
- Scale trigger — when to add more (e.g.
cpu > 80%,queue.depth > 100).
When Max instances is more than 1, the Python export uses a thread pool sized to that number, and the AI uses parallel patterns like thread pools or multiple processes.