Serverless Patterns

Here is an overview of the most common serverless patterns use cases & characteristics.

Simple Web Service

Use Case
- A client needs to consume a specific service via a public or private API.
Characteristics
- Popular scenario for serverless n-tier apps.
- Classic par of a layered architecture.
- Data connections need to be managed.
- High-concurrency. Scales nicely.
- Needs to be stateless.
- Sessions should be watched.

Use Case
- As we break out the monolith, different services have to interact and we want to avoid bottlenecks, synchronous i/o, and shared state. Asynchronous messaging is the foundation for most service integrations.
Characteristics
- A service that distributes events to subscribed services.
- As new services are created, they can subscribe as well.
- A well defined API for other services and systems to interact with.

Use Case
- In a cloud-based application, components of the system need to provide information to other components as events happen. Asynchronous messaging enables applications to announce events to multiple interested consumers without coupling.
Characteristics
- Services “publish” events thru a channel as messages.
- Multiple interested consumers listen to the events by "subscribing" to these channels.
- Decouples services that need to communicate, but can evolve and focus their core capabilities.
- Infrastructure is responsible for ensuring a single message is delivered to multiple interested parties reliably.

Use Case
- A client needs to consume different services. Because each service might have different endpoints, belong to different teams, and/or have different release cycles, having the client manage these connections can be challenging.
- This can be also known as API Gateway.
Characteristics
- Single point of entry for clients.
- Routes requests to other services based on routes, methods, and endpoints.
- Other services can be lambda functions, external APIs, microservices, etc.
- Exposes internal APIs to external clients.
- Allows for incremental updates, rolling releases, and parallel versioning.

Use Case
- A client might have to make multiple calls to various backend services to perform an operation. This chattiness can impact performance and scale.
Characteristics
- Single point of entry for clients.
- Collects and stores individual responses as they arrive.
- Aggregates the response of downstream services and returns a combined response.

Use Case
- As time goes by systems to grow and evolve, complexity increases and adding new features can be challenging. Completely replacing the system can take time, and starting from scratch is almost always a bad idea.
- Gradual migration to a new system, while keeping the old system to handle the features that haven’t been migrated is a better option. But that means clients need to know about both systems and update every time a feature has been migrated.
Characteristics
- A façade intercepts requests to the service and routes them either to the legacy app or the new service(s).
- Consumers continue to use the same interface, unaware of the migration.
- Minimizes the impact of the migration. Risk is reduced as roll-backs are easy.

Use Case
- Traffic can be unpredictable sometimes, some services cannot scale when there’s an intermittent heavy load. Peaks in demand can cause overload, flooding downstream services causing them to fail. Introducing a queue between the services that acts as a buffer, storing the messages allowing consumers to process the load at their own pace.
Characteristics
- A queue decouples tasks from services, regardless of the volume of the request to less scalable backends like RDS, MongoDB or a third party service.
- Workload is controlled using low concurrency on the consumer side. The number of workers can be adjusted as needed.
- If a task expects a reply from a service, a mechanism needs to be implemented to send a response.

Use Case
- A continuous stream processor to capture data or events. Distributes the data to different services or data stores.
Characteristics
- Continuously processes streams of data or events as they come.
- Scales quickly to meet demand of large volumes of data.
- Parses the events, and applies business logic to transform, analyze, or distribute data.

Use Case
- It’s very common with read-heavy applications to hit the limits of downstream services. Caching data and creating specialized views of the most queried data can help mitigate the impact of a read-heavy service.
Characteristics
- Loading data on demand into in-memory cache. Priming the cache, lifetime of data, and cache-eviction should be taken into consideration when designing the services.
- Specialized views:
  - With Index Tables the data is replicated in a new table using specialized indexes for common queries.
  - With Materialized Views the data is replicated and formatted for efficient query and display of common queries.

Use Case
- Large jobs or tasks can easily exceed the execution time limit on Lambda functions. Using a divide-and-conquer strategy can help mitigate the issue. The work is split between different lambdas workers.
- Each worker will process the job asynchronously and save its subset of the result in a common repository. The final result can be gathered and stitched together by another process or it can be queried from the repository itself.
Characteristics
- Fan-out/Fan-in refers to breaking a task in subtasks, executing multiple functions concurrently, and then aggregating the result.
- The Fan-out pattern messages are delivered to workers, each receives a partitioned subtask of the original task.
- The Fan-in pattern collects the result of all individual workers, and aggregates them.