Banco Limen
Limen is Latin for threshold: the space between what was and what could be.
Banco Limen is a fictional, composite retail bank. It is a controlled Phase 1 reconstruction of generalized failure patterns from regulated production — not an employer system, source codebase, or data set. The app is the pretext; the infrastructure around it, and the reasoning behind its eventual repair is the point.
Current status: Phase 1 is in progress. The stack deliberately exposes legacy anti-patterns so they can be inspected before later phases address them. This is not a finished cloud-native case study.
The current Phase 1 architecture
All components share one flat Docker bridge network. That lack of segmentation is intentional: it is part of the system being examined.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Banco Limen / Phase 1
Client
│ :5001
▼
Flask application (:5000) ───────────────► PostgreSQL 12
│ exposes /metrics │
│ │
├──── Prometheus scrapes ────────────────────┘
│ │
│ ├────► Grafana reads metrics
│ ├────► node-exporter (running)
│ └────► postgres-exporter + legacy VMs (configured, absent)
│
├────► Elasticsearch ◄──── Kibana
│ (no retention) (stale dashboards)
│
└────► Jaeger
installed, but the application emits no spans
All services: one flat limen-network bridge
The architecture is intentionally inconsistent: Prometheus, ELK, and Jaeger coexist without useful correlation; the database has no replica; several scrape targets do not exist; and a compromised service can reach every component on the flat network.
What to inspect
- Problem inventory — 38 documented failure patterns.
- Phase 1 design — the current stack and the anti-patterns it reproduces.
- Architecture Decision Records — why each deliberate decision exists in Phase 1.
- The Limen repository — source, current roadmap, and the preserved Phase 1 baseline.