Event-sourced architecture, travelling Java -> Scala (Part 2: Threads, connections)

Http sever, threads.

When we are talking about scalability we should always start from IO. It is well reworked during last years, let's look into the history.

HTTP 1.0

Nobody remembers how it was, just the fact that on each call server to client connection was opened and closed. Some overhead of course.

HTTP 1.1

Persistente connections helped to solve the issue with opening closing the TCP connection for each request, now connection can be reused for several request - response sessions.

From the session protocol, until the coming of Web Sockets we weren't expect any possible improvements. Some rework was done on server level:

Event-sourced architecture, travelling Java -> Scala (Part 1: Into)

Intro

I ve been interested with event-sourced approach during previous 3 years. Actually I had the feeling that regular CRUD application isn't the best one candidate to redesign into event-sourced architecture. Previous week my friend shared with me the source code of interesting commercial project - engine for online game. Actually it follows the best practices and even implements the dreams of modern Java coders. Of course there is some legacy code - but project management pushing the team to follow processes based on BDD and TDD, that keeps technical debt in controlled borders. Code is in good shape (well refactored), covered with specs and tests. From the start project had a Java code only - but for now it's migrated mostly to Scala. Of course language is just one of the tools and it's more important to know the whole technology stack. It is: Spray -> Akka -> JPA -> MySQL. In the current moment team is actively looking for the ways of performance improvement. When I reviewed the business of the application - it is the best one candidate for event-sourced approach. Keep the whole instance world as immutable state in the memory - and track all actions as the log.