Video: https://www.youtube.com/watch?v=ttmuN8hPQLA From: http://finagle.github.io/finaglecon/

1. Finagle @ SoundCloud
Phil Calçado
SoundCloud

4. > 11 hours of audio uploaded
every minute
~ 300 million people every month

6. some more micro
than others

7. ~100 services
~130 engineers

8. each service has a cost
we need to reduce
fixed cost

9. 1) complexity cost

11. edge
value-added
foundation

12. edge
value-added
foundation
api-web
user-profile
user-metadata playlists
api-android

14. • Building in Scala
should be a no-brainer
• Building in other JVM
languages should be
easy
• Building in something
else should be possible

15. 2) setup cost

17. +

19. 3) RPC cost

21. the only thing these
things had in common
was HTTP+JSON

22. typical flow
1. Get the IDs of all tracks by an
artist
2. For each ID:
2.1.Get track metadata from X
2.2.Get usage permissions from Y
2.3.Get comments from Z
3. Return list to client app

23. typical flow
1. Get the IDs of all tracks by an
artist
2. For each ID:
2.1.Get track metadata from X
2.2.Get usage permissions from Y
2.3.Get comments from Z
3. Return list to client app
parallel concurrent

24. what to use?

27. lots of resistance
> That said, my overall critique of
> [Finagle] is that I feel a lot of
> their published implementations are
> exceptionally complicated for the
> problem domain or entail a bunch of
> onerous transitive dependencies.

28. ultimately…

29. …the only three things
you need to understand

30. basically

31. Actual
Feature
Request Validator
User

32. Authentication Geo IP Rate Limiting
Available
Features
Actual
Feature
User

33. Actual
Feature
User
Filters
Service
}

34. we use filters a lot

35. 10 services + 42 spans +
3 levels deep: 92ms

36. REST is always
good enough.

37. or is it?

38. migrating to thriftmux

39. where we don’t
follow the "defaults"

40. DNS for service discovery
with SRV records

41. Prometheus.io for metrics

42. twitter-server jvmkit

43. verify new versions of
Finagle

44. Q&A