Architectural Complexity Lessons from the bwin P5 Poker System - - PowerPoint PPT Presentation

▶
architectural complexity
SMART_READER_LITE
LIVE PREVIEW

Architectural Complexity Lessons from the bwin P5 Poker System - - PowerPoint PPT Presentation

Feb 17, 2024 244 likes •1.15k views

Architectural Complexity Lessons from the bwin P5 Poker System Presented by: Henrik Henke Lagercrantz & Gerold Cactus Kathan QCon London 2010, March 10 2010 Online Poker Functional Requirements in the Poker domain are well-

slide-1
SLIDE 1

Architectural Complexity

Lessons from the bwin P5 Poker System

Presented by: Henrik “Henke” Lagercrantz & Gerold “Cactus” Kathan QCon London 2010, March 10 2010

slide-2
SLIDE 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

slide-3
SLIDE 3

extreme performance

slide-4
SLIDE 4

massive stability

slide-5
SLIDE 5

immediate time2market

slide-6
SLIDE 6

infinite flexibility

slide-7
SLIDE 7

seamless integration

slide-8
SLIDE 8

maximum cost efficiency

slide-9
SLIDE 9

superior quality

slide-10
SLIDE 10

cosy customer experience

slide-11
SLIDE 11

customer care friendly

slide-12
SLIDE 12

tons of real money

slide-13
SLIDE 13

real-time transactions

slide-14
SLIDE 14

ultimate security

slide-15
SLIDE 15

fraud detection

slide-16
SLIDE 16

auditable compliance

slide-17
SLIDE 17

global reach

slide-18
SLIDE 18
  • rganizational scaling
slide-19
SLIDE 19
  • perational excellence
slide-20
SLIDE 20

pervasive monitoring

slide-21
SLIDE 21

fully automated processes

slide-22
SLIDE 22

e-commerce

shop has to deal with those issues.....

hold on

every serious

slide-23
SLIDE 23
slide-24
SLIDE 24
slide-25
SLIDE 25
slide-26
SLIDE 26
slide-27
SLIDE 27
slide-28
SLIDE 28
slide-29
SLIDE 29
slide-30
SLIDE 30
slide-31
SLIDE 31
slide-32
SLIDE 32
slide-33
SLIDE 33
slide-34
SLIDE 34
slide-35
SLIDE 35

...getting

COMPLEX ?

who are those guys ?

slide-36
SLIDE 36

The Speakers

Cactus

"...guys, what is the real problem you want to solve here ?"

Henke

“I would prefer the correct solution over the simple one"

slide-37
SLIDE 37

P5 HISTORY

P4 ?

slide-38
SLIDE 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!!

slide-39
SLIDE 39

REGULATION

  • Non-compliance = NOT OPTIONAL!
  • „Weird‟ regulations/requirements
  • Implementation on P4

= IMPRACTICAL for multiple markets

slide-40
SLIDE 40
slide-41
SLIDE 41

NEW Build = P5

slide-42
SLIDE 42

2007 challenging project ahead...

slide-43
SLIDE 43

business drivers

slide-44
SLIDE 44

Support the widest range of gaming

regulatory requirements

slide-45
SLIDE 45

Build a poker platform with a highly

customizable

client.

slide-46
SLIDE 46

Enable a wide range

  • f new games, business models, and integration scenarios
slide-47
SLIDE 47

Build the world‟s most scalable and cost-efficient poker platform.

slide-48
SLIDE 48
slide-49
SLIDE 49

we took a step back...

slide-50
SLIDE 50

we couldfeel the complexity of P4 ...

slide-51
SLIDE 51

But it looks simple?

slide-52
SLIDE 52

we looked inside the simple boxes ...

slide-53
SLIDE 53

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

slide-54
SLIDE 54

we learned to

differentiate...

slide-55
SLIDE 55

Hello!!

Accidental

Complexity

slide-56
SLIDE 56

Essential

Complexity

slide-57
SLIDE 57

E = m c²

slide-58
SLIDE 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

slide-59
SLIDE 59

P5 Architecture

WTF is that?

slide-60
SLIDE 60

KEY Principles

  • Modularisation
  • Asynchronous Integration
  • Abstraction
  • Encapsulation
slide-61
SLIDE 61

Eventual Consistency

slide-62
SLIDE 62

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

  • Groucho Marx
slide-63
SLIDE 63

too much fluffy stuff already… details pleeese!

slide-64
SLIDE 64
slide-65
SLIDE 65

Sorryabout that ...

…let’s look at an Example instead

slide-66
SLIDE 66
slide-67
SLIDE 67

Original Setup

reads writes

Writer Reader History Storage Service

DB

slide-68
SLIDE 68

Availability Flexibility Performance Consistency

slide-69
SLIDE 69

Availability Flexibility Performance Consistency

slide-70
SLIDE 70

Relational Data Model

d e f i n e s

d e p e n d s

  • n

Writer Reader

writes reads

History Storage Service

DB

slide-71
SLIDE 71
slide-72
SLIDE 72

Time to Modularize…

Audit Service History Storage Service

DB

Became

History Service

DB

slide-73
SLIDE 73

reads writes fetches

Relational Data Model

defines translates

Writer Reader Audit Service History Service

DB

slide-74
SLIDE 74

High Performance

Writer Audit Service

LB

Continuous Availability

slide-75
SLIDE 75

Consistency Flexibility

Reader Audit Service History Service

DB

slide-76
SLIDE 76

Busting a CAP (theorem) High Performance

Continuous Availability

Flexibility

Consistency

Eventual Consistency

slide-77
SLIDE 77

Writer Reader History Storage Service

DB

slide-78
SLIDE 78

Writer LB Audit Service Reader History Service

DB

slide-79
SLIDE 79

fine ...

slide-80
SLIDE 80

recap...

short

slide-81
SLIDE 81

poker system

we did a big rewrite of our

slide-82
SLIDE 82

we won't do it again ;-)

slide-83
SLIDE 83

we learned our lessons !

slide-84
SLIDE 84

the essential complexity ! do not try to escape

slide-85
SLIDE 85

architect it !

slide-86
SLIDE 86

resistance is futile

slide-87
SLIDE 87

any questions ?

slide-88
SLIDE 88

you remember the cat ...

slide-89
SLIDE 89

join.us@bwin.com

slide-90
SLIDE 90

Embrace Essentíal Complexity. Architect it !