IGT Play Command

Player Management Platform – Knowledge Transfer, Architecture & Module Guide

Java 11 • Spring Boot • Microservices • REST • Event Driven • PostgreSQL • Solr • Security

1. Project Overview

Play Command is a complete player-management solution for Lottery products. It is a high-performance and scalable digital solution designed to manage player-centric functions and game enablement within iLottery programs.

The solution follows a modular microservices architecture and supports player account management, wallet management, game administration, back-office administration, network integrations and external-system communication.

Microservices Modular Architecture
```
Java 11 Backend Platform
PostgreSQL Primary Database
Jenkins CI/CD Automation
```

Player Management

Player-centric account and lifecycle management capabilities.

Wallet Management

Wallet-related operations and transaction processing.

Game Enablement

Game administration and game-related business capabilities.

Back Office

Administrative functions and operational management.

Integrations

Integration with external systems and services.

Observability

Monitoring, logging, alerting and performance analysis.

2. High-Level Architecture – Updated Module View

Architecture principle: The supplied architecture shows the Portal as the player-facing UI trigger point, Control as the BackUserPortal entry point, GOV as the governance layer and ORC as the central coordinator/orchestrator. Internally, modules communicate through REST Services, while JMB provides event-driven messaging through its router.xml and event_type_id-based routing model.
Updated IGT Play Command architecture Portal and Back Office entry points connect through security and governance to the central ORC orchestrator. JMB handles event-driven messaging and routes events to business modules. Internal modules communicate through REST services. OAuth, Proxy-OAuth, Solr and delivery templates are supporting components. ENTRY POINTS ORCHESTRATION & MESSAGING BUSINESS & SUPPORT MODULES PORTAL Actual UI trigger point Player perspective CONTROL BackUserPortal Back-office entry point PROXY-OAUTH Security boundary OAUTH AuthN / AuthZ GOV Governance Back-office control flow ORC Central Coordinator ORCHESTRATOR Coordinates module flows JMB Messaging Bean Event Driven router.xml • event_type_id Routes events to subscribed modules CORE MODULES BBM Bonus Bag Mgmt CMO Consent Mgmt CMP Campaign Mgmt DLV Notifications EWL Wallets LOY Loyalty LRT Long Run Tasks ONP One Payment GAD/GADM Game Admin RGL Responsible Gaming UMS/SMS User Management THP Tax & Txn Processing TSO Txn Orchestrator GCS Module SOLR Search / Indexing DLV Delivery Runtime DLV TEMPLATE Notification templates OAuth / PROXY-OAUTH Security components GCS Supporting module INTERNAL MODULE COMMUNICATION REST Services between modules • Event-driven communication through JMB
Security / OAuth Orchestration / REST Event-driven / Messaging Business modules

The diagram is an updated, clean HTML/SVG representation of the supplied ProjectArchitecture diagram. It keeps the original concepts—Portal, Control, GOV, ORC, JMB, module ecosystem and internal REST communication— while adding the module names and responsibilities provided for this KT document.

Key Architecture Interaction Patterns

PatternExplanationPrimary Components
UI / Player FlowPortal is the actual UI trigger point for player-facing operations.PORTAL → Security → ORC / modules
Back-office FlowControl represents the BackUserPortal entry point and feeds governance processing.CONTROL → GOV → ORC
Central OrchestrationORC acts as the central coordinator/orchestrator for module-level processing.ORC → Business Modules
Internal RESTOne module communicates with another module through REST Services.Module ↔ Module
Event DrivenJMB handles messaging and routes events using router.xml and event_type_id.JMB → Event Consumers
SecurityOAuth and Proxy-OAuth are positioned as security/authentication components.Proxy-OAuth / OAuth

3. Major Modules 23 Modules / Components

The following module names and responsibilities are based on the module information supplied for this document. Where a detailed responsibility was not provided, it is explicitly marked rather than inferred.

