Reading a C4 Level 2 Container Architecture: Cloudflare, Gateway, Queue and Monitoring — So AI Doesn't Lead You Around When Vibecoding

In the C4 model, Level 1 (System Context) only tells you who uses the system and what the system talks to. Level 2 — the Container level — goes inside: which containers the system is made of, and how they talk to each other. A walkthrough from the Facebook page Code Web Không Khó reads a real web architecture exactly along that axis, from the outside in: Cloudflare at the gate, a Gateway splitting traffic by subdomain, a Backend with a realtime API and a queue, a PostgreSQL – MinIO – Redis data tier, and a Prometheus – Grafana – Loki monitoring stack running entirely on internal ports. Understanding this diagram means understanding the whole system — and it is the prerequisite for working with AI without being led around by it when vibecoding.

Quick answers

• C4 Level 2 (Container) breaks the inside of a system into containers — independently runnable applications, services and data stores — and shows how they communicate; it is the next step after Level 1 (System Context: who uses the system and which external systems it connects to).
• In the example architecture, a request flows from the outside in: Internet → Cloudflare (blocks bots and malicious requests, HTTPS on port 443 only, HTTP port 80 switched off in production) → the internal LAN → the Gateway (Nginx or Kong) acting as reverse proxy → the frontends and services inside → the data tier → with Monitoring watching over everything.
• The Gateway routes by subdomain: the main domain goes to the User Frontend; the admin subdomain to the Admin Frontend; the app subdomain to the App; plus a separate Link Base service; and a dedicated MCP path (via the mcp subdomain) so AI can interact with the system.
• The Backend pairs an API with a queue: an API written in Express + Socket handles realtime needs (chat, notifications, instant order-status updates — swappable for Go + Gin), and a BullMQ Queue lines up jobs so the server does not collapse when many users arrive at once, and no task gets lost.
• Data tier and monitoring: PostgreSQL stores the primary data (users, orders, products); MinIO stores files, images and video like a self-hosted S3; Redis is the cache. Monitoring — Prometheus (metrics), Grafana (dashboards), Alertmanager (alerts pushed to a bot), Loki (log aggregation) — runs on internal ports, unreachable from outside.

What is C4 Level 2 (Container)?

The C4 model is a way of drawing software architecture at several zoom levels. Level 1, System Context, is the outermost view: who the users are, where your system sits, and which external systems it talks to. Level 2, Container, zooms into your system itself: which containers it contains — a container being an independently runnable unit such as a web application, an API, a database or a background service — and how they communicate, with what, and in which direction.

The value of Level 2 is its immediacy: one look at the diagram and you can picture the whole system — where a request enters, where it branches, where the data lives, and which part watches over which. According to the original author, this is also the foundation for working with AI in the vibecoding era: whoever can read the architecture stays in control of the system, instead of letting the AI draw and decide on its own.

How do you read the architecture from the outside in?

The walkthrough follows the exact path of a request, in seven stages:

Stage	Component	Role in the example architecture
1. Internet gate	Cloudflare	The first "city wall": blocks bots and malicious requests from outside and prevents direct access to the server; requests enter over HTTPS port 443, with HTTP port 80 switched off entirely in production
2. Internal network	LAN (the white box in the diagram)	All internal services communicate over this LAN; outsiders cannot interfere — in the author's words, the system's sturdiest wall
3. Gatekeeper	Gateway — Nginx (or Kong)	A reverse proxy that routes each request to the right internal service, split by subdomain
4. Backend	API (Express + Socket) + Queue (BullMQ)	The API handles business logic and realtime; the Queue lines up jobs so the system survives load spikes without losing work
5. Data tier	PostgreSQL + MinIO + Redis	Primary data, files/images/video, and cache — everything the Backend does is stored in this tier
6. Monitoring	Prometheus + Grafana + Alertmanager + Loki	Measures performance, draws dashboards, raises alerts and aggregates logs; runs on internal ports, unreachable from outside
7. Outbound	Discord / Google Drive / Backup	Notifications pushed to external platforms; data and backups pushed off the server so the data survives even if the server dies

How does the Gateway split traffic by subdomain?

After Cloudflare, every request reaches the Gateway — Nginx in the example architecture, with Kong noted as an alternative. The Gateway acts as a reverse proxy, routing requests to the correct internal service based on the subdomain:

• Main domain → User Frontend, where end users arrive.
• admin subdomain → Admin Frontend for administration.
• app subdomain → the App.
• Link Base → a service of its own.
• mcp subdomain → a dedicated MCP path for AI, so AI can interact with the system.

Per the author, MCP (Model Context Protocol) is a trend worth noting: reserving a container and a dedicated entry path for AI right inside the Level 2 architecture shows a system designed on the assumption that AI is a special "user" of the system, rather than an add-on bolted on later.

What is in the Backend: realtime API and Queue?

The example Backend has two main blocks. First, an API written in Express + Socket: the Socket layer serves realtime needs such as chat, notifications and instant order-status updates; the author notes it can be swapped for Go + Gin if preferred. Second, a Queue using BullMQ to process job queues.

The author's analogy is a fried-chicken shop: when 100 people walk in at once, they line up — first come, first served. The queue processes multiple jobs in order and has techniques to ensure no queued task is lost. Without a queue, 100 people rushing in at once would crash the server. That is why the queue appears as its own container in the Level 2 diagram instead of being folded into the API: its role, its processing rhythm and its failure modes are completely different from the part that answers requests directly.

What does the data tier consist of?

