# carlamndz/inventarioitu architecture

> Architecture diagram of the GitHub repository carlamndz/inventarioitu, generated by GitDiagram from its file tree, README and a sample of source files (last updated 2026-06-23). It is an AI-made overview: check details against the source.

- Interactive diagram: https://gitdiagram.com/carlamndz/inventarioitu
- Repository: https://github.com/carlamndz/inventarioitu

## Overview

1. **What this repository is**
   - This repo is a **system blueprint + deployment skeleton** for an inventory platform called **“Ecosistema de Inventario Seguro”**.
   - The architecture is split into a **web application**, **two separate data stores**, **LDAP-based authentication**, and **Kubernetes deployment artifacts**.

2. **Main user-facing subsystem: `app/`**
   - `app/` is the **Node.js + Express** application labeled in the README as `inventario-web`.
   - It acts as the **central entry point** for users to consult inventory information.
   - Architecturally, this is the only application layer exposed on the listed application port: **3000**.

3. **Data persistence is intentionally split by domain**
   - The repo uses **two databases for two different kinds of data**:
     - `db/sqlserver/` for **location and assignment data** (`ubicacion-db`, port **1433**).
     - `db/mongodb/` for **hardware/component inventory data** (`inventario-db`, port **27017**).
   - This is an important boundary: the system is **not** storing everything in one database; relational and document data are separated by responsibility.

4. **Relational data flow: SQL Server**
   - SQL Server holds the **structured inventory metadata**: lab location, assigned machines, and related relational entities.
   - From the README, this is the data source for **where a computer is and who/what it is assigned to**.
   - If drawing the architecture, place SQL Server on the “inventory location/assignment” path only.

5. **Document data flow: MongoDB**
   - MongoDB stores the **hardware details** of the computers: components and other semi-structured inventory attributes.
   - This suggests the app queries MongoDB for **machine internals** while querying SQL Server for **organizational placement**.
   - The split indicates a hybrid persistence model rather than a single normalized schema.

6. **Authentication boundary: LDAP / Active Directory**
   - `ldap/` represents the **OpenLDAP side** of the architecture, exposed as `ldap-service` on port **389**.
   - The README states authentication is against **Active Directory/LDAP**, so the web app likely relies on LDAP for login and identity validation.
   - In the diagram, LDAP should be shown as an **external identity provider / auth subsystem**, separate from the business data stores.

7. **Kubernetes is the deployment and isolation layer**
   - `k8s/` contains manifests for each subsystem:
     - `k8s/frontend/`
     - `k8s/sqlserver/`
     - `k8s/mongodb/`
     - `k8s/ldap/`
     - `k8s/network-policies/`
   - This means the platform is designed to run as **multiple isolated Kubernetes workloads**, not a monolith.
   - `network-policies/` is especially relevant: it implies **explicit traffic restrictions between components**.

8. **Security and segmentation are first-class concerns**
   - The presence of Kubernetes **NetworkPolicies** plus a separate LDAP service indicates the repo is designed for **controlled east-west traffic**.
   - Likely intent: the frontend can reach only the required databases and LDAP, and the databases should not be publicly reachable.
   - For an architecture diagram, show **restricted internal service-to-service communication**, not an open flat cluster network.

9. **Documentation and diagrams live separately**
   - `docs/` is reserved for supporting documentation and diagrams.
   - Since the repo itself currently contains mostly placeholders, the repository structure is acting as a **project scaffold** for the final system design and deployment assets.

10. **Current repository state**
   - The tree shows mostly `.gitkeep` files, so the repository is currently **structural rather than fully populated**.
   - The architecture should therefore be drawn from the README’s intended design: a **frontend + LDAP auth + dual-database backend**, all deployed in Kubernetes.

11. **End-to-end request path**
   - The most likely flow is:
     - User accesses **inventario-web**
     - The app authenticates against **LDAP/Active Directory**
     - The app reads **location/assignment** data from **SQL Server**
     - The app reads **hardware/component** data from **MongoDB**
   - This is the key data flow to emphasize in a diagram.

12. **Technology footprint that materially affects architecture**
   - Runtime/app layer: **Node.js + Express**
   - Datastores: **SQL Server** and **MongoDB**
   - Identity: **OpenLDAP / Active Directory**
   - Platform: **Docker + Kubernetes**, with **Minikube + Calico** mentioned in the README
   - Security tooling/networking: **GUFW** and Kubernetes **network policies**