Entry Points, Governance & Orchestration

ModulePurposeKey Responsibilities
PORTALActual UI trigger pointActual UI trigger point; player-facing entry point.
JMBMessaging BeanMessaging Bean; event-driven routing using router.xml and event_type_id.
ControlBackUserPortalBackUserPortal / back-office entry point.
GOVGovernanceGovernance and control-related processing.
ORCCentral coordinator / OrchestratorCentral coordinator / orchestrator for module flows.
BBMBonus Bag ManagementBonus Bag Management.
CMOConsent Management OrchestratorConsent Management Orchestrator.
CMPCampaign ManagementCampaign Management.
DLVDelivery Module (SMS, Email, Push Notifications)Delivery of SMS, Email and Push Notifications.
EWLWalletsWallet-related functionality.
LOYLoyaltyLoyalty-related functionality.
LRTLong Run TasksLong Run Tasks.
ONPOne PaymentOne Payment functionality.
GAD/GADMGame AdminGame administration functionality.
RGLResponsible Gaming LimitsResponsible Gaming Limits.
UMS/SMSUser Management SystemUser Management System.
THPTax and Transaction ProcessingTax and Transaction Processing.
TSOTransaction System OrchestratorTransaction System Orchestrator.
GCSPurpose not specified in the supplied module information.Supporting module; detailed responsibility was not specified in the supplied information.
SolrSearch / indexingSearch and indexing component.
DLV TemplateDelivery templatesDelivery notification templates.
OAuthAuthentication / authorizationAuthentication / authorization component.
Proxy-OAuthOAuth proxy / security boundaryOAuth proxy / security boundary.

Module Interaction Summary

PORTAL

Actual UI trigger point. Represents the player-facing starting point for UI-driven operations.

CONTROL

BackUserPortal. Represents the back-office interaction path.

GOV

Governance. Handles governance/control-related processing before orchestration.

ORC

Central Coordinator / Orchestrator. Coordinates requests and module interactions.

JMB

Messaging Bean. Supports event-driven communication and routing using router.xml and event_type_id.

DLV

Delivery Module. Handles notification delivery such as SMS, Email and Push Notifications.

TSO / THP

Transaction processing path. TSO represents Transaction System Orchestrator and THP represents Tax and Transaction Processing.

UMS/SMS

User Management System. User management capability as supplied.

Module Communication Model

PORTAL
→
Security
→
ORC
→
Business Modules
CONTROL
→
GOV
→
ORC
→
Business Modules
JMB
→
router.xml
→
event_type_id
→
Event Consumers

Internal communication: As specified in the supplied architecture, one module communicates with another module through REST Services. JMB provides the event-driven messaging path.

4A. Module Communication & Processing Flow

Player / UI Trigger Flow

PORTAL
→
Proxy-OAuth
→
OAuth
→
ORC
→
Target Module

Back-office Flow

CONTROL
→
GOV
→
ORC
→
Target Module

Event-driven Flow

Source Event
→
JMB
→
router.xml
→
event_type_id
→
Consumer Module

Internal REST Communication

Module A
⇄ REST ⇄
Module B
⇄ REST ⇄
Module C
KT statement: “The Portal is the actual UI trigger point. Back-office operations enter through Control/BackUserPortal and Governance. ORC acts as the central coordinator. Modules can communicate internally through REST Services, while JMB provides event-driven communication using router.xml and event_type_id-based routing.”

4. Technology Stack

Backend

Java 11 Spring Boot REST JPA Hibernate

Database

PostgreSQL Liquibase SQL

Messaging

Apache Camel JMS Async Processing

Scheduling

Quartz Scheduler Batch Jobs

Search

Apache Solr Full Text Search Indexing

DevOps

Git GitHub Jenkins Maven

Testing

JUnit Postman Swagger SOAP UI

Observability

Grafana New Relic VisualVM

Resilience

Resilience4j Hystrix Circuit Breaker

