akka streams – viktor klang – qcon

This is part of my live blogging from QCon 2015. See my QCon table of contents for other posts.

Streams are:

  • Ephemeral – time dependent
  • Possibly unbounded in length
  • Focus on transformation and transformation of data

Programming involves moving things from A to B and changing the bytes along the way.


  • message oriented programming model for reactive apps
  • can be used from Java or Scala.


  • unit of proessing a called an Actor
  • component with address, mailbox, current behavior and storage
  • No CPU cost if actor doesn’t have someting to do. Only use a few bytes each so scale well
  • Each actor has a parent- handling for failures

Akka Streams

  • Higher order abstraction for concurrency
  • Solving the 100% case is impossible and 90% case is hard. Akka focuses on 80% case. Solve most problems
  • Immutable, reusable, composable, coordinated, async transformations.
  • Flows – one input and one output. Not connected to source or destination. Like a reusable pipe. Goal is to describe the transformation.

Types of transformations

  • Linear Time-agnotistic -ex common ones like map
  • Linear Time sensitive – ex dealing with infinite streams
  • Linear Rate detached – ex how deal with buffering
  • Linear Async – ex calling a service
  • Non-linear – ex binary flow (two inputs going to two outputs), custom stages

Sources – publisher, iterator, future, etc

Sinks – subscriber, foreach/fold/onComplete, ignore, head, etc

Fan in/fan out – merge, zip, etc

Output/Input – Http, tcp, InputStreamSource/OutputStreamSink blocking wrappers, etc

Materialization – taking description of transformation and making it run. Streams are blueprint. Materializer makes it run. Cycles are allowed. Look for troublesome ones.

If can’t solve problem without programming; wnt be able to solve it without programming. Why would be able to tell a computer how to do something if we don’t understand it either.

Push vs pull

  • Want to get data across async boundary without blocking back-pressure.
  • When pushing data, have to drop if get it too fast.
  • “A slow solution is no solution”
  • Pull can be slow
  • Better: Two way channel – only push when know ready. Know what needed based on requests. Don’t demand 100 ice creams unless know what to do with them. Switching between push/pull and batching requests when know about related ones. Called “dynamic push pull”

Also see The Reactive Streams Initiave

Impressons: good talk; learned a lot. Both about Akka and conceptually. Glad I’m comfortable with the basics of functional programming so it wasn’t overwhelming.

Leave a Reply

Your email address will not be published. Required fields are marked *