cd ../case-studies
~/case-studies/logbook.md
Architectural Deep-Dive

LogBook

An enterprise academic LMS & educator workspace rebuilt from legacy PHP into a high-concurrency Go modular monolith backend on Microsoft Azure.

LogBook screenshot

title: "LogBook: Enterprise Academic LMS & Educator Workspace" excerpt: "How a 194-feature legacy PHP system evolved into a high-concurrency Go modular monolith backend deployed on Azure with a Next.js frontend." date: "Dec 2025 - Present" stage: "production" readTime: "9 min read" stack: ["Go (Golang)", "Next.js", "TypeScript", "PostgreSQL", "Microsoft Azure", "Chi Router", "JWT"] role: "Lead Systems Architect & Full-Stack Developer" liveUrl: "https://logbook.syedsystems.dev"

LogBook — Enterprise Architecture & Product Evolution

Architecture Overview: Designed as a multi-tenant, white-label Learning Management System (LMS) and educator workspace for university faculties. Features a high-performance Go (Golang 1.26+) modular monolith backend deployed on Microsoft Azure, paired with a Next.js 14 / TypeScript frontend.

LogBook Secure Command Center


1. What Problem Does LogBook Solve?

Academic administrative operations at universities are notoriously complex and resource-intensive:

  • Legacy Performance Bottlenecks: Traditional PHP/Moodle institutional portals crumble under concurrent user spikes during exam weeks or registration windows, consuming massive server RAM and CPU.
  • Complex Academic Workflows: Higher education requires strict compliance with BAETE / OBE (Outcome-Based Education) criteria, program outcomes (POs), course outcomes (COs), multi-section class routines, and grade scheme evaluations.
  • Weak Institutional Connectivity: Universities often operate on constrained internal networks or poor internet infrastructure, causing slow page loads and dropped requests when handling heavy data exports.

LogBook solves this by providing a unified, high-concurrency platform that automates attendance tracking, gradebook math, course routine scheduling, Google Classroom sync, and OBE reporting with minimal server overhead.


2. Societal Impact, User Count, & Product Positioning

Product Positioning

LogBook is positioned as an Enterprise Educator Workspace & Institution LMS. It is engineered for dual deployment:

  1. Multi-Tenant SaaS Cloud: Multi-tenant architecture (org_id isolation) hosted on Microsoft Azure for cloud-based university subscriptions.
  2. Single Binary On-Premise: Can be compiled into a single ~17MB executable for on-premise deployment on air-gapped university servers.

LogBook Platform Coverage & Feature Capabilities

Impact & Benefits

  • For Professors & Faculty: Zero operational friction. They get an intuitive, fast Next.js workspace for grade entry, roster management, and routine tracking without caring about underlying server complexity.
  • For Universities: Saves thousands of dollars in server infrastructure costs while ensuring zero downtime during peak grading periods.
  • For Students: Seamless login with Google Classroom integration and transparent academic tracking.

3. Tech Stack

  • Backend: Go 1.26+ (Modular Monolith)
    • go-chi/chi/v5 (Lightweight idiomatic HTTP router)
    • jackc/pgx/v5 (High-performance PostgreSQL connection pool)
    • golang-jwt/jwt/v5 (Stateless JWT authentication)
    • rs/zerolog (Structured JSON logging)
  • Frontend: Next.js 14 (App Router), TypeScript, TailwindCSS
  • Database: PostgreSQL (with org_id multi-tenancy and optimized indexes)
  • Cloud & Hosting: Microsoft Azure (utilizing Azure student license credits for zero-cost high-performance hosting)

4. Tech Stack Justification & Product Evolution

The Evolution: PHP/Moodle → Next.js BaaS → Go Modular Monolith

  1. Phase 1 (Legacy PHP/Moodle): The original legacy system (LogBook Institute) contained 190+ features, but suffered from terrible concurrency and speed under load. PHP-FPM required heavy server resources (Nginx/Apache + PHP workers), crashing under peak faculty load.
  2. Phase 2 (Next.js/Supabase BaaS Experiment): We experimented with a TypeScript/Supabase stack (Logbook V1.1). While great for rapid prototyping, relying entirely on serverless functions and client-side BaaS wrappers created execution limits for heavy backend data processing.
  3. Phase 3 (Current Production - Go + Next.js): We made the strategic architectural decision to rewrite the backend in Go (Golang).

Why Go for Backend? (The Developer & Architect Perspective)

  • Unmatched Concurrency & Low Resource Usage: Go compiles down to a tiny ~17MB single binary. Go's goroutines handle thousands of concurrent API requests using minimal RAM (a few megabytes) and CPU, compared to hundreds of megabytes required by Node.js or PHP processes.
  • Resilience Under Low Bandwidth: In educational institutions with weak or spotty internet, Go's high-speed data processing ensures requests are served in milliseconds, preventing timeout errors under congested network conditions.
  • Azure Cloud Cost Efficiency: From a developer and founder perspective, Go's ultra-low resource footprint allows hosting the entire production backend on Microsoft Azure using Azure student license credits. It delivers enterprise-grade performance without breaking the bank.

5. Future Plan & Strategic Roadmap

  • Pilot University Rollout: Onboarding the first pilot university customer onto the Go + Azure infrastructure.
  • BAETE / OBE Automated Analytics: Expanding outcome-based education mapping (PO/CO attainment charts) to provide automated institutional accreditation reports.
  • Hybrid Sync: Enabling instantaneous sync between on-premise local campus installations and the Microsoft Azure cloud SaaS.