Hardening Logging in a Fintech API

Problem/Feature Description

A fintech startup runs a Fastify REST API that handles payments, account lookups, and user authentication. During a recent compliance audit, the security team found two serious issues in the production logging setup.

First, raw sensitive fields are appearing in log output. The audit team pulled log samples and found entries containing plaintext passwords submitted in login requests, API keys in query parameters, and raw Authorization header values. This is a data protection violation and needs to be fixed before the next regulatory review.

Second, the logging style is inconsistent. Some developers log strings with variable interpolation ("User " + userId + " logged in"), others use template literals, and a few use console.log directly. This makes the logs impossible to search or aggregate in the company's log management tool, which expects structured JSON records with discrete fields.

You have been asked to build a clean Fastify application skeleton that demonstrates how logging should be set up across the codebase. The setup must redact sensitive information automatically at the logger level, enforce structured log output, make the log verbosity configurable for each environment without code changes, and use request-scoped loggers in route handlers so that every log line is correlated with its request. The application should also show how library/service code outside the request lifecycle should create its own logger with identifying context.

Output Specification

Produce the following files:

• package.json — with type: "module" and scripts to install dependencies and run the app
• src/app.ts — Fastify application factory. This file must contain the logger configuration, including redaction rules. Export a buildApp function that accepts no arguments and returns the configured Fastify instance
• src/plugins/user-service.ts — a simple service module (not a Fastify plugin) that provides two functions: createUser(email, name) and getUser(id). These functions do not need a real database — use in-memory Maps. The service must use its own logger with identifying context that is created from the application logger
• src/routes/users.ts — a Fastify route plugin containing at minimum POST /users (creates a user) and GET /users/:id (retrieves a user). Route handlers must log meaningful events using the request-scoped logger, not with global or module-level loggers
• logging-notes.md — a brief document (bullet list is fine) describing: what categories of data are being redacted from logs, how to change the log verbosity in a deployment, and why string interpolation in log calls is avoided

The application does not need to connect to a real database or external service. Focus entirely on the logging configuration and patterns.