Finagle is a fault-tolerant, protocol-agnostic RPC system for the JVM, written in Scala and used to construct high-concurrency servers, and it is aimed at JVM engineers who want one uniform client and server API across several network protocols instead of a separate stack for each one.

What it is

Finagle is an extensible remote procedure call framework that runs on the Java Virtual Machine and lives in the Scala ecosystem, published under the Apache License, Version 2.0. Its central design choice is that most of the code is protocol agnostic: protocol-specific pieces plug into shared machinery for connections, hosting, and request dispatch, so implementing a new protocol means writing far less than a full networking stack. On top of that core it exposes uniform client and server APIs for several protocols, with HTTP, HTTP/2, Thrift, Memcached, MySQL, Redis and Zipkin tracing all appearing in its topic list. Documentation is split between a user guide and generated API documentation at twitter.github.io/finagle, and development happens in the open, with the release branch holding the latest stable release and weekly snapshots published from the develop branch.

The concrete problem it solves is protocol sprawl inside a single JVM service. A service that talks to a MySQL database, a Redis cache, a Memcached tier and one or more HTTP or Thrift peers would otherwise carry a separate, separately configured client library for each one, each with its own connection handling, timeouts and retry behaviour. Finagle replaces that collection of bespoke per-protocol clients with a single client and server abstraction, so the calling code looks the same whether the downstream dependency speaks HTTP/2 or a cache protocol.

Key capabilities

• Uniform client and server APIs across multiple protocols, covering HTTP, HTTP/2, Thrift, Memcached, MySQL and Redis according to the project's topic list.
• A protocol-agnostic core that makes most of the codebase shared, simplifying the implementation of new protocols.
• Fault tolerance as a stated design goal of the RPC system, applied to how calls to downstream services are issued.
• Integration with Zipkin for distributed tracing of requests across services.
• Design targeted at high performance and high concurrency on the JVM.
• Approximately monthly releases published to Maven Central, with artifacts such as com.twitter/finagle-core_2.12.
• A detailed CHANGELOG.rst that documents public API breaks and changes in runtime behaviour, even though semver is not followed.

Who uses it and how

• Twitter runs Finagle in production, and the README lists Foursquare, ING Bank, Pinterest, SoundCloud and Tumblr among adopters, with a fuller list in ADOPTERS.md.
• JVM teams running high-concurrency services that need to fan out to datastores and caches such as MySQL, Memcached and Redis behind one client abstraction.
• Organisations that want the server side of a protocol handled by the same library used for the client side, rather than pairing two unrelated stacks.
• Contributors, who are asked to submit pull requests against develop, with release holding the stable line and weekly snapshots available in between.
• Adopters are invited to add themselves to ADOPTERS.md and open a pull request to do so.

Getting started

Finagle is consumed as a JVM library from Maven Central under the com.twitter group, for example finagle-core_2.12; the README points to the user guide and API documentation sites for setup detail, and no standalone binary, Docker image or compose file is described.

How it compares

No comparable or competing tools are named in the facts provided for this project, so there is nothing here to contrast it against. It stands alone in this registry on the evidence available, and any comparison would have to wait until another RPC framework is listed alongside it.

When to use it — and when not to

Finagle suits teams already committed to the JVM and Scala or Java, who can absorb a library dependency and read the changelog before each upgrade, because semver is not followed and public API breaks are expected between releases. A self-hoster operates nothing extra in the way of databases, object storage or SMTP, since Finagle is a library rather than a service, but they do own their JVM build, dependency versions and the tracing infrastructure behind Zipkin if they enable it. Teams outside the JVM, or those wanting a packaged deployable, should not pick it: the facts show no container image, no release binary and no hosted offering, only Maven Central artifacts.