Skip to content
All Projects
Stock market simulation trading interface
University of Groningen··Academic·coursework

Stock Market Simulation

Built a modular Java stock-market simulator where 25 autonomous bots trade 11 stocks through a client-server message queue, with a live browser dashboard for market and portfolio data.

systemsconcurrencyvisualization
  • ▸Seven-module Maven architecture separating commands, networking, the message queue, stock domain objects, trader and exchange applications, and UI
  • ▸Thread-safe BlockingQueue and observer pattern connect the client-server trading applications without tightly coupling them
  • ▸25 autonomous bots use the implemented RandomChoiceStrategy to trade 11 stocks
  • ▸Browser dashboard tracks traders, portfolios, stock prices, and market performance
Stack
JavaMavenDockerHTTP
RoleTeam member
Team2 people
Source Code

Overview

A modular stock-market simulation built in Java 17 with Konstantinos Chasiotis for the University of Groningen's Advanced Object-Oriented Programming course. The application separates the stock exchange, trader bots, networking, shared domain models, and browser UI into independently buildable Maven modules.

7

Maven modules

25

Trader bots

11

Stocks

3

Design patterns

What I Built

  • Client-server networking with a separate handler for each connected client
  • A thread-safe BlockingQueue for passing buy and sell commands between applications
  • 25 autonomous trader bots using the implemented RandomChoiceStrategy across 11 stocks, with a strategy interface designed for additional implementations
  • A browser dashboard for live trader, portfolio, stock-price, and market-performance views
  • Docker Compose configuration for running the exchange and trader applications together

Technical Details

The system uses Command, Observer, and Factory patterns to keep the modules independent. A property-change listener wakes the stock exchange when the thread-safe message queue receives an order, avoiding continuous polling. The repository's evaluation also records an important limitation: orders are processed sequentially, and parallel extraction plus explicit locking was identified as future work rather than implemented functionality.

What I Learned

This project made modular design concrete: shared interfaces and domain objects can connect independently deployable applications without making them depend on each other's implementations. It also showed the difference between using a thread-safe communication primitive and making an entire processing pipeline concurrent: the queue supports concurrent access, while order execution remains deliberately sequential.