FINANCIAL DATA · FULL-STACK PRODUCT

Trade Journal

From raw executions to a clearer trading picture.

Overview

A trading analytics platform that transforms broker executions into structured positions, P&L analytics, and actionable trading insights.

Java 17Spring BootAngularMySQLJWT

The problem

Broker exports describe individual executions. A useful journal needs coherent positions, realized outcomes, and the decisions behind each trade. Partial closes and inconsistent input make that translation more than a simple import.

The solution

A structured processing pipeline cleans imported CSV/Excel executions, matches them into open and closed positions, and feeds analytics alongside trade plans, risk/reward tracking, notes, and psychology review.

Architecture & data flow

An Angular frontend connects to a Java 17 and Spring Boot modular monolith through REST APIs. The backend separates authentication, ingestion, trade processing, and analytics responsibilities, with MySQL persistence.

Trade Journal · conceptual architecture
  1. 01CSV / Excel + manual entry
  2. 02Clean & normalize
  3. 03FIFO position matching
  4. 04P&L & risk metrics
  5. 05Analytics & review

The engineering challenge

Reconstructing positions from partial fills and FIFO execution matching.

Key features

  • Broker CSV/Excel import and manual trade entry
  • Execution cleaning, duplicate detection, and normalization
  • FIFO matching, partial closes, and weighted exit prices
  • Realized P&L, equity curves, and performance analytics
  • Asset, strategy, and day-based performance analysis
  • Risk metrics, trade planning, and risk/reward tracking
  • Mistake tracking, notes, and trading psychology review
  • Authentication, authorization, and administration

Design decisions

  • Use a modular monolith to keep domain boundaries explicit without distributed deployment overhead.
  • Separate imported executions from derived positions so the domain model reflects how trades develop.
  • Keep calculations in the backend so analytics and the interface share one interpretation of outcomes.

Performance considerations

Areas to evaluate as the workload grows; no benchmark results are claimed.

  • Treat repeat imports, partial fills, and chronological ordering as correctness concerns before optimizing throughput.
  • Review database access patterns and paginate historical records as the dataset grows.
  • Measure calculation cost before introducing precomputed summaries; cached analytics need explicit invalidation.

Security boundaries

Spring Security and JWT support authenticated access and authorization. Trade records and import operations need ownership checks at the API boundary. File validation, upload limits, and careful handling of broker data are important review areas.

A look at the product

Trade Journal · workspace

Actual product capture to be added

Trade Journal · workspace
Reserved for an actual screenshot. No mock product data.

What I learned

The central engineering lesson is that the data model determines the quality of the analytics. Executions, positions, and trading decisions each need a clear place in the system. Correctness and explainable calculations come before a polished chart.

Explore the source on GitHub ↗

HAVE SOMETHING IN MIND?

Let’s build
something useful.

Engineering roles, interesting problems, or a good technical conversation.