A practical backend engineering roadmap with interactive explainers and visualizations.
Topics include networking, HTTP, databases, queues, caching, distributed systems, and real-world outages.
Feedback welcome.
Hi, everybody!
Today I decided to cover 12-factor app.
If it's still actual or now. Ended up with 23 factors (2x times more).
https://medium.com/@sadensmol/learning-system-design-11-the-many-factor-app-why-12-factors-are-not-enough-in-2026-3b2b60f02acd
Welcome to comments (if interested!)!
Curious how backend teams here think about modularity at scale.
At what point does a backend stop feeling like a system and start feeling like a pile of scripts, SDK wrappers, env files, auth handlers, retries, queues, webhooks, and debugging tools duct-taped together?
Feels like most teams eventually reinvent an internal layer just to keep everything connected and observable.
What tradeoffs are you actually willing to tolerate to get that modularity?
Extra latency from a middle layer?
Routing calls through a third party?
Some vendor lock-in?
Less direct control over infrastructure?
I keep wondering what “true modularity” for backend systems would actually look like.
Like if services, APIs, queues, databases, auth providers, workflows, and internal tools could just connect together predictably — and you could actually see everything happening in one place. Every request, retry, event, failure, webhook, transformation, credential, and flow.
Less plumbing. Less scattered scripts. Less hidden infrastructure logic. More composable systems.
It’s something I’ve been working on lately and I’m curious whether other backend engineers are interested in this direction too
I've been rethinking how to limit the impact of AI slop in my projects and decided each app should do one thing only.
This has let me build a tightly coupled permission and documentation system.
Capabilities are documented in plain English and are attached to permissions, so when a plan grants you capabilities, they are listed on the subscribe page.
The app you see isn't the product, it's just a demo and there's no way to pay. I'm keen to showcase the functionality which is a little difficult in screenshots so I'll explain.
Every single plug is its own Go application which connects to a NATS JetStream server. They all communicate in this way and can be on different servers. I can work on one feature without breaking everything.
If that feature breaks, I simply make it again. I keep them really small.
The coolest thing is each new feature I add is exponential: if I add WhatsApp support with plug-wa (WIP), all the other plugs will be able to have WA as an interface. So I make one thing, and can use it in many ways.
I'm really enjoying the ChatGPT integration which lets me access my Obsidian notes synced with Syncthing -- I can make plans and write to Obsidian and then amend them on my phone and computer, then have a separate agent do the work.
It's all possible because of trust boundaries. plug-mcp exposes capabilities as tools, and plug-chatgpt allows ChatGPT to access plug-mcp. Everything is tiny. plug-syncmd just writes markdown to a directory, but together they let me plan and work effectively.
I've also binned off containers and switched to AppArmor, now when agents try to implement unsafe inter-plug communication, it doesn't work. They can't see each others secrets, they are simply invisible.
Keen to hear your thoughts & whether I'm reinventing the wheel because it doesn't seem that new to me
The auth service is working perfectly on its independent api
But when I connect it to the api gateway it gives a 404 error I have tried everything and changed the application.properties multiple times but no solution.The spring version is 4.0.6 and the cloud version is 2025.1.1
Help me please