IRFC - A Design Pattern for Next Generation Business Applications: Couchbase Connect 2015

IRFCA DESIGN PATTERNFOR NEXT GENERATION BUSINESS APPS

Steve Yen, Couchbase, Inc.



ImmutableRequests For

Change




Change




Change

©2015 Couchbase Inc. 5

Steve Yen [email protected] co-founder Couchbase

mailto:[email protected]


How do I and my team build our

Next GenerationBusiness Applications

using

couchbase’s software suite?


old schoolfor

inspiration


old school


old school

document forms real paper forms


old school


press hard for 3 copies


old school


press hard for 3 copies yellow for accounting pink for shipping …


old school



no erasers route another form for

changes


old school wisdom



no erasers route another form for

changes

denormalized

replicatableroute’able

immutable


old school wisdom

denormalized


immutable


press hard for all 3 copies yellow goes to

accounting pink for shipping you keep white copy canary for customer

no erasers staple on yet another

form for any future changes

circa 2015


old school wisdom

denormalized


immutable






circa 2015

documentdatabases


old school wisdom

denormalized


immutable






circa 2015

documentdatabases

syncfunctions


old school wisdom

denormalized


immutable






circa 2015

documentdatabases

syncfunctions

the bottom line is immutability


Pat Helland “Immutability Changes Everything” http://www.cidrdb.org/cidr2015/Papers/CIDR15_Paper16.pdf

“Accountants don’t use erasers” http://blogs.msdn.com/b/pathelland/archive/2007/06/14/accountants-don-t-use-erasers.aspx

CQRS command query responsibility separation

http://www.cidrdb.org/cidr2015/Papers/CIDR15_Paper16.pdf



http://blogs.msdn.com/b/pathelland/archive/2007/06/14/accountants-don-t-use-erasers.aspx




a familiar system-of-record

web app server

web browser



web app server

web browser

product-45version: 1

name: t-shirtsize: largeprice: 10

JSON stored in db



web app server

web browser



JSON stored in db



web app server

web browser



JSON stored in db

browser GET’s a

copy



web app server

web browser



JSON stored in db

1

browser GET’s a

copy



web app server

web browser



JSON stored in db

1



web app server

web browser



JSON stored in db

1

render to view on-demand



web app server

web browser



JSON stored in db

next, user wants to

make some updates

1



web app server

web browser


price: 10 -> 15

JSON stored in db

JSON from AJAX / REST request



1

AJA

X /

R

ES

T



web app server


price: 10 -> 15

JSON stored in db

web browser





1JSON from AJAX / REST request

AJA

X /

R

ES

T



web app server


price: 10 -> 15

JSON stored in db

web browser

✓HTTP 200 ok





1JSON from AJAX / REST request

AJA

X /

R

ES

T



web app server


price: 10 -> 15

JSON stored in db

web browser





12


AJA

X /

R

ES

T ✓HTTP 200 ok



web app server JSON stored in db

web browser





12

a concurrent client appears!


concurrent client


web browser





12


concurrent client


web browser





web browser1

21


concurrent client


web browser





web browser1

21


price: 10 -> 8


concurrent client

web app server

web browser


price: 10 -> 8

JSON stored in db

HTTP409conflict





web browser1

21

what if…



price: 15 -> 20

what if…

web browser1

2


web app server

✓HTTP 200 ok

AJA

X /

R

ES

T



price: 15 -> 20

what if…

web browser1

2


this JSON is ephemeral

web app server

✓HTTP 200 ok

AJA

X /

R

ES

T



price: 15 -> 20

what if…

web browser1

2


web app server

✓HTTP 200 ok

AJA

X /

R

ES

Twhat if…

we held onto this

request JSON?



price: 15 -> 20

req-id: 91

what if…

web browser1

2


web app server

✓HTTP 200 ok

AJA

X /

R

ES

Twhat if…

we held onto this

request JSON?

why?


slow, offline server

web app server

web browser1

2

server getsreally slow

or goes down



web app server

web browser1

2

validate.jsmvc.js

business logic unavailable

server getsreally slow

or goes down


validate.js


web app server

web browser1

2

validate.js

mvc.js

mvc.js

some business logic runson both client and server

side

(some) business logic can runon both client

