From UI Lead to Backend Lead: A Learning Path

Most of my career has been on the front end: leading UI development for platforms, building real-time trading interfaces, running a UI guild. Increasingly, the problems I find most interesting sit on the other side of the API: how data is modelled, how state is synchronised, how services fail. I’d like to grow towards back-end leadership.

This note is my plan, written in public so I keep myself honest. It is a learning path, not a list of things I’ve mastered.

What I already bring

Leading front ends for platforms has meant a lot of time at the boundary with back-end teams:

• API design and contracts. Defining API contracts with back-end teams through OpenAPI, typing the data layer, and arguing about pagination, error shapes and bulk operations (API Modelling, REST API Design Trade-offs: Bulk Deletes, Request Bodies and Cancellation).
• Some real server-side work. Python API endpoints and database aggregation for a workflow platform, and a Node.js tool that migrated whole sites between CMSs with batching and resumable runs (A Resumable CMS Migration Tool).
• JVM roots. Java and Kotlin at university, from coursework to algorithms like seam carving, so the JVM isn’t a new language for me, just one I haven’t used professionally yet (Spring and Java, Refreshed).
• Gateways and security. Putting an API gateway in front of a platform’s services: versioned routes, mutual TLS, CORS in one place, throttling (Rolling Out an API Gateway). Secret scanning and security checks in pipelines.
• Real-time protocols. WebSockets, SSE, polling, and the snapshot-and-delta sync behind live trading screens (Snapshot and Delta Sync over WebSockets, Designing Snapshot and Delta APIs).
• Migrations without big bangs. Incremental migrations, from a TypeScript clean-up to a CMS move (Progressive Overload and Incremental Migration).
• Distributed-systems fundamentals. University study and notes on consensus, failure and delivery guarantees (The Consensus Problem, Message Delivery Semantics, Fallacies of Distributed Computing).
• Leadership. Leading teams, running communities of practice and handing systems over cleanly (Knowledge Transfer Before Moving On). That part transfers directly.

What I’m learning next

Laid out like a skill tree (Skill Trees as Platform Capability Maps): foundations first.

Foundations

• Data modelling. Relational design, normalisation and when to break it, modelling money, time and versions.
• PostgreSQL in depth. Indexes and query plans, transactions and isolation levels, migrations without downtime.
• The JVM and Spring. I work alongside Java services day to day and wrote Java and Kotlin at university, so this is the obvious place to start: getting back into it, now with Spring Boot (Spring and Java, Refreshed).

Core

• Queues and event streams. Kafka-style logs versus work queues, consumer groups, ordering, and exactly-once in practice versus theory.
• Reliability. Timeouts, retries with idempotency keys, circuit breakers, backpressure (The Node.js Event Loop, Streams and Backpressure).
• Observability from the server side. Tracing, SLOs and error budgets (SLA vs SLO vs SLI, Observability).

Applied

• Service ownership. On-call, runbooks, capacity planning, cost.
• Designing for audit and change. Event history, versioned writes, schema evolution.
• Leading a back-end team: technical direction, review standards and architecture decisions (Architecture Decision Records).

How I’ll learn it

• Build something real end to end. A small service with a real database, a queue and a streaming API, deployed and observed, rather than isolated tutorials.
• Read production code in the services I already work next to, and ask the people who own them.
• Pair across the boundary. Take back-end tickets that touch the APIs I consume.
• Write it down here, so every topic ends as a note I can be questioned on.

Why the front end is a good starting point

The front end is where the consequences of back-end decisions land. I’ve spent years living with snapshot formats, missing sequence numbers, dropped request bodies and money calculated in the wrong place. That gives me strong opinions about what a good API feels like to consume. Now I want the depth to build one.

I’ll update this note as each node gets unlocked.