Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
77 lines (48 sloc) 4.27 KB

Step 5 - Which API or SDK to use

This getting started guide shows you how to get started with Event Store using the Atom publishing protocol as the primary interface. This final step covers the different APIs, and client SDKs Event Store has available with the aim of helping you choose which one suits your use case.


Event Store offers a low-level protocol in the form of an asynchronous TCP protocol that exchanges protobuf objects. At present this protocol has adapters for .NET and the JVM.

Event Store Supported Clients

Community Developed Clients


Event Store also offers an HTTP-based interface, based specifically on the AtomPub protocol. As it operates over HTTP, this is less efficient, but nearly every environment supports it.

Event Store Supported Clients

Community Developed Clients

If you have a client to add, click the 'Improve this Doc' link on the top right of the page to submit a pull request.

Which to use?

Many factors go into the choice of which of the protocols (TCP vs. HTTP) to use. Both have their strengths and weaknesses.

TCP is faster

This speed especially applies to subscribers as events pushed to the subscriber, whereas with Atom the subscribers poll the head of the atom feed to check if new events are available. The difference can be as high as 2–3 times higher (sub 10ms for TCP, vs. seconds for Atom).

Also, the number of writes per second supported is often dramatically higher when using TCP. At the time of writing, standard Event Store appliances can service around 2000 writes/second over HTTP compared to 15,000-20,000/second over TCP. This increase might be a deciding factor if you are in a high-performance environment.

AtomPub is more scalable for large numbers of subscribers

This scalability is due to the ability to use intermediary caching with Atom feeds. Most URIs returned by Event Store point to immutable data and are infinitely cachable. Therefore on a replay of a projection, much of the data required is likely available on a local or intermediary cache. This can also lead to lower network traffic.

Atom tends to operate better in a large heterogeneous environment where you have callers from different platforms. This is especially true if you have to integrate with different teams or external vendors. Atom is an industry standard and well-documented protocol whereas the TCP protocol is a custom protocol they would need to understand.

Most platforms have good existing tooling for Atom including feed readers. None of this tooling exists for analyzing traffic with the TCP protocol.

[!NOTE] Our recommendation would be to use AtomPub as your primary protocol unless you have low subscriber SLAs or need higher throughput on reads and writes than Atom can offer. This is due to the open nature and ease of use of the Atom protocol. Often in integration scenarios, these are more important than raw performance.

Next Step

Congratulations! You've reached the end of our getting started guide, what's next?