This case study presents the architecture and functional design of a multi-station fuel stock management system.
My role focused on clarifying complex business requirements, identifying the true domain core, and designing a system structure that development teams can confidently implement and extend over time.
The work emphasizes system thinking, clean data flows, and long-term scalability rather than feature-level implementation.
2. Context & Problem
The client required a centralized back-office system to manage fuel operations across multiple stations.
Key challenges included:
Requirements were incomplete and evolving
Operations spanned multiple stations, tanks, and daily processes
Inventory accuracy and auditability were business-critical
The system needed to support an MVP first, with full inventory logic introduced later
Without a clear domain core, the system risked becoming busy but conceptually fragmented.
3. My Role
Role: System Architect & Backend Consultant
I worked directly with the client to:
Define the end-to-end business flow
Identify the system’s true domain core
Design data models and system boundaries
Establish a phase-based delivery strategy (Phase 1 vs Phase 2)
Produce architecture documentation usable by both technical and non-technical stakeholders
This role focused on direction, structure, and clarity — not feature-level coding.
4. Core Business Flow
The system is structured around a clear operational flow:
Purchase Order (PO) → Goods Received Voucher (GRV) → Daily Tank & Pump Readings
This flow represents how fuel moves from planning to physical delivery and daily consumption, forming the backbone of all future inventory calculations.
All modules and future extensions are designed around this core flow.
5. Key Design Decisions
5.1 Tank-Level Allocation
Fuel deliveries are allocated at the tank level.
GRV records the receipt event
Tank Allocation models where fuel physically goes
Enables accurate inventory modeling and future stock movements
This design reflects real-world station operations and supports future scalability.
5.2 Stock Movement as the Inventory Core (Phase 2)
Inventory is modeled using a unified Stock Movement concept.
Deliveries, sales, adjustments, and losses share the same movement model
Becomes the single source of truth for inventory
Enables auditability, reconciliation, and reporting
This approach avoids fragmented inventory logic across multiple tables.
5.3 Operating Day & Accounting Period
The system introduces a clear time-governance model:
Operating Day runs from 06:00 to 06:00
Provides a consistent boundary for readings, variance, and locking
Accounting Period groups operating days for reporting and closing
This design supports operational accuracy, auditability, and future financial reporting.
6. Phase-Based Delivery Strategy
To reduce risk and allow incremental delivery, the system was intentionally designed in phases.
Phase 1
PO and GRV workflows
Daily tank and pump readings
Clear role boundaries and data capture
Phase 2
Inventory calculations
Variance analysis
Period locking and reporting
This ensured early usability while keeping the long-term architecture clean and extensible.
7. Outcome
The result was:
A clear, buildable system architecture
Shared understanding across technical and non-technical stakeholders
Documentation that directly guided development work
A stable foundation for future inventory and reporting features
The architecture document became the reference point for subsequent development.
8. Confidentiality Note
All business details have been anonymized.
This case study focuses on system thinking and architectural approach rather than client-specific implementation details.
9. Closing
This case study reflects how I approach complex systems:
identify the domain core first, then design everything else around it.
Like this project
Posted Dec 17, 2025
Designed a scalable system architecture for a multi-station fuel stock platform, focusing on clear data flows and long-term inventory scalability.