and server side


validate.js


web app server

web browser


price: 15 -> 20

req-id: 91

12

JSON from queued request

validate.js

mvc.js

mvc.js


validate.js


web browser


price: 15 -> 20

req-id: 91

12


mvc.js

run client-sidevalidation

and provisionalmodel updates

validate.jsmvc.js


validate.js


web browser


price: 15 -> 20

req-id: 91

12


mvc.js



validate.jsmvc.js

client side can directlyupdate its copy of the

biz document…

simple for update;complex for

conflict resolution


validate.js


web browser1

2


mvc.js


maybe

name: t-shirtsize: largeprice: 20 maybe






price: 15 -> 20

req-id: 91

validate.jsmvc.js


validate.js


web browser1

2


mvc.js


maybe



price: 15 -> 20

req-id: 91

a provisional biz documentbecause client is not the source of

truth


validate.js


web browser1

2

JSON from queued request(s)

mvc.js


price: 15 -> 20

req-id: 91


price: 20 -> 18

req-id: 92


validate.js


web browser1

2


mvc.js


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 18 -> 10

req-id: 93


validate.js


web browser1

2


mvc.js


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 10 -> 12

req-id: 94


validate.js


web browser1

2


mvc.js


maybe







price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 10 -> 12

req-id: 94

validate.jsmvc.js


validate.js


web browser

ChangeRequests

12


mvc.js


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 10 -> 12

req-id: 94

server’s back online


validate.js


web browser

ChangeRequests

12


mvc.js


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 10 -> 12

req-id: 94


validate.js


web app server

web browser

ChangeRequests

12

validate.js


mvc.js

mvc.js

12


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 10 -> 12

req-id: 94

backendsystems

server’s back online!

source of truth,system of record

has returned!


validate.js


web app server

web browser

ChangeRequests

12

validate.js


mvc.js

mvc.js

AJA

X /

R

ES

T

12


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 10 -> 12

req-id: 94

backendsystems


validate.js


web app server

web browser

ChangeRequests

12

validate.js


mvc.js

mvc.js

AJA

X /

R

ES

T

12


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 10 -> 12

req-id: 94

check forconcurrent changes,

business rules,other systems

backendsystems


validate.js


web app server

web browser

ChangeRequests

12

validate.js


mvc.js

mvc.js

AJA

X /

R

ES

T

12

22

5


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 10 -> 12

req-id: 94

backendsystems

check forconcurrent changes,

business rules,other systems


validate.js


web app server

web browser

ChangeRequests

12

validate.js


mvc.js

mvc.js


price: 10 -> XL


price: 10 -> XL


price: 10 -> XL

product-45version: 5req-id: 94

OK

ChangeResponses

AJA

X /

R

ES

T

12

22

5


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 10 -> 12

req-id: 94

backendsystems


validate.js


web app server

web browser

ChangeRequests

12

validate.js


mvc.js

mvc.js


price: 10 -> XL


price: 10 -> XL


price: 10 -> XL


OK

ChangeResponses

AJA

X /

R

ES

T

12

22

5


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 10 -> 12

req-id: 94

backendsystems

every Change Request

gets its own, pairedChange

Response


validate.js


web app server

web browser

ChangeRequests

12

validate.js


mvc.js

mvc.js


price: 10 -> XL


price: 10 -> XL


price: 10 -> XL


OK

ChangeResponses

AJA

X /

R

ES

T

12

22

5


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 10 -> 12

req-id: 94

backendsystems



price: 10 -> XL


price: 10 -> XL


price: 10 -> XL


OK

validate.js


web app server

web browser

ChangeRequests

12

validate.js


mvc.js

mvc.js

ChangeResponses

AJA

X /

R

ES

T

12

22

5


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 10 -> 12

req-id: 94

backendsystems



price: 10 -> XL


price: 10 -> XL


price: 10 -> XL


OK

validate.js


web app server

web browser

ChangeRequests

12

validate.js


mvc.js

mvc.js

ChangeResponses

12

22

5

22

5


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 15 -> 20

req-id: 91


price: 10 -> 12

req-id: 94

backendsystems

what ab ut mobile?


web app server

web browser

12

22

5

backendsystems


works for mobile, too

web app server

