Every software engineer should learn about the Actor Model, even if they don't work with Erlang, Elixir or Akka. It opens up your mind to a new way of thinking about computation and concurrency. And what better way to learn than to hear from its inventor, Carl Hewitt (R.I.P)? This conversation between Carl, Erik Meijer (of the Rx fame) and Clemens Szyperski is a must-see! An actor is the fundamental unit of computation which embodies the 3 things – processing, storage and communications – that are essential to computation. Actors come in systems, and they have addresses so that one actor can send messages to another actor. Every actor has a mailbox, and when an actor receives a message, it can:
Multiple messages might arrive in the mailbox at the same time, but they are processed one at a time. An arbiter decides the order in which these messages are processed. So, inside the body of an actor, there is no concurrency because messages are processed one at a time. The best way to experience the Actor Model is to spend time with Erlang, Elixir or Akka. F#'s MailboxProcessor also implements a similar idea. Looking beyond code, you can also see the same pattern in AWS Lambda! Where a Lambda execution environment handles only one event at a time, and concurrency is managed at the platform level. |
Join 12K readers and level up you AWS game with just 5 mins a week. Every Monday, I share practical tips, tutorials and best practices for building serverless architectures on AWS.
One of the most misunderstood aspects of Lambda is how throttling applies to async invocations. Or rather, how it doesn't! Every Lambda invocation has to go through its Invoke API [1], whether you're invoking the function directly or through an event source such as API Gateway or SNS. With the Invoke API, you can choose invocationType as either "RequestResponse" (i.e. synchronous) or "Event" (i.e. asynchronous). Synchronous invocations With synchronous invocations, throttling limits are...
When it comes to building event-driven architectures on AWS, EventBridge has become the de facto service for ingesting, filtering, transforming and distributing events to their desired destinations. It provides a standard envelope encapsulating each event, including metadata like the source, detail type, and timestamp. These fields are useful, but I'm gonna give you several reasons why you should wrap your event payload in its own envelope. For example, like this: 1. Clear separation between...
Years ago, I worked at a large e-commerce company that was one of the biggest food delivery services in the UK. They did something very interesting - they regularly ran load tests against production using fake orders. As a partial observer, here's what I think we can learn from this practice and how it partially caused the biggest outages they ever experienced (but not from the load test itself!). Load Testing in production As a food delivery service, they experienced large traffic spikes...