The document discusses the architectural complexity of building the bwin P5 online poker system. While the functional requirements of poker are straightforward to implement, there are many non-functional requirements that complicate the system, such as performance, stability, flexibility, security, and compliance with varying regulations. The original P4 system worked but had scaling issues. The new P5 system was built from the ground up using a modular architecture with asynchronous integration and abstraction/encapsulation to address the essential complexity while improving availability, performance, flexibility and consistency. The key lessons were to not try to escape essential complexity but rather to architect it effectively through principles like modularization and decentralization.

1. Architectural Complexity
Lessons from the bwin P5 Poker System
Presented by:
Henrik “Henke” Lagercrantz & Gerold “Cactus” Kathan
QCon London 2010, March 10 2010

2. Online Poker
• Functional Requirements in the Poker domain are well-
understood and therefore EASY to implement
• However, there are a series of Non-Functional
requirements that complicate the implementation of
Online Poker

3. extreme performance

4. massive stability

5. immediate time2market

6. infinite flexibility

7. seamless integration

8. maximum cost efficiency

9. superior quality

10. cosy customer experience

11. customer care friendly

12. tons of real money

13. real-time transactions

14. ultimate security

15. fraud detection

16. auditable compliance

17. global reach

18. organizational scaling

19. operational excellence

20. pervasive monitoring

21. fully automated processes

22. hold on
every serious
e-commerce
shop has to deal with those issues.....

35. who are those guys ?
...getting
COMPLEX ?

36. The Speakers
Henke Cactus
“I would prefer the correct "...guys, what is the real problem
solution over the simple one" you want to solve here ?"

37. P5 HISTORY
P4 ?

38. What was P4?
• P4 = Poker v4
• Ran from 2002 to 2008...it worked!
But...we had performance issues, that we fixed...
• Then the UIGEA happened...and we turned to Europe...
REGULATION!!

39. REGULATION
• Non-compliance = NOT OPTIONAL!
• „Weird‟ regulations/requirements
• Implementation on P4
= IMPRACTICAL for multiple markets

41. NEW Build
= P5

42. 2007 challenging project ahead...

43. business
drivers

44. Support the widest range of gaming
regulatory requirements

45. highly
Build a poker platform with a
customizable
client.

46. Enable a wide range
of new games, business models, and integration scenarios

47. most scalable
Build the world‟s
and cost-efficientpoker platform.

49. we took a step back...

50. feel
we could the complexity of P4 ...

51. But it looks simple?

52. we looked inside the simple boxes ...

53. Buuuuh ......... good old legacy mess

54. we learned to
differentiate ...

55. Accidental
Complexity
Hello!!

56. Essential
Complexity

57. E = m c²

58. “In the presence of essential
complexity, establishing simplicity
in one part of a system requires
trading off complexity in another”
– Grady Booch, IT Guru

59. WTF is that?
P5 Architecture

60. KEY Principles
• Modularisation
• Asynchronous Integration
• Abstraction
• Encapsulation

61. Eventual
Consistency

62. “Those are my principles,
and if you don't like them...
well, I have others”
- Groucho Marx

63. too much fluffy stuff already…
details pleeese!

65. Sorry about that ...
…let’s look at an Example instead

67. Original Setup
reads writes
Reader DB Writer
History Storage
Service

68. Availability
Performance
Flexibility
Consistency

69. Availability
Performance
Flexibility
Consistency

70. Relational
Data Model
de
s pe
ne nd
fi s
de on
reads writes
Reader Writer
DB
History Storage
Service

72. Time to Modularize…
DB Became
DB
History Storage
History Service Audit Service
Service

73. Relational
Data Model
n es tran
fi slat
de es
reads fetches writes
Reader Writer
DB
History Service Audit Service

74. LB
Audit Service Writer
High Performance
Continuous Availability

75. DB
Reader
History Service Audit Service
Consistency
Flexibility

76. Busting a CAP (theorem)
High Performance
Continuous Availability
Flexibility
Consistency
Eventual Consistency

77. Reader DB Writer
History Storage
Service

78. LB
DB
Reader
History Service Audit Service Writer

79. fine ...

80. short
recap...

81. big
we did a rewrite of our
poker system

82. we won't do it again ;-)

83. we learned our lessons !

84. do not try to escape
the essential complexity !

85. architect it !

86. resistance is futile

87. any questions ?

88. you remember the cat ...

89. join.us@bwin.com

90. Embrace Essentíal Complexity.
Architect it !