web browser

1

2

2

2



web app server

web browser

CB Sync Gateway

1

2

2

2

5



web app server

web browser

CB Mobile

CB Sync Gateway

1

2

2

2

5



CB Mobile





product 45

name: t-shirt

size: large

price: 15

CB Mobile





product 45

name: t-shirt

size: large

price: 15

CB Mobile






product 45

name: t-shirt

size: large

price: 15

CB Mobile









product 45

name: t-shirt

size: large

price: 15

CB Mobile










product 45

name: t-shirt

size: large

price: 15

CB Mobile











product 45

name: t-shirt

size: large

price: 15

CB Mobile










product 45

name: t-shirt

size: large

price: 15

validate

mvc


CB Mobile





product-45version: 2 maybe







product 45

name: t-shirt

size: large

price: 15


CB Mobile

validate

mvc












product 45

name: t-shirt

size: large

price: 20

product 45

name: t-shirt

size: large

price: 15


no signal?

no proble

m

keeps on

workingCB Mobile

validate

mvc










product 45

name: t-shirt

size: large

price: 15


CB Mobile










product 45

name: t-shirt

size: large

price: 15


CB Mobile
















product 45

name: t-shirt

size: large

price: 15


CB Mobile










product 45

name: t-shirt

size: large

price: 20









product 45

name: t-shirt

size: large

price: 15


CB Mobile










product 45

name: t-shirt

size: large

price: 20









product 45

name: t-shirt

size: large

price: 15


Change Requests & Change Responses

are now actual, persisted,replicated, routed JSON documents

CB Mobile



web app server

web browser

CB Mobile

CB Sync Gateway

✓



web app server

web browser

CB Mobile

CB Sync Gateway

✓

Sync-Gateway is used as amessage queue,

but with advanced sync functions

advancedmobile topologies


advanced mobile topologies

web app server

web browser

CB Mobile

CB Sync Gateway


advanced mobile topologies : hub & spoke

web app server

web browser

CB Mobile

CB Mobile

CB Sync Gateway

hub& spoke

CB Mobile


advanced mobile topologies : peer to peer

web app server

web browser

CB Mobile

CB Mobile

CB Mobile

CB Mobile

CB Mobile

CB Mobile

CB Sync Gateway

peer to peer

hub& spoke










peer to peer sync











peer to peer sync

ChangeRequestssync’ed

from peers


product-45version: 2req-id: 94product-45

version: 2req-id: 94


peer to peer sync










from peers







peer to peer sync










from peers







peer to peer sync










product 45

name: t-shirt

size: small

price: 20



from peers

validate

mvc


















peer to peer sync










from peers

ChangeResponse

ssync’ed

from peers


















peer to peer sync










from peers

ChangeResponse

ssync’ed

from peers



new versionssync’ed

from peers


advanced mobile topologies

web app server

web browser

CB MobileCB Mobile

CB MobileCB MobileCB MobileCB Mobile

CB Sync Gateway

peer 2 peer

hub& spoke✓

✓

kinds of IRFC documents


immutablereplicatable routable

Biz Document

Change Request

Change Response

Provisional Biz Document

product-45version: 2name: t-shirtsize: largeprice: 15




product-45version: 2 maybename: t-shirtsize: largeprice: 15 maybe



Biz Document versioned yy

Change Request

Change Response










Change Request yy y

Change Response y yy










Change Request yy y

Change Response y yy

Provisional Biz Document mutableno no

client-side-only client-side-only







creatorupdator

Biz Document

Change Request

Change Response


kinds of IRFC documents, part 2






creatorupdator

Biz Document S-O-R S-O-R system of record

system of record

Change Request

Change Response








creatorupdator


system of record

Change Request client no, immutable

Change Response S-O-R no, immutable








creatorupdator


system of record



Provisional Biz Document client client







creatorupdator deleter


system of record










creatorupdator deleter

Biz Document S-O-R S-O-R S-O-R

system of record system of record


requestor w/ change-response

Change Response S-O-R no, immutablerequestor w/ change-request


client






business scenarios


works for many business documents

product / item customer employee / org supplier invoice sales-order packing-slip shipping-

manifest inventory-count RMA’s






item-transfer

acct-transfer

