Case Study 03
A Shared Platform Library for ~20 Services
The problem
Once a dozen-plus services existed, the same concerns — database connection handling, caching, file storage, rate limiting, security headers, authentication — were being re-implemented in each one, slightly differently. That meant inconsistent behaviour, duplicated bugs, and a security fix having to be applied by hand in twenty places. Cross-cutting concerns needed to become a single upgrade point.
The library
A versioned TypeScript library, published to a private registry and consumed by every service, provides one hardened implementation of:
- Database — a resilient MongoDB connection with retry, back-off and health-aware startup.
- Cache — a Redis client that is Sentinel-aware for high availability, with an in-memory no-op fallback for offline local development.
- Storage — a provider-agnostic interface over Google Cloud Storage and Azure Blob, with signed-URL access.
- Rate limiting — layered per-IP, per-device and per-user limits backed by Redis.
- Security headers — Helmet with a per-request nonce Content-Security-Policy.
- Internal auth — the HMAC-signed, replay-protected service-to-service signing and verification described in the auth case study.
- Identity primitives — access-token verification, signed device identity, session heartbeat, input sanitisation, and mobile attestation.
Why it matters
This is the difference between a collection of services and a platform. A security improvement — a stricter CSP, a new rate-limit tier, a hardened token check — is written once and reaches every service through a single version bump, instead of being re-implemented (and mis-implemented) service by service. New services start hardened by default, which is what let one engineer keep twenty of them consistent and secure.
A companion shared frontend component library gives the applications the same consistency on the client — shared session handling, guards, and UI primitives.
Outcome
Roughly twenty services share one implementation of their most important cross-cutting concerns. Security and reliability became properties of the platform rather than per-team effort — the defining trait of an internal developer platform.