Hangman service exposes three REST API endpoints
- API to start new game
- API to retrieve started game
- API to modify the game state by guessing new character
Start service from command line using Gradle or from with-in the IDE
./gradlew bootRun
- Start new game API
- Method: POST
- Uri: : http:/localhost:80801/hangman
- Status Codes: 200 (Ok), 404 (NOT_FOUND), 400 (BAD_REQUEST)
- Sample Response:
{ "stateId": "b5edb1be-3675-4fc1-90d3-18c332b97b70", "wrongGuesses": "", "guessesLeft": 10, "solved": false, "gameSolution": "__________"}
- Retrieve game API
- Method: GET
- Uri: : http:/localhost:80801/hangman/{stateid}
- Status Codes: 200 (Ok), 404 (NOT_FOUND), 400 (BAD_REQUEST)
- Sample Response:
{ "stateId": "b5edb1be-3675-4fc1-90d3-18c332b97b70", "wrongGuesses": "x", "guessesLeft": 9, "solved": false, "gameSolution": "ha_______"}
- Make a guess API
- Method: PUT
- Uri: : http:/localhost:80801/hangman/{stateid}/{guess}
- Status Codes: 200 (Ok), 404 (NOT_FOUND), 400 (BAD_REQUEST)
- Sample Response:
{ "stateId": "b5edb1be-3675-4fc1-90d3-18c332b97b70", "wrongGuesses": "xkl", "guessesLeft": 5, "solved": true, "gameSolution": "hangman"}
- Assuming the service is to be run in a clustered environment behind load balancer
- Perhaps adding API Gateway layer for routing, throttling (by ip), monitoring, analytics and security
- Distributable caching layer (write around cache) with LRU eviction policy to maintain hot games in cache
- Obvious choice is NoSql DB, since we don't need JOINS and transaction ACID kind of properties to persist game/game state, using stateId as partition key
- Three replicas/replication factor for failover
- Schema:
- stateid: UUID (partition key)
- content: Varchar
- expire_time
- Enforce time to live for automatic cleanup of stale data (30 days) based on expire_time