Presentation at DeveloperWeek 2016

1. Evolution of the PayPal Platform:
Journey to APIs & Microservices
DeveloperWeek Conference
February 17, 2016
Deepak Nadig
@deepak_nadig

2. PAYPAL CONTEXT
2
– 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

3. PAYPAL API PLATFORM USAGE OVER THE YEARS
3
PayPal API
PayPal Capabilities

4. 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
5
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
6
Portfolio of APIs
aligned 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
7
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
MONOLITHMICROSERVICES

8. LOOSE COUPLING
8
• 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
9
• 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

10. 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)
Batch
Processing
External
Notifications
Batch
APIsProtocol conversion
OAuth, CORS
Routing
Orchestration

11. MATURITY MODEL FOR MANAGING CHANGE
11
Maturity
Level
Maturity 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
12
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 LEGACY
Retire internal legacy
Transition to norm
Webhooks

13. TO CLOSE
13
• 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
14