Miguel Carranza presented his top learnings from architecting a high throughput critical API. He emphasized that developer experience and reliability are most important. For developer experience, documentation, anticipating unexpected uses, consistency, deprecation policies, and separating internal and external endpoints are key. For reliability, establishing an on-call rotation, keeping the system simple, optimizing early, anticipating bottlenecks, and establishing limits are important. His top takeaways were to treat the API like a product, put developers first, ensure consistency, and focus on reliability once developers are using the API.

1. Top 10 learnings architecting a
high throughput critical API
Miguel Carranza
Co-founder & CTO
RevenueCat
@elwatto

2. ● Most of you are viewing this session from our event platform, which we
hope you are enjoying! To submit a question to the speaker - you can use
the “Question” feature positioned on the right rail of your screen
● If you’d like to be on directly with the speaker, click the join us on stage
button ( found below the player) -- we’ll take questions at the end
● Interactive, 20 minute session followed by a networking session with Beth
● These sessions will be recorded and available post event
Housekeeping Notes

3. ● API and SDK for managing in-app
subscriptions
● Launched during YC (Summer 18)
● 5000+ apps
● Unlocking & entitlement checking
● We cannot go down!
Intro
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

4. 3x Growth YoY
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

5. 1. Developer experience
2. Reliability
What makes a great API?
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

6. Developer Experience
● Documentation
● Unexpected uses
● Consistency
● Deprecation
● Internal vs External
Reliability
● On-call rotation
● Simplicity
● Early optimizations
● Bottlenecks
● Limits
Top 10 learnings
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

7. DEVELOPER
EXPERIENCE
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

8. ● First contact with developers
● Reduces CS tickets
● Improves funnels
● Good for SEO
● Code samples
Documentation
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

9. ● Ideally, your API is designed in a robust way, no room for error
● At scale, people will use your API in crazy ways you never
imagined
● It’s not their fault. It’s your fault
● You need to protect against these
● Most common cases are duplicated/out of order requests:
○ Protect against race conditions
○ Idempotency
Unexpected use cases
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

10. ● Developers are logical people. They hate inconsistencies.
● API is your product. Manage it like any other product.
● Extreme attention to detail required when designing the API
● Some mistakes we made
○ Upper/lowercase irregularities
○ Dates in different formats (ISO8601 vs epoch)
○ Discrepancies between REST API, webhooks and dashboard
Consistency
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

11. ● You can deprecate, but you need a really good plan
● Remember, best APIs work in perpetuity
● You don’t need to live with your mistakes forever, but existing
customers should not be penalized
● Encourage customers to upgrade, but support old versions as long
as you can
Deprecation
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

12. ● Unified APIs are great, but sometimes splitting them might make
sense:
○ Sync vs async operations
○ SDK vs Developer API
○ Developer support operations
○ SDK vs Dashboard…
● Always prioritize consumer’s ease of use
Internal vs External endpoints
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

13. RELIABILITY
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

14. ● Set it ASAP
● We did it too late, founders carrying laptop 24/7
● Some learnings:
○ It helps creating feeling of ownership
○ New employees: training and pairing
○ Create a fire drill document
○ Multiple time zones help drastically
○ Alarms SNR
○ Blameless post-mortems
○ Automate all the things
○ Ideally 5+ people in the rotation
On-call rotation
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

15. ● Simple stack, simple architecture, simple infrastructure
○ Easier to hire
○ Easier to onboard
○ Easier to get a deeper knowledge of the tools
○ Easier to scale
● Avoid adding a new piece of infrastructure until really
needed
● Proven boring technology > fancy unused new technology
Simplicity
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

16. ● You might not know for sure
where the bottleneck is
● It might take a lot of effort and
be virtually useless
● Always profile, optimize the
most common case
● However...
Do not early optimize
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

17. ● Be proactive, monitor and constantly predict the next
bottleneck and single points of failure:
○ Database memory, CPU, IOPS, space and connections
○ Caching layer
○ Queue capacity
○ Servers CPU, memory and IO
○ ...
● Migrations are way less stressful when they have been
planned and rehearsed
Always look for the next bottleneck
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

18. ● Nothing is completely infinite
● Better to think about them earlier: rate limits, field lengths,
size of metadata...
● Very difficult to predict: too high? too low?
● Easier to increase than to decrease once you have users
Limits
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

19. 1. Treat your API as you would treat any other product
2. Always put the developers first, make them want to use your API
3. Once they are using it, consistency and reliability are key
My Top Takeaways
Do not place text, or graphics
in any of the red space
Your faces will be
here
Logo Overlays will
be here
DO NOT DELETE
SaaStr Team will delete these
guides in review.

20. Q&A and Networking
To participate - click “Join us on stage”
(below the player)

21. THANK YOU