13. **How to draw the system boundary**
   - Treat the repository as one logical system with four internal services:
     - web app
     - SQL Server
     - MongoDB
     - LDAP
   - Surround them with a **Kubernetes cluster boundary** and show the user entering only through the web app.
   - Keep LDAP and both databases as **internal dependencies** rather than user-facing endpoints.

Main entry points: [`app`](https://github.com/carlamndz/inventarioitu/tree/main/app) (inventario-web), [`README.md`](https://github.com/carlamndz/inventarioitu/blob/main/README.md) (README), [`k8s/network-policies`](https://github.com/carlamndz/inventarioitu/tree/main/k8s/network-policies) (Network policies), [`db/sqlserver`](https://github.com/carlamndz/inventarioitu/tree/main/db/sqlserver) (Location DB)

## Diagram (Mermaid)

```mermaid
flowchart TD

subgraph group_runtime["Runtime services"]
  node_app["inventario-web<br/>Node.js app"]
  node_sqlserver[("Location DB<br/>SQL Server")]
  node_mongodb[("Inventory DB<br/>MongoDB")]
  node_ldap[("LDAP service<br/>OpenLDAP")]
end

subgraph group_deployment["Kubernetes deployment"]
  node_k8s_frontend["Frontend manifests<br/>k8s manifests"]
  node_k8s_sqlserver["SQL manifests<br/>k8s manifests"]
  node_k8s_mongodb["Mongo manifests<br/>k8s manifests"]
  node_k8s_ldap["LDAP manifests<br/>k8s manifests"]
  node_netpol["Network policies<br/>k8s policies"]
end

subgraph group_reference["Reference material"]
  node_readme["README<br/>project spec<br/>[README.md]"]
  node_docs["Docs"]
end

node_user(("User<br/>external actor"))

node_user -->|"uses"| node_app
node_app -->|"authenticates"| node_ldap
node_app -->|"reads location"| node_sqlserver
node_app -->|"reads hardware"| node_mongodb
node_k8s_frontend -.->|"deploys"| node_app
node_k8s_sqlserver -.->|"deploys"| node_sqlserver
node_k8s_mongodb -.->|"deploys"| node_mongodb
node_k8s_ldap -.->|"deploys"| node_ldap
node_netpol -.->|"restricts"| node_app
node_netpol -.->|"restricts"| node_sqlserver
node_netpol -.->|"restricts"| node_mongodb
node_netpol -.->|"restricts"| node_ldap
node_readme -.->|"describes"| node_app
node_readme -.->|"describes"| node_sqlserver
node_readme -.->|"describes"| node_mongodb
node_readme -.->|"describes"| node_ldap
node_docs -.->|"supports"| node_readme

click node_app "https://github.com/carlamndz/inventarioitu/tree/main/app"
click node_sqlserver "https://github.com/carlamndz/inventarioitu/tree/main/db/sqlserver"
click node_mongodb "https://github.com/carlamndz/inventarioitu/tree/main/db/mongodb"
click node_ldap "https://github.com/carlamndz/inventarioitu/tree/main/ldap"
click node_k8s_frontend "https://github.com/carlamndz/inventarioitu/tree/main/k8s/frontend"
click node_k8s_sqlserver "https://github.com/carlamndz/inventarioitu/tree/main/k8s/sqlserver"
click node_k8s_mongodb "https://github.com/carlamndz/inventarioitu/tree/main/k8s/mongodb"
click node_k8s_ldap "https://github.com/carlamndz/inventarioitu/tree/main/k8s/ldap"
click node_netpol "https://github.com/carlamndz/inventarioitu/tree/main/k8s/network-policies"
click node_readme "https://github.com/carlamndz/inventarioitu/blob/main/README.md"
click node_docs "https://github.com/carlamndz/inventarioitu/tree/main/docs"

classDef toneNeutral fill:#f8fafc,stroke:#334155,stroke-width:1.5px,color:#0f172a
classDef toneBlue fill:#dbeafe,stroke:#2563eb,stroke-width:1.5px,color:#172554
classDef toneAmber fill:#fef3c7,stroke:#d97706,stroke-width:1.5px,color:#78350f
classDef toneMint fill:#dcfce7,stroke:#16a34a,stroke-width:1.5px,color:#14532d
classDef toneRose fill:#ffe4e6,stroke:#e11d48,stroke-width:1.5px,color:#881337
classDef toneIndigo fill:#e0e7ff,stroke:#4f46e5,stroke-width:1.5px,color:#312e81
classDef toneTeal fill:#ccfbf1,stroke:#0f766e,stroke-width:1.5px,color:#134e4a
class node_app,node_sqlserver,node_mongodb,node_ldap toneBlue
class node_k8s_frontend,node_k8s_sqlserver,node_k8s_mongodb,node_k8s_ldap,node_netpol toneAmber
class node_readme,node_docs toneMint
class node_user toneNeutral
```

## Components

### Runtime services

User-facing app, identity, and the two separated data stores.

- [inventario-web](https://github.com/carlamndz/inventarioitu/tree/main/app): Node.js app · Express application that serves as the central entry point for inventory queries. · `app`
- [Location DB](https://github.com/carlamndz/inventarioitu/tree/main/db/sqlserver): SQL Server · Relational store for location and assignment data. · `db/sqlserver`
- [Inventory DB](https://github.com/carlamndz/inventarioitu/tree/main/db/mongodb): MongoDB · Document store for hardware and component inventory details. · `db/mongodb`
- [LDAP service](https://github.com/carlamndz/inventarioitu/tree/main/ldap): OpenLDAP · Identity subsystem used for authentication and directory lookups. · `ldap`

### Kubernetes deployment

Manifests and network policy scaffolding for isolated workloads.

- [Frontend manifests](https://github.com/carlamndz/inventarioitu/tree/main/k8s/frontend): k8s manifests · Kubernetes deployment assets for the web application. · `k8s/frontend`
- [SQL manifests](https://github.com/carlamndz/inventarioitu/tree/main/k8s/sqlserver): k8s manifests · Kubernetes deployment assets for the SQL Server workload. · `k8s/sqlserver`
- [Mongo manifests](https://github.com/carlamndz/inventarioitu/tree/main/k8s/mongodb): k8s manifests · Kubernetes deployment assets for the MongoDB workload. · `k8s/mongodb`
- [LDAP manifests](https://github.com/carlamndz/inventarioitu/tree/main/k8s/ldap): k8s manifests · Kubernetes deployment assets for the LDAP workload. · `k8s/ldap`
- [Network policies](https://github.com/carlamndz/inventarioitu/tree/main/k8s/network-policies): k8s policies · Traffic segmentation rules controlling east-west access between workloads. · `k8s/network-policies`

### Reference material

Repository documentation and supporting notes.

- [README](https://github.com/carlamndz/inventarioitu/blob/main/README.md): project spec · Primary narrative for the intended architecture and deployment model. · `README.md`
- [Docs](https://github.com/carlamndz/inventarioitu/tree/main/docs): supporting docs · Placeholder area for supplementary documentation and diagrams. · `docs`

### Other components

- **User**: external actor · Person accessing the inventory system.

## Connections

- User → inventario-web: uses · End users reach the system through the web application.
- inventario-web → LDAP service: authenticates · Login and identity validation happen against LDAP/Active Directory.
- inventario-web → Location DB: reads location · The app queries relational inventory placement and assignment data.
- inventario-web → Inventory DB: reads hardware · The app queries document-based component and machine details.
- Frontend manifests → inventario-web: deploys · Kubernetes resources define the web application workload.
- SQL manifests → Location DB: deploys · Kubernetes resources define the SQL Server workload.
- Mongo manifests → Inventory DB: deploys · Kubernetes resources define the MongoDB workload.
- LDAP manifests → LDAP service: deploys · Kubernetes resources define the LDAP workload.
- Network policies → inventario-web: restricts · Network policies constrain access to the application workload.
- Network policies → Location DB: restricts · Network policies constrain access to the SQL Server workload.
- Network policies → Inventory DB: restricts · Network policies constrain access to the MongoDB workload.
- Network policies → LDAP service: restricts · Network policies constrain access to the LDAP workload.
- README → inventario-web: describes · The README defines the intended application architecture.
- README → Location DB: describes · The README documents the relational data boundary.
- README → Inventory DB: describes · The README documents the document-store data boundary.
- README → LDAP service: describes · The README documents the authentication boundary.
- Docs → README: supports · Documentation space complements the main system description.