This talk describes how to implement Event-Driven Microservices with examples in F#. It starts with introducing Domain Driven Design to create Microservices boundaries. Using Discriminated Unions (F#'s Algebraic Data Types), the domain model can be captured as code eliminating the need for separate documentation. Moreover, using Computation expressions (F#'s Monads), one can model custom workflows easily.

It then introduces event-driven architecture, where every external action generates an event that the system responds to. Events act as the notification messages for any significant change in state and may generate other event(s) as services invoke each other. They are immutable by nature.

An explanation on why 2-phase commits cannot be used in Microservices having their own databases. Further the talk explains, how Event Driven Architecture solves this problem in an eventually consistent manner without sacrificing availability or partition tolerance. Distributed Sagas as a protocol for coordinating Microservices is introduced and its implementation in F# is also provided.

Event Sourcing can be used to model the system state. Event sourcing models the state of entity as a sequence of state-changing events. Whenever the state of a business entity changes, a new event is appended. List fold operation is ideal for implementing Event sourcing where the application reconstructs an entity's current state by replaying the events. An example with F#'s List.fold is provided.

Some aspects of evolutionary architecture are also discussed, particularly on how to evolve Microservices interface. F#'s Type providers can be used for the same though there are alternate approaches using Apache Thrift/Google Protobuf (They don't have support for F# but they do have support for C#, which F# code can leverage).

Events and their responses can be very easily modeled with Discriminated Unions. Data immutability captures the behavior of these events, since events are immutable by nature. A service can be thought of as a function that accepts an event (input) and gives back a response (output). A service may call other services, which is equivalent to a function calling other functions or even Higher-Order functions.

Immutability allows infinite scalability as it eliminated the need to worry about a mutex, a lock, or a race. As functional code is much more terse compares to object-oriented code, it provides productivity benefits. Its strict typing makes writing correct code easy as mismatch of types are caught at compile time.

Most of the services are implemented as set of pure functions. These functions which have no internal state, where outputs depend only on inputs and constants and it is very easy to test such functions. The absence of internal state means that there are no state transitions to test. The only testing left is to collect a bunch of inputs that tests for all the boundary conditions, pass each through the function under test and validate the output.

The objective of the talk is to show how to create a scalable & highly distributed web service in F#, and demonstrate how various characteristics of functional paradigm captures the behavior of such services architecture very naturally.