Evolution of the PayPal Platform: Journey to APIs & Microservices

DeveloperWeek ConferenceFebruary 17, 2016

Deepak Nadig@deepak_nadig

2

PAYPAL CONTEXT– 179 million active customer accounts– 203 markets and 100 currencies– Serves 2M+ external developers

– 2015: TPV of $282 Billion, 4.9 Billion transactions– Mobile: 23% of TPV, 28% of transactions

– Q4 2015– TPV of $82 Billion, $10400 / second– Growing 29% YoY– 1.43 Billion transactions, 15.6 million payments / day– Mobile: 25% of TPV, 45% volume growth

– 22% cross border trade

In a globally dynamic environment– 300+ features per quarter; 100K+ LOC every two weeks– 17K employees across the globe

PAYPAL API PLATFORM USAGE OVER THE YEARS

3

PayPal API

PayPal Capabilities

API PLATFORM CHALLENGES (2012)

4

External API

• Multiple developer portals

• Overlapping, inconsistent APIs

• Learn from large documents

• Complex sign-up process

• Incomplete, unreliable Sandbox

Internal SOA

• Discovery through tribal knowledge

• Overlapping, inconsistent APIs

• Integrating with an API took weeks

• Tight coupling; monoliths

• Proprietary standards & technology

5

API PLATFORM – CURRENT (2012) & TARGET

API Definition Internal or External Universal

API Discovery Painful Developer Portal

API Design Project specific API as a Product

Architecture Tightly coupled SOA Loosely coupled SOA

Technology Proprietary Standards based

Integration Expensive TTFHW1 < x min

(1) Time To First Hello World – Time to make a simple call/application using APIs

6

PAYPAL API PLATFORM

Portfolio of APIsaligned by business capabilities,

realized by isolated and encapsulated services,that can be used by internal and external developers

to develop applications and integrations quickly and cost effectively

7

BUILDING A GOOD API AND MICROSERVICE

API First

API as a Product

• Work back from end customer use cases• API Design Standards

• Capability and domain modeling• API portfolio

Developer Experience• Easy to learn, integrate, diagnose• Time To First Hello World

API Quality Attributes• Response time• Availability

Service Implementation• Isolation of code and data• Encapsulation

MO

NO

LITH M

ICR

OS

ER

VIC

ES

8

LOOSE COUPLING• API Portfolio

• Orthogonal capabilities• Bounded contexts• Related by “foreign keys”

id

id

/invoicing /payments

/risk

Domain model API• Entities, Attributes• Verbs• Relationships• State machine, Domain events

How is your implementation prioritizing

customer needs vs. cost?

• API• Domain model Problem space• No shared definitions• Agreement on vocabulary & standards

• Service implementation• Reuse = Coupling• Tolerance to latency & availability• Code & data isolation

9

Microservice Granularity• Cohesive

• Should realize a cohesive and loosely coupled capability• Adaptability

• Should not mix functionality exposed to different rates of change• Scalability

• Should not mix different levels of scalability• Security

• Should not mix different levels of security

Granularity is usually a function of

company growth stage and organization structure

TARGET STATE - RUN-TIME ARCHITECTURE

10

API Facade

Payments Instruments Customer

Credit Risk Compliance

Invoicing

Disputes

PayPal Applications(Wallet, POS)

2nd-party Applications

(eBay, Braintree)

3rd-party Server Applications

(Online websites)

PayPal Web Applications

Experience APIs

Capability APIs

Event Bus

Webhooks

3rd-party Mobile Applications

(Uber, PhotoCard)

BatchProcessing

ExternalNotifications

Batch APIsProtocol conversion

OAuth, CORSRoutingOrchestration

11

MATURITY MODEL FOR MANAGING CHANGEMaturity

LevelMaturity Level

Name Characteristics (Design, Functional, Operational)

Level 1 Exists All services (classic & new)

Level 2 Functional Complies with API standards, fully tested, basic documentation

Level 3 Core API aligned with product structure, complete developer experience

Level 4 Performant Complies with Service Level Objective (response-time, availability)

Level 5 Ideal Fully isolated (code & data) and encapsulated

Shared 2014 Goal for completing at least 75% of platform at Maturity Level 3+Shared 2015 Goal for completing at least 50% of platform at Maturity Level 5

12

API EVOLUTION – THE JOURNEY

2016

NORM

2012

INITIATED

President buy-in

Company mandate

Seed organization

Right people

2013

EXTERNAL

Launched externally

Started internally

Early adopters

2014

EXPANSION

Complete majority

Educate, evangelize

Recognize success

2015

MANAGE LEGACYRetire internal legacy

Transition to norm

Webhooks

13

TO CLOSE

• Business imperative has prioritized agility over cost efficiency

• Agility comes from flexible architectures and short cycle times

• Flexibility comes from APIs and loosely-coupled (micro) services

• Moving to a flexible architecture needs persistence and air cover

• Culture has to go hand-in-hand with architecture for sustenance

14

Thank You