Fastify performance model

Fastify optimizes the HTTP hot path: schema-based response serialization avoids generic `JSON.stringify`, the router uses a low-overhead radix tree, and plugin encapsulation limits decorator lookup scope. Benchmarks help, but measure your own workload.

					fastify.get('/users/:id', {
  schema: {
    params: { type: 'object', properties: { id: { type: 'string' } } },
    response: {
      200: {
        type: 'object',
        properties: {
          id: { type: 'string' },
          email: { type: 'string' },
        },
      },
    },
  },
}, handler);
				

Performance gains require response schemas — without them Fastify falls back to slower paths. Avoid sync CPU work in handlers; use hooks sparingly on hot routes. `@fastify/compress` and logging add latency — enable deliberately.

On interviews: why schema serialization beats manual JSON, when Fastify versus Express trade-offs matter (throughput-sensitive APIs), and that premature framework switching without profiling is weak engineering.

Common pitfalls: claiming Fastify is always faster while skipping response schemas, heavy per-request logging on hot paths, and blocking the event loop in handlers.

Checklist:

• Add response schemas on high-traffic routes.
• Profile before choosing framework for speed.
• Keep handlers async and non-blocking.
• Scope plugins to reduce decorator overhead.