Lifestyles are systems
Two people can have the same body and the same skills, yet live completely different lives: one is running a rat race, one is living in peace, one is just chilling. Their health depends on matching their habits to their life. Systems are the same. The same kind of services need very different designs depending on the life they lead.
The three main lifestyles
| 🏃 Rat race | 🧘 Living in peace | 😎 Just chilling | |
|---|---|---|---|
| Traffic | Very high, spiky, unpredictable bursts | Moderate, steady, predictable cycles | Very low, occasional |
| Latency expectations | Strict — every millisecond counts | Reasonable | Relaxed |
| Cost of failure | Huge (lost sales, angry crowds) | Moderate | Low |
| Main risk | Burnout: overload and cascading failure | Slow decay: complexity, drift | Neglect: forgotten, insecure, surprise costs |
| Design priority | Resilience under pressure, backpressure, performance | Balance, maintainability, efficiency | Minimal cost and effort |
| Examples | Flash sales, concert tickets, trading, food delivery at dinner, exam results day | B2B SaaS, HR/payroll, back offices, steady e-commerce | Personal apps, internal tools, prototypes, nightly reports |
Questions that reveal a system's lifestyle
- What does traffic look like over a day, a week, a year? Spikes, cycles, flat?
- What happens if it's slow for a minute? Down for an hour? Who suffers, and how much does it cost?
- How fast must it respond? Human-noticeable latency, or batch overnight?
- How much does idle time cost with the current design?
- Who looks after it? A dedicated team, or someone who checks once a month?
Lifestyles can change
A personal side project (chilling) gets featured on social media and suddenly lives a rat race for a weekend. A startup's MVP becomes a peaceful SaaS. Serverless designs are good at changing lifestyles because scaling is automatic — but limits, costs and failure modes still need thought.
Ask "what life will this system live?" before choosing settings. The same Waiter construct can be configured for a rat race, a peaceful life or a lazy Sunday — the next chapters show how.
A lifestyle setting in your DNA
You can make lifestyle an explicit input to your constructs, so the choice is visible and reviewable:
export type Lifestyle = "ratRace" | "peace" | "chilling";
export interface WaiterProps {
eventBus: events.IEventBus;
api: apigw.HttpApi;
lifestyle: Lifestyle;
}
Inside the construct, the lifestyle decides concurrency, capacity mode, alarms and log retention — covered in each lifestyle chapter.
Senior Full-Stack Engineer · AI & AWS. I design and build serverless systems on AWS — and love explaining them simply.