Architectural hiccups (and you really shouldn't bother with sprint-0)
summary
An online poker platform evolves from simple Java clients and a Java-based server to handle 20,000 concurrent players, strict legal game history retention and a late demand for hardware RNG integration; engineers add a custom protocol, handle asynchronous timers that misfire, enforce tournament timeouts, and build bot-based test rigs. The RNG native call takes three sprints to implement, stateful reconnection and negative-balance fallout force architectural fixes, and the team concludes no sprint-0: do small shippable work, iterate, and learn.
AI-written summary · about
chapters (8)
- 0:00Start
- 2:08Background
- 8:33Application: a bird's eye view
- 12:43Servers must be ...
- 20:36Tricky to test software which..
- 22:38Example of asynchronous behaviour
- 24:25Some of problems detected
- 43:35Experience reminds us that
related talks
17mExtreme Engineering-Elements of Building a High -scale Broking Application
57mAnalysis of FOSS Gaming Failure: A history of PokerSource and Open Source Online Poker
27m“Good Enough” Architecture Part 2
01h 01mArchitecture Decisions: A Case Study -
31m“Good Enough” Architecture Part 1
33mFrom Enterprise Architecture to Software Design - Critical Thinking
51mMicroProcess Architectures: Planning for Change, & Retaining Flexibility
20mBuilding for Scale: How not to get Caught out at Global Launch