// saiful alom

© 2026. All rights reserved.

BLOG POST

How I Design and Build Systems: From Monoliths to the Edge

Illustration showing a transition from a messy monolithic system to a clean modular architecture.
3 min read

The Architectural Evolution: A Structural Deep Dive

To understand how I build systems today, we have to look at the structure. Below is the “Tree” view of my transition from a traditional MERN Monolith to a modern, Edge-Native Modular system.

1. The Legacy Architecture (BazarBhai)

This follows the classic Layered Monolith pattern. Logic is separated by technical function (all models together, all routes together).

bazarbhai-backend/ (The Monolith)
├── src/
│   ├── config/             # Environment-specific settings
│   ├── models/             # Data definitions (MongoDB schemas)
│   │   ├── userModel.js
│   │   └── productModel.js
│   ├── routes/             # API Endpoints
│   │   ├── userRoutes.js
│   │   └── productRoutes.js
│   ├── middleware/         # Security & Auth (Global)
│   │   └── checkAuth.js
│   └── helper/             # Business Logic (Scattered)
│       ├── order/          # Logic detached from the API layer
│       └── products/
└── server.js               # Central point of failure

The Flaw: As this grows, it becomes “Spaghetti Code.” If you change a field in userModel.js, you have to manually search every file in helper/ and routes/ to make sure it doesn’t break. There is no automatic safety.


2. The Modern Architecture (TrackFlow)

This follows the Modular Edge-Native pattern. Logic is separated by feature (everything about ‘Events’ is in one folder).

trackflow-backend/ (The Modular Edge)
├── src/
│   ├── app/                # Application "Bootstrap"
│   │   ├── register-routes.ts
│   │   └── create-app.ts
│   ├── db/                 # The "Source of Truth"
│   │   └── schema/         # Drizzle Schemas (SQL)
│   │       ├── user.ts
│   │       └── event.ts
│   ├── modules/            # Domain-Driven Modules
│   │   ├── event/          # Fully self-contained feature
│   │   │   ├── event.routes.ts     # Definition
│   │   │   ├── event.schema.ts     # Validation (Zod)
│   │   │   ├── event.controller.ts # Orchestration
│   │   │   └── event.service.ts    # Business Logic
│   │   └── site/
│   ├── queue.ts            # Background Worker (Edge-Native)
│   └── index.ts            # Global Edge Entry Point
├── wrangler.jsonc          # Cloudflare Infrastructure Config
└── drizzle.config.ts       # Database Migration Config

The Strength: This is Type-Safe.

  • If I change the event.ts database schema, TypeScript immediately shows me errors in event.service.ts.
  • OpenAPI Integration: The structure in modules/ allows me to auto-generate documentation.

Comparison: Why I Switched

Feature BazarBhai (Old) TrackFlow (New)
Logic Placement Scattered across helper/ and routes/ Encapsulated in modules/[feature]/
Data Validation Manual checks inside functions Automatic via Zod-OpenAPI
Deployment Single Server (Limited) Edge Network (Global/Cloudflare)
DB Handling Non-relational (Risky data drift) Relational SQL (Drizzle ORM)

Summary of my Design Goal

I design for predictability. By using a modular tree structure like the one in TrackFlow, I ensure that a client’s system is easy to upgrade, impossible to “break” by accident, and runs with zero latency on the edge.