MLB The Show Marketplace Forecaster
Repo
UI Repo
Docs
UI Docs
dotnet react postgresql mongodb rabbitmq docker github actions aws

What is it?

MLB The Show Marketplace Forecaster is an application that uses an MLB Player’s real-world performance to predict the price of their card in MLB The Show.

What is MLB The Show?

MLB The Show is a baseball video game that allows users to create custom teams with real-life players to play against other teams. Think along the lines of fantasy leagues, but you actually control your players.

In order to form your team, you need to collect in-game baseball cards that represent real-life players. To earn cards, you play baseball games to earn an in-game currency called “stubs”. You then use stubs to either purchase a pack of randomized cards or use the in-game marketplace to buy cards from other users or sell your own. Of course, you can also use real money to purchase stubs (it’s the business model after all).

A card’s performance in-game is based on the actual player’s real-life performance in the MLB. So a more performant player will likely get better “stats” and draw a higher price in the market. The purpose of this forecaster is to then look for these trends and display them to the user.

How does it work?

The application monitors a player, their performance, and their corresponding card in MLB The Show. All relevant data for a player is combined to create a comparison between a player’s real-world performance and the marketplace performance of their card in MLB The Show.

Architecture

Primarily following DDD principles, each domain is split into its own microservice. They communicate using a message broker for events or APIs when on-demand data is needed. The microservices are deployed as containers into their own virtual network and are not accessible publicly. A separate, auth-protected gateway app then exposes only what needs public access to a SPA. The end user authenticates via the SPA and is able to start jobs and view player reports.

What design patterns are used?

  • Domain driven design - A logical boundary was set up around any area that would be expanded on
  • Event message broker - Notifies subscribing domains when something important happens
  • CQRS Mediator - Enforces a strict set of rules on the logic of the write and read process, but loose coupling between the (command) sender and (query) receiver
  • Job system - Work only needs to be done on a schedule

What are the domains?

  • PlayerStatus - The value of a player is determined by whether a player is active or not. This track’s a player’s status and will notify the system upon any changes.
  • Performance - A player must not only play, but their value also scales with their performance. This track’s a player’s stats and notifies the system when there are improvements or declines.
  • GameCards - The player’s in-game card representation has both attributes that influence its ability and a price that is directly tied to its demand. This tracks a player’s card’s value and notifies the system on any changes to ability or cost.

What does each layer in a domain do?

  • Domain - Defines domain/business logic, events, and objects – the core of the domain and is always dependency-agnostic
  • Application - Services and contracts that define how each component of the program interact with each other
  • Infrastructure - Implementations of any contracts that rely on external dependencies

End-to-end example of a microservice in the system

In the Performance.Domain layer, we define PlayerSeason that represents a player’s stats throughout a given season. We allow this entity to be mutable by appending individual game stats as the year progresses, and then allowing it to assess the performance against the business rules. Any significant change will publish a domain event.

The Performance.Application layer orchestrates how those PlayerSeasons get into the system using a service called IPerformanceTracker. Its implementation is defined directly in the application layer because its only dependencies are other contracts like itself. The basic logic of the service is to:

  1. Get stats for all active players in the season
  2. PlayerSeason entity is created or its stats are updated and a persist command is sent to a mediator
  3. Persist changes
  4. Assess the stats
  5. Publish a domain event if there is an improvement or decline
  6. The published event is consumed by the GameCards domain and updates the price forecast of the corresponding player card

To get all stats for players, it relies on the contract IPlayerStats. Unlike the IPerformanceTracker, the implementation does not reside in the Application layer since it relies on external data.

In comes the Performance.Infrastructure layer to define the implementation. This data needs to come from the MLB API and the Infrastructure layer is where we add those external dependencies.

MLB The Show Forecaster end-to-end microservice example

Technologies

It is built with:

  • .NET
    • ASP.NET Core microservices
    • SignalR/Websockets (real-time updates for UI)
  • React + Vite (UI repo)
  • PostgreSQL operational db
  • MongoDB reporting db (for front-end consumption)
  • RabbitMQ message broker

Infrastructure

All the .NET apps are containerized and deployed to AWS Elastic Container Service via a Github Actions CD pipeline. The microservices live in their own VPC, with no public access. The gateway app provides access to these microservices via a load balancer that handles all incoming traffic. Authentication is handled with AWS Cognito.

  • Docker
  • GitHub Actions (CI/CD)
  • AWS
    • VPC
    • ECS
    • Cognito

MLB The Show Forecaster infrastructure

VPC

All running instances are placed in a VPC which is split into:

  • Private Subnet - Isolated from public access, but can communicate with each other
  • Public Subnet - Accessible to the public and also has access to the Private Subnet

The domain apps are in the private subnet while the gateway app is in the public subnet. This means no one but the gateway app can access the domain services – and can do so using only the actions defined in the app itself.

Security groups

The access rules are below. Note that access between groups is only over the specific port that is required, not all ports.

  • Private - private domain apps
    • Accessible by: Private, PrivateAccess
    • Access to: Private
  • PrivateAccess - for something in public that needs access to private
    • Accessible by: None
    • Access To: Private
  • Public - gateway app
    • Accessible by: LoadBalancer
    • Access To: None
  • LoadBalancer - handles traffic to the gateway
    • Accessible by: Internet (over ports 80 or 443)
    • Access To: Public

Load Balancer

The load balancer is the entry point to the application. It only accepts HTTPS traffic so the encryption/decryption overhead is offloaded here and downstream HTTP is used. It also has a health check that will ping the gateway app to ensure it is active.

Elastic Container Service

All apps have their own Dockerfile which are built in the CD pipeline upon a release. ECS will then pick up these as task definitions and deploy them as services.

UI

The UI is built in React + Vite and its repository is separate. The release pipeline for the UI publishes the React build files and the ASP.NET Core app then loads these as static files.