Following are the general design principles for desiging aws Lambda and serverless applications.
Single Purpose
Your function should be concise, short, simple, single purpose, follows Single-Responsibility-Principle.
No monolithic Lambda Functions
Your function should not have internal branching logic, which makes them Monolithic, harder to change and maintain.
State Machines for Orchestration
Chaining Lambda executions within the code to orchestrate the workflow of your application results in a monolithic and tightly coupled application. Instead, use a state machine to orchestrate transactions and communication flows.
Share nothing
Function runtime environment and underlying infrastructure are short-lived, therefore local resources such as temporary storage are not guaranteed.
State can be manipulated within a state machine execution lifecycle.
Persistent storage is preferred for highly durable requirements.
For Scalability, Think concurrent requests
Serverless applications take advantage of the concurrency model and tradeoffs at the design level are evaluated based on concurrency.
Assume no hardware affinity
Underlying infrastructure may change. Leverage code or dependencies that are hardware-agnostic as CPU flags, for example, may not be available consistently.
Design for failures and duplicates
Operations triggered from requests/events must be idempotent as failures can occur and a given request/event can be delivered more than once. Include appropriate retries for downstream calls.
Use events to trigger transactions
Events such as writing a new Amazon S3 object or an update to a database allow for transaction execution in response to business functionalities. This asynchronous event behavior is often consumer agnostic and drives just-in-time processing to ensure lean service design.