Go architectures · 3 MIN READ
Serverless handlers: bounded work and retry-safe effects
Separate invocation mechanics from deterministic application behavior.
Separate invocation mechanics from deterministic application behavior. A function platform manages execution capacity while your handler processes an invocation. Trace the worked Go example, then compare the benefit with the cost before applying this design to your own project.
Architecture · A MAP OF THE IDEA
- Platform supplies an invocation
- Pure handler validates and computes
- Adapter writes the response or durable effect
Useful when
- Tasks are bounded and traffic varies
- Managed invocation scaling is valuable
Watch out
- Invocation limits and cold starts affect design
- Retries require idempotent durable effects
Implementation & operation cost: Medium to high
Fit depends on the task
Editorial suitability, not benchmarks or a universal ranking. Styles describe different axes and can be combined.
The design decision
A function platform manages execution capacity while your handler processes an invocation. Keep durable state outside the process and assume a retry policy may invoke the same logical work again. Provider limits, cold starts and event semantics belong in the design.
A complete Go example
Read this program from the entry point and follow the calls shown in the diagram. The output is included at the end so you can check the behavior without a compiler.
package main
import (
"errors"
"fmt"
"strings"
)
type Event struct{ Name string }
func Handle(e Event) (string, error) {
name := strings.TrimSpace(e.Name)
if name == "" {
return "", errors.New("name required")
}
return "Hello, " + name, nil
}
func main() {
message, err := Handle(Event{Name: " Ada "})
fmt.Println(message, err)
}
// Output:
// Hello, Ada <nil>
Handle is pure application behavior, independent of a provider SDK. An outer adapter decodes the event and serializes the result. Moving a side effect into this function would require an idempotency policy, not a process-global seen map.
Tradeoffs and the simpler alternative
Functions suit bounded event-driven tasks and variable workloads. Long-running connections or strict latency targets may favor a continuously running service. Check the chosen platform’s actual Go runtime, resource limits and billing; serverless does not mean operations-free.
Keep a handler independent of a warm process
Treat process memory as a disposable cache, not the authoritative record of a completed job. Reused instances may retain state between calls while new instances begin empty. Validate input and obtain a durable idempotency key for retried operations. Bound execution time, payload size and concurrency. A serverless function is a deployment unit; the same clean application service can also run in an ordinary HTTP server.
Design retry-safe external effects
A queue-triggered handler may be invoked again after a timeout or lost acknowledgement. Persist progress and use the external provider idempotency mechanism when available. A local done map does not survive another instance. If an effect succeeds but recording success fails, the retry must reconcile rather than blindly repeat. Connection pools and downstream database capacity need limits because rapid function scaling can overwhelm a shared dependency.
Measure the real operational fit
Observe cold and warm latency, failures, throttling, queue age and per-invocation cost. Test execution with no warmed globals and interrupted work, not only by calling the function twice inside one test process. Use serverless for bounded independently triggered work where its scaling and operations model fits. Long-lived connections, latency-sensitive steady load or complex coordination may be simpler in a service or worker.
TAKE THIS WITH YOU
Processes bounded invocations with external durable state. Functions suit bounded event-driven tasks and variable workloads. Long-running connections or strict latency targets may favor a continuously running service. Check the chosen platform’s actual Go runtime, resource limits and billing; serverless does not mean operations-free.
Check your understanding
Which statement best describes Serverless handlers: bounded work and retry-safe effects?
Go to the source
Progress stays in this browser. No account needed.