Everything the Backend does is stored in a Data/Infra tier of three containers:

• PostgreSQL: the primary data — users, orders, products.
• MinIO: files, images and video — like a self-hosted S3. One tip the author shares: when a user requests an image, the request goes straight to MinIO through the Gateway, and the Gateway caches that image; the next load is very fast because the image has effectively become cached static content.
• Redis: caching — temporary storage of frequently used data for fast loads.

This three-way split reflects three different natures of data: relational data that needs integrity (PostgreSQL), large files that need cheap, self-controlled object storage (MinIO), and temporary data that needs speed (Redis).

How is the Monitoring system organized?

Monitoring in the example architecture runs on internal ports — unreachable from outside — and consists of four components:

• Prometheus: plugs directly into PostgreSQL, Redis, Node and many other components to measure performance.
• Grafana: draws dashboards for CPU, RAM, request volume and other indicators.
• Alertmanager: when something goes wrong, it pushes a notification to a bot so the operator knows immediately. (In the author's Figure 2, this layer also includes Tempo for distributed tracing, and Alertmanager's alerts are pushed via the Telegram Bot API.)
• Loki: collects all of the system's logs. The practical payoff the author emphasizes: when a user reports an error and the cause is unclear, you search Loki, let the AI read that very log — and it finds the bug and fixes it for you.

The lesson here is that Monitoring is drawn as a horizontal layer watching every other container, not as a feature of the Backend alone — and locking it behind the internal network is a deliberate security decision in the architecture.

How do you keep the architecture correct when working with AI?

This is the message the author most wants to send. Once you have built an architecture like this, the next problem arrives immediately: when you work with AI through prompts every day, how do you keep this architecture up to date and stop the AI from drawing it differently over time?

The shared solution is to create a Rules folder containing the project's entire software-development process. The AI then follows those Rules in every subsequent working session — that is how the author keeps the architecture true to its intended standard, instead of letting each AI session "re-invent" the system in a different direction. The author's screenshots show the concrete implementation: a custom /architecture-plan command in the project's command system, casting the AI as a Principal Software Architect to generate and update the official architecture document (architecture.md), with every claim grounded in file-and-line evidence from the codebase — no guessing, no fabrication. In other words: the Level 2 diagram gives humans the overview, and the Rules folder is how you force the AI to respect that same overview.

In summary, the example architecture closes into this chain: User → Cloudflare (bot filtering) → Gateway Nginx/Kong (subdomain split) → User/Admin/App Frontends + MCP + API + Queue → Data Tier (PostgreSQL + MinIO + Redis) → Monitoring (Prometheus + Grafana + Loki) watching everything, with backups and notifications pushed outside (Discord, Google Drive, Backup) at the output end.

Frequently asked questions

How does C4 Level 2 differ from Level 1?

Level 1 (System Context) views the system from outside: who uses it and which external systems it connects to. Level 2 (Container) zooms inside that system: which containers it consists of (applications, APIs, databases, queues…) and how those containers communicate. To understand how a request travels through the system, you need Level 2.

Why open only port 443 and switch off port 80 in production?

Per the author's walkthrough, requests from the Internet must first pass through Cloudflare, which blocks bots and malicious requests, and then enter the system over HTTPS port 443. In production, HTTP port 80 is switched off entirely, leaving only 443 — meaning every connection must be an encrypted one through the protected gateway, with no unencrypted side entrance left for attackers to probe.

Is Nginx or Kong the better Gateway?

The example architecture currently runs Nginx as the reverse proxy, and the author says Kong works too. The Gateway's core role at Level 2 is routing requests by subdomain to the right frontend or service inside (main domain → User, admin → Admin, app → App, mcp → the AI path). Nginx versus Kong is an implementation decision; what matters architecturally is that the system has a single, clear entry point instead of each service exposing itself to the Internet.

What problem does the Queue (BullMQ) solve?

The queue lines jobs up to be processed in first-come-first-served order instead of forcing the server to handle everything at once. In the author's analogy: like a fried-chicken shop with 100 customers arriving simultaneously, the queue keeps the system from collapsing under a load spike, with techniques to make sure no queued task is lost. In the C4 Level 2 diagram, the Queue is its own container, separate from the API that answers requests directly.

How does a Rules folder stop AI from redrawing the architecture?

According to the author, the Rules folder holds the project's entire software-development process. When working, the AI complies with those rules, so the architecture that was designed stays consistent across many prompt sessions instead of the AI proposing a different structure each time. It is a mechanism that "locks" the architecture at the process level, complementing the C4 diagram — the diagram helps humans read and verify, the Rules help the AI do it right from the start.

Conclusion

Reading a Container Level 2 diagram means reading the entire system in one picture: the Cloudflare gate, the internal LAN boundary, the Gateway splitting traffic by subdomain, a Backend with a realtime API and an overload-proof queue, a three-part PostgreSQL – MinIO – Redis data tier, and Monitoring sealed on internal ports watching over everything. In the vibecoding era, the diagram's value is even greater: it is the "reference map" against which everything the AI generates can be checked. Whoever holds the map uses AI as a tool; whoever doesn't will be led around by it — and the Rules folder is how the author turns that map into law the AI must follow every day.

Source: walkthrough by the Facebook page Code Web Không Khó (9 November 2026) on reading a Container architecture under the C4 model's Level 2, with the author's own system diagram; edited and structured by Wotech Electronics. The example architecture, technology choices and operational tips in this article are as shared by the author. Illustrations: photos attached to the original post.