dashboard leaderboard report






likes / votes / pokes?

10 M followers? 10 M

comments?

item-transfer

acct-transfer

dashboard leaderboard report


we’ve just scratch the surface

we’ve just scratch the surface

meaning, it’s time to wrap up


How do I and my team build our

Next GenerationBusiness Applications

usingcouchbase’s software suite?

Mobilized >

Occasionally<

Disconnected


IRFC – immutable requests for change



old school inspired



old school inspired design pattern



old school inspired design patternimmutable, replicatable, routabledocument data

biz document

provisionalbiz document

changeresponse

changerequest



old school inspired design patternimmutable, replicatable, routabledocument datamobilized

biz document


changeresponse

changerequest




multi-topology

biz document


changeresponse

changerequest

web app server

web browser

CB MobileCB Mobile

CB MobileCB MobileCB Mobile

CB Sync Gateway




multi-topology for yournext-gen business applications

biz document


changeresponse

changerequest

web app server

web browser

CB MobileCB Mobile


CB Sync Gateway




multi-topology for yournext-gen business applicationsalso has pretty colors

biz document


changeresponse

changerequest

web app server

web browser

CB MobileCB Mobile


CB Sync Gateway

IMMUTABLE REQUESTS FOR CHANGE

#IRFCQuestions?THANKS!

(and please do the survey)



extra slides


feedback from the crew

why this not rev trees?

is this implementing on top of rev-trees? instead of rev-trees?

is this CB’s blessed approach for modeling (or just one of many patterns/tools)no mutable docs?new featurebase rev and incr / CRDT example from dave

change request is an atomic document on its own

better title

more compare & contrast to other patterns

cloud / datacenter

CB Mobile

CB MobileCB Mobile

CB Mobile

CB Mobile CB Mobile

topology

peer to peer sync andcycles are fine, too

CB Mobile(sync-gw)

business logic

(app svrs)


validate.js

slow, offline backend integration

web app server

web browser

backendsystems

12

validate.js

mvc.js

mvc.js


immutability makes everything easier

immutable

you can’t change a document but you can version them

and, if you have concurrent updates e.g., disconnected mobile users you can make a new “change-request”

documentsagainst existing document &

versions a system of record needs to reconcile change-

requests


new school architecture

ios

app

cloud / datacenter

Couchbase ServerCB Mobile(sync-gw)

CB Mobile(sync-gw)

CB Mobile

CB Mobile

android app

CB Mobile

mobile web app

sync funcs

sync funcs

web browser

web app server

server-sidebusiness logic

web UI

CustomerDoc-001, version 12

a master doc and change requests


change-request 123to CustomerDoc-001, version 12

“update address”


an AP system can build up a stack of immutable change-request docs up against a master doc





“update address some more”









“update email”



Zachary Gramana

The "change requests" doc is essentially a commutative replicated data type (CmRDT), but the conception as stated violates the commutativity rule required to make it qualify as a conflict-free. However, since the change request does not also send the full local state, it cannot meet the requirements of being a convergent replicated data type (CvRDT). The problem here comes into sharp relieve when you need to handle partitions between edge nodes. In this case, there is no way to prevent each edge node from creating change-request documents that don't have the same sequence numbers. In which case, the "center" system does not have enough information to determine which one is the "real" one. If each change request included a vector clock going "all the way back in time" to version 12 (in this example), then you would then have both ingredients needed for implementing Operational Transforms.

Steve Yen

No claim that these change-requests must be CmRDT's or CvRDT's. (If they _were_ then my app team would see even more benefits.)On CmRDT's, for example, on my phone, as I build up a "stack" of change-requests against a master document, they might not be commutative. Also, the app will need to assign unique ID's to each of these change-requests... so they're not sharing some global sequence number.Nothing's preventing other users/edge-devices from concurrently making their own change-requests. But, since there's no seq-num sharing for change-requests, it's no problem.On the center not having enough info to pick the 'real' change-request, I'd claim that's actually a "must" responsibility of the center to examine each change-request and either apply the business logic rules to accept&incorporate each one or to reject them (and perhaps reference them in some "exception queue" that a human can look at later) or to realize (idempotently) that "hey, I already processed this change-request (because I see that there's already a change-response)" so I can ignore it.But, the business logic rules might be complex. Like one change request might be "change the first name field value from Zach to Zack, on master document user-record-4, version-47.But, maybe I made that Zack name change while traveling out of network, and meanwhile a whole bunch of other change-requests went through (the current user-record-4 is now at version-200000)But, in all those other changes, everybody else left "Zach" untouched. The center biz rules says, no problem, this one's is a field-level thing so go ahead and accept and incorporate "Zack" and the new name value, which leads to user-record-4, version 200001.







