Application / API service
Stateless business logic that handles requests and calls data stores and other services.
Problem it solves: Encapsulates domain logic; stateless instances can be added horizontally.
Where it sits: Behind the LB/gateway; calls caches, databases, queues and other services.
When to use
- Any request-handling logic.
When not to use
- Long-running or bursty background work — move it behind a queue.
Failure modes
- Saturation: latency rises sharply as utilisation approaches 100%.
- Synchronous dependency chains multiply failure probability.
Metrics to watch
- Throughput (req/s)
- Utilisation (%)
- p50/p95/p99 latency (ms)
- Error rate (%)
Alternatives
- Serverless function
- Microservice split
Configuration in Labs (illustrative defaults)
- Instances (count) = 2 — Identical copies behind this logical component. Capacity scales linearly in this model.
- Capacity per instance (req/s) = 500 — Maximum requests one instance completes per second before it saturates.
- Base service time (ms) = 20 — Processing time per request at zero load. Queueing adds to this as utilisation rises.