5. Microservices Development

The application is developed using independently deployable Spring Boot microservices. Each service contains its own API, business logic, persistence, configuration, testing and operational concerns.

REST Controller
→
Service Layer
→
Business Logic
→
Repository
→
PostgreSQL

6. REST API Development

HTTP Operations

Method Purpose
GETRetrieve information
POSTCreate a resource
PUTUpdate a resource
PATCHPartially update a resource
DELETEDelete a resource

API Development Checklist

  • Request validation
  • Business validation
  • Authentication and authorization
  • Correct HTTP status codes
  • Exception handling
  • Logging and correlation ID
  • Swagger/OpenAPI documentation
  • Unit and integration tests
  • Backward compatibility

7. Apache Camel & JMS

Apache Camel is used for integration, routing, transformation and message-processing requirements.

Source System
→
Camel Route
→
Validate
→
Transform
→
Target Service

JMS Flow

Producer
→
JMS Queue
→
Consumer
→
Business Processing
Benefits: asynchronous processing, loose coupling, better scalability, fault isolation and improved handling of high-volume workloads.

8. Quartz Scheduler

Quartz Scheduler is used for automated and recurring jobs, including batch processing, data synchronization, notifications and production scheduled activities.

Quartz Trigger
→
Job
→
Business Service
→
Database / External System

Production Schedule Change

  • Identify the Quartz job.
  • Verify current schedule.
  • Update required script/configuration.
  • Validate the change.
  • Deploy.
  • Monitor job execution.
  • Verify logs and business results.

9. PostgreSQL & Hibernate

PostgreSQL is used as the primary relational database. JPA and Hibernate provide the persistence layer.

Java Entity
→
JPA
→
Hibernate
→
SQL
→
PostgreSQL

Performance Optimization

  • SQL query optimization
  • Index optimization
  • Schema design
  • Pagination
  • Connection pool tuning
  • Transaction optimization
  • Query execution plan analysis
  • Avoid unnecessary database calls

10. Liquibase Database Migration

Liquibase manages database schema and data changes in a controlled, versioned manner.

ChangeSet
→
GitHub
→
Jenkins
→
Liquibase
→
PostgreSQL

Common Liquibase Issues

  • Invalid SQL
  • ChangeSet already executed
  • Incorrect change-set ordering
  • Database connection issues
  • Missing dependency
  • Constraint conflicts
  • Schema mismatch
Night Build Support: Liquibase-related database change-set failures are a common area to investigate when installation or Jenkins night builds fail.

11. Apache Solr

Apache Solr provides search indexing and full-text search capabilities and integrates with business services.

Application
→
Business Service
→
Solr Client
→
Solr Index

Typical Use Cases

  • Full-text search
  • Fast retrieval
  • Search filtering
  • Large dataset searching
  • Business-service search integration

12. API Gateway & Security

Client
→
API Gateway
→
Authentication
→
Authorization
→
Microservice

Gateway Responsibilities

  • Request routing
  • Authentication
  • Authorization
  • Request filtering
  • Rate limiting where applicable
  • Circuit breaking
  • Security enforcement
  • Centralized monitoring

13. Circuit Breaker & Resilience

CLOSED
→
Failure Threshold
→
OPEN
→
Wait
→
HALF-OPEN
Pattern Purpose
Circuit Breaker Prevent repeated calls to an unhealthy dependency.
Retry Retry transient failures.
Timeout Prevent requests from waiting indefinitely.
Fallback Provide an alternative response where applicable.

Technologies/patterns include Resilience4j and legacy Hystrix implementations where applicable.

14. Testing Strategy

JUnit

Unit testing for business logic, services, validation and exception scenarios.

Integration Testing

Validates interactions between application components, databases and integrations.

Postman

REST API request and response validation.

Swagger

API documentation and API-level testing.

SOAP UI

Testing SOAP-based services where applicable.

Code Coverage