“update email”



customer 001

name: steve yen

phone: 650 804-1417

email: [email protected]

address san francisco

the edge AP system can display the master doc in a view merged with any change-requests, and can also indicate whether those changes-requests are still pending







“update email”

a master doc, change requests & change responses







“update email”

change-response 532 to change-request 133on CustomerDoc-001, version 12

“ok”


“ok”


“accepted”









“update email”


“ok”


“ok”


“accepted”

CustomerDoc-001, version 14customer 001

name: steve yen

phone: 650 804-1417

email: [email protected]

address san francisco


Zachary Gramana

What happens here if prior to applying 123, 127, and 133 (and thus creating version 14) a center user saves a version 13 master doc with an address of "completely different"? Will version 14 end up with "completely different address" or "update address some more"?

Steve Yen

It's up to the actual biz logic...For example, it might reject the changes if it's following some CAS-like rules.Or, it might merge the changes if it's following some rules like "hey, this is an ok field-level-by-field-level change", since maybe the before-values still match.

Zachary Gramana

I think the confusion for me here was that I thought this proposal was to have the system provide this logic, rather than the user.

extra slides

143

case: generating unique ID’s

example: globally unique ticket ID generationUUID’s (hard for end-users to use (hard to read & type => copy & paste))

provisional #’s (bookmarks & refs might be to unapproved provisional ID’s)

steve001-72 (local, provisional) vs MB-11411 (from the center, final)

pre-reserved ranges (numeric gaps; need occasional sync to reserve new ranges)

byzantine, adversarial actors might generate bad #’s? the center sorts it all out

case: inventory counts

current inventory snapshot is 15and, you sold one ticket via an edge POS device, so... create a change-request

“change inventory to 13” (bad - concurrency races)vs

“change inventory by -2” (a better model; commutative)vs

“create inventory-reservation-request with count 2” (best)should have lots of cross-correlation data & refs for

idempotencyso that the center can apply the -2 just once

pattern: a change-response might also be master doc

a inventory-reservation-requestcan have a change-response of “accepted”

ora result of “success”, where we just create

a brand-new inventory-reservation doc

case: aggregates

aggregates are everywhere...similar to inventory counts

similar to friend countssimilar to “like’s” and “+1’s”similar to article/video “views”

case: leaderboards / dashboards

a leaderboardor a global aggregate dashboard

would be a master docgenerated in the center

local, edge changes can be reflectedin local renderings

case: a new customer

field sales meets new customer,begins data entry on her edge device

so, it’s an edge document, like…CreateCustomerRequest

rendered on device as provisional untilthe center creates a change-response

like a brand new master doc… a Customer doc

multi-master change-requests

transfer inventory, resource or money from A to Bwho’s the master doc?

location A or location B?

the answer might be “both”

search / queries ?

user updates a customer record...but before she syncs back to the center…

how do edge searches/queries work?answer:

need to query the reduced/merged resultswhere change-req’s shadow

the underlying master docs

immutability simplifies a lot

idempotency, too

immutability simplifies a lot

idempotency, too

(it’s also lambda architecture friendly)

Zachary Gramana

Interestingly, as a total aside, people often don't realize that SG already implements a lambda architecture. :)

but, immutability is expensive

lots of mutations means lots ofversionschange-requestschange-responses

big storage utilization explosion?especially for fast-changing data

optimization: center documents

CP system doesn’t need to track rev-tree’sfor center documents;

after all, center documents should be100% consistent (source of truth)

similarly, on AP side, there shouldn’t bebushy rev-tree’s for center docs;

rev-trees can be aggressively pruned / dropped

optimization: cleaning old change requests & responses

change request docs should never enterinto a CP database; instead, biz logic

should be bridging between AP & CP systems