Maven-based coverage reports identify gaps in automated tests.

Testing Flow

Development
→
Unit Test
→
Integration Test
→
API Test
→
Coverage

15. GitHub Branching & PR Process

Feature / Enabler Story

Current Branch
→
Feature Branch
→
Development
→
Tests
→
PR
→
Review
→
Merge

Hotfix Process

Production Tag
→
Hotfix Branch
→
Fix
→
Release
→
Backport
→
Development Branch
Important: Production fixes are backported to the appropriate current development branch so the fix is not lost in future releases.

16. Jira Development Workflow

Jira Story
→
Analysis
→
Branch
→
Development
→
Testing
→
PR
→
Review

Jira Updates

  • Update Jira status.
  • Attach unit-test results.
  • Attach integration-test results.
  • Add Pull Request reference.
  • Update Effective Version.
  • Update Fix Version.
  • Assign reviewer.
  • Track PR approval.
  • Update deployment status.

17. Jenkins CI/CD

Git Commit
→
GitHub
→
Jenkins
→
Maven Build
→
Tests
→
Package
→
Deploy

Common Maven Activities

mvn clean
mvn test
mvn verify
mvn package

Nightly Build Validation

  • Check Jenkins night-build status.
  • Review failed stages.
  • Analyze console logs.
  • Identify code/build/environment issues.
  • Check installation logs.
  • Check Liquibase execution.
  • Validate database changes.
  • Fix issues.
  • Re-run the build.
  • Confirm successful installation.

18. Linux Deployment

Build Artifact
→
Verify Version
→
Linux Server
→
Configuration
→
Start Service
→
Health Check

Post Deployment Validation

  • Verify application startup.
  • Check application logs.
  • Check database connectivity.
  • Check dependent services.
  • Validate APIs.
  • Validate scheduled jobs.
  • Execute smoke tests.
  • Monitor application metrics.

19. Observability & Performance

Grafana

Dashboards for metrics, service health, performance and operational monitoring.

New Relic

Application performance monitoring, transaction analysis and troubleshooting.

VisualVM

JVM monitoring, heap analysis, CPU and thread analysis.

Important Metrics

Area Metrics / Signals
Application Request count, response time, throughput, error rate
JVM Heap, GC, threads, CPU
Database Connection usage, slow queries, locks, query performance
Infrastructure CPU, memory, disk and system availability
Jobs Execution status, duration and failures

20. Production Support

Typical Support Activities

  • Monitor application health.
  • Investigate application errors.
  • Analyze logs.
  • Check database problems.
  • Investigate integration failures.
  • Validate scheduled jobs.
  • Support deployments.
  • Prepare hotfixes.
  • Monitor application performance.
  • Coordinate with QA and Support teams.

21. Incident Troubleshooting

Application Issue

Incident
→
Logs
→
Metrics
→
Database
→
Dependencies
→
RCA

Build Failure

Jenkins Failure
      |
      +-- Compilation?
      |
      +-- Unit Test?
      |
      +-- Integration Test?
      |
      +-- Liquibase?
      |
      +-- Packaging?
      |
      +-- Deployment?
      |
      +-- Environment?

Database Issue

  • Check database connectivity.
  • Check SQL/query.
  • Check Liquibase change set.
  • Check locks.
  • Check indexes.
  • Check schema.
  • Check query performance.

Production Incident Lifecycle

Incident
→
Impact
→
Investigation
→
Mitigation
→
Fix
→
Validation
→
RCA

22. Agile / Scrum Practices

Daily Stand-up

Discuss progress, today's activities and blockers.

Backlog Grooming

Clarify requirements, acceptance criteria, dependencies and priorities.

Planning Poker

Estimate complexity and story points collaboratively.

Sprint Planning

Calculate capacity and assign tickets based on estimations.

Sprint Review

Demonstrate completed work and collect feedback.

Retrospective

Discuss improvements for quality, delivery and team process.

The development team works with the Product Owner to maintain a well-groomed and prioritized backlog and coordinates with other Scrum Masters to maintain consistent Agile practices.

23. KT Checklist

Business Understanding

  • Understand Play Command business purpose.
  • Understand player lifecycle.
  • Understand wallet functionality.
  • Understand game administration.
  • Understand rewards and notifications.

Technical Understanding

  • Understand microservice architecture.
  • Understand REST APIs.
  • Understand JPA/Hibernate.
  • Understand PostgreSQL.
  • Understand Liquibase.
  • Understand Camel/JMS.
  • Understand Quartz.
  • Understand Solr.
  • Understand Gateway and security.
  • Understand circuit breakers.

DevOps Understanding

  • Understand Git branching strategy.
  • Understand Jira workflow.
  • Understand Pull Request process.
  • Understand Jenkins pipeline.
  • Understand Linux deployment.
  • Understand hotfix and backport process.

Operations Understanding

  • Understand Grafana dashboards.
  • Understand New Relic monitoring.
  • Understand VisualVM.
  • Understand logs and troubleshooting.
  • Understand scheduled production jobs.
  • Understand incident and RCA process.

24. KT / Interview Knowledge Questions

1. What is Play Command?

Play Command is a scalable player-management solution for Lottery/iLottery products supporting player-centric functions, game enablement, wallet management, administration and integrations.

2. Why is a microservices architecture used?

It allows business capabilities to be separated into independently deployable services, improving scalability, maintainability, fault isolation and team ownership.

3. What is the role of Apache Camel?

Camel provides integration, message routing, transformation and orchestration capabilities between application components and external systems.

4. Why is JMS used?

JMS enables asynchronous communication using messaging infrastructure, reducing tight coupling between producers and consumers.

5. Why is Quartz used?

Quartz is used to execute scheduled and recurring jobs automatically, including batch and production activities.

6. What is Liquibase?

Liquibase is a database change-management tool used to version and deploy database schema and data changes through change sets.

7. Why use Solr?

Solr provides fast indexing and full-text search capabilities, especially useful when business applications need flexible and efficient search.

8. What is a circuit breaker?

A circuit breaker prevents repeated calls to an unhealthy downstream service and helps prevent cascading failures.

9. What is the hotfix process?

A production tag is used as the baseline for a hotfix branch. After the fix is released, the change is backported into the appropriate development branch so that the production fix is preserved.

10. How do you troubleshoot a Jenkins night-build failure?

Start with the Jenkins console log, identify the failed stage, determine whether the issue is compilation, testing, packaging, Liquibase, installation or environment related, fix the root cause and re-run the pipeline.

11. How do you troubleshoot a production incident?

Start with impact analysis, application logs and metrics, then check database and downstream dependencies. Identify the root cause, apply mitigation/fix, validate the solution and document the RCA.

12. How do you ensure code quality?

Through unit tests, integration tests, code reviews, code coverage, API testing, automated Jenkins builds and Agile quality practices.

25. End-to-End Development Lifecycle

Planning
Requirement
Jira
Grooming
Estimation
↓
Development
Git Branch
Coding
Unit Tests
Integration Tests
↓
Quality
Code Review
PR
Coverage
Jenkins
↓
Deployment
Artifact
Linux
QA
Production
↓
Operations
Grafana
New Relic
Logs
Incident Support

26. Final KT Summary

The IGT Play Command platform is a scalable digital Lottery player-management solution built using a modern Java/Spring Boot microservices architecture.

The platform combines REST APIs, PostgreSQL, JPA/Hibernate, Apache Camel, JMS, Quartz, Solr, API Gateway, resilience patterns, Jenkins CI/CD, automated testing, GitHub-based development and modern observability practices.

Primary KT Objective: Understand the complete flow from business requirement → Jira → development → testing → code review → Jenkins → deployment → monitoring → production support → incident/RCA.