once a change-request doc is handledand has a matching change-response doc,

they both can be deleted as long as they’vebeen replicated (everyone’s seen the change-

response)

optimization: delay immutability until replication

you can relax on document immutability,as long as you haven’t replicated yet

example: you can merge and collapse multiplechange-requests into fewer, smaller docs,

until you’re ready to replicate (cblite has controllable replication)

see also: CRDT data structures (e.g. inventory counts or friend-like +1’s)

Zachary Gramana

One variant which Jens and I have recently discussed is a variation on this suggestion, whereby we implement the unit-of-work pattern internally to a doc/proxy so that multiple mutations to a document/object can be coalesced into a single immutable revision once the user signals they are done making changes and which to either save or revert them.

Zachary Gramana

The proposal you make here is actually conceptually similar to git's "squash" process whereby local immutable revisions are allowed to be merged into a single revision provided that the repository has not yet been replicated. Conceptually, I don't see a reason why we couldn't implement the same feature in CBL, though it would be both more compute expensive and more IO expensive than the unit-of-work approach described above. Both approaches could co-exist simultaneously as well. However neither exist currently and neither is a trivial feature to implement.

Steve Yen

Yep, it's the squash. If it never left your box, nobody saw it happen.

cloud / datacenter

Couchbase Server Enterprise

CB Mobile

CB MobileCB Mobile

CB Mobile

CB Mobile CB Mobile

topology

peer to peer sync andcycles are fine, too

the design rules would still workif this was SAP or ORCL or SFORCE

CB Mobile(sync-gw)

business logic

(app svrs)

business logic rulesbridge the AP & CP systems

the design rules would still workif this was coredata or sqlite or meteorjs


agendaproblem pattern new users, new employees, new products unique ID generation blog, comments, stars embed vs refer many followers 1 to (potentially) massive

manyappend &positive/negative bags

a dashboard / leaderboard aggregate bins time series data time based bins inventory transfers atomic, immutable docs enterprise apps atomic, immutable,

mobile docs


how I do...?create unique customer ID’s across

devices?manage “already seen/read” on news

events?integrate with my external credit check & scoring

systems?implement friend “likes” and unlikes with double-counting?handle reserving or allocating potentially overbooked inventory?have aggregate reports on top N reps/region/product?transfer game gold or inventory from player A to player B?handle concurrent updates on a customer record?handle loops/cycles of P2P replication?implement a distributed CMS?handle comments on page?have audit trails?too small, etcto read?

Section Break (Blue)Subtitle

Thank you.


next generation business apps

mobilized occasionally disconnected cross platform devices multiple topologies (star, peer 2 peer, …) IoT scale out flexible transactions reports


Architecting next generation, disruptive business applications using document data modeling and design patterns that leverage Couchbase's full product suite

LEVERAGINGCOUCHBASE PRODUCTSTO BUILDNEXT GENERATION BUSINESS APPS

Steve Yen, Couchbase


.:/+mmsssssssm+/:.`

-/msyyyyyyyyyyyyyyyyyyym/-`

.+syyyyyyyyyyyyyyyyyyyyyyyyyys+-

-myyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyys:

.myyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyys-

/syyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy+`

`myyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyys`

myyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyys`

/yyyyyys/..````myyyyyyyyyyyyyyyys.```..:syyyyyym

.syyyyyy- /yyyyyyyyyyyyyyyym `yyyyyyy:

/yyyyyyy. /yyyyyyyyyyyyyyyym yyyyyyym

myyyyyyy. /yyyyyyyyyyyyyyyym yyyyyyyy

syyyyyyy. ````` ````` yyyyyyyy

myyyyyyy. yyyyyyyy

/yyyyyyy. yyyyyyym

.yyyyyyy/ :yyyyyyy:

+yyyyyyysm+//::::--------------:::://+msyyyyyyys

myyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy`

`myyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyys.

+yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyym`

-syyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy:

:syyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy/`

-+yyyyyyyyyyyyyyyyyyyyyyyyyyyym:

-+syyyyyyyyyyyyyyyyyyyyy+:`

`-:+mssyyyyyyysm+/-`

Software

IRFC - A Design Pattern for Next Generation Business Applications: Couchbase Connect 2015