EP226: API Concepts Every Software Engineer Should Know

ByteByteGo's system design newsletter EP226 outlines five defenses against prompt injection, which it notes tops the OWASP LLM Top 10, splitting them into model-level techniques such as spotlighting and instruction hierarchy and system-level techniques such as least-privilege tools, human-in-the-loop approval, and a planner/executor split. The same issue covers API design fundamentals including REST, GraphQL, gRPC, webhooks, and WebSockets, plus authentication via API keys, OAuth, and JWTs, and announces a "Rebuild YouTube with AI" course running September 26 through October 24, 2026. A sponsored section promotes Blitzy, an autonomous software development tool that can reverse-engineer up to 1 million lines of code and generate up to 25,000 lines of end-to-end tested code.

Autonomous Software Development for the Enterprise Sponsored https://go.bytebytego.com/Blitzy 091926 Blitzy is built for large, complex software projects that other coding agents cannot handle: new feature development, large-scale refactors, scaled vulnerability remediation, and undocumented legacy systems. Blitzy’s Sandbox lets engineers evaluate Blitzy on their own software estate, at their own pace. Eligible organizations can connect real applications, reverse-engineer up to 1 million lines of code, generate up to 25,000 lines of E2E tested code, and surface prioritized security vulnerabilities across their software estate. This week’s system design refresher: - API Concepts Every Software Engineer Should Know - 5 Way to Defend Prompt Injection - New Course: Rebuild YouTube with AI Starts in a Week https://go.bytebytego.com/youtubeai-c1-substack - 12 AI Papers that Changed Everything - Monolithic vs Microservices vs Serverless - 7 Key Load Balancer Use Cases API Concepts Every Software Engineer Should Know Most engineers use APIs every day. Sending a request and reading JSON is one thing. Designing an API that other people can rely on is something where things get complicated. A lot of problems begin with basic HTTP details that seem small at first. Methods, status codes, request formats, and response structure can make an API feel clear and predictable, or confusing and inconsistent. Then there are the bigger design choices. REST, GraphQL, gRPC, webhooks, and WebSockets each make sense in different situations. The challenge is knowing what actually fits the system and the use case. A lot of API problems also comes from design decisions that do not get enough attention early on. Naming, pagination, versioning, error responses, and backward compatibility often decide whether an API is easy to work with or frustrating to maintain. Security is another area where weak decisions can cause real problems. API keys, OAuth, JWTs, scopes, and permissions are easy to mention. Getting them right is harder, and mistakes here can be costly. Reliability matters too. Timeouts, retries, idempotency, rate limits, and caching are often easy to ignore until the system is under pressure. And once an API starts growing, the supporting work matters too. Clear documentation, solid specs, observability, and contract testing make it much easier for teams to trust the API and use it without guessing how it works. Over to you: What’s the most overlooked API concept in your experience? 5 Way to Defend Prompt Injection Prompt injection tops the OWASP LLM Top 10 and there’s no single fix. Instead, you stack defenses, each one catching what the others miss. Defenses come in two families: model-level and system-level. Model-level defenses teach the model to resist injection. - Spotlighting wraps untrusted text in control tags like <UNTRUSTED ...</UNTRUSTED and tells the model to treat anything inside as data, not instructions. - Instruction Hierarchy fine-tunes the model to rank the developer’s system prompt above the user’s message, and both above third-party content. System-level defenses build a system around the LLM that bounds the damage. - Least-Privilege Tools: Give the agent the minimum tools it needs. - Human-in-the-Loop: Require explicit user approval before any sensitive action runs. - Planner / Executor Split: Two separate LLMs. The planner has tool access but never sees untrusted content. The executor reads untrusted content but has no tools. No single defense is enough. Production systems like Gmail stack them, and together they make indirect injection manageable. Over to you: what’s the one defense you’ve seen work in production that isn’t on this list? New Course: Rebuild YouTube with AI starts in a Week https://go.bytebytego.com/youtubeai-c1-substack Rebuild YouTube with AI starts September 26 and runs through October 24, 2026. What you’ll build and learn - Build a functional YouTube clone and ship it to production in five weeks. - Understand how YouTube works , from its core product surfaces to how a real-world MVP can be scoped. - Master AI-assisted development using Cursor agents to plan, implement, review, and recover from bad diffs or dead-end sessions. - Turn AI-generated mockups into working pages and recreate YouTube’s core UI in React. - Build the backend with Postgres, authentication, video uploads, CRUD tooling, and AI-generated seed data. - Add semantic search and related videos using multimodal embeddings while learning how production recommender systems differ. - Deploy to Vercel , track watch time in an admin dashboard, and test features with AI-driven Playwright checks. 📅 Course dates: September 26 – October 24, 2026 12 AI Papers that Changed Everything A handful of research papers shaped the entire AI landscape we see today. The diagram below highlights 12 that we consider especially influential. 1. AlexNet 2012 : Showed deep neural nets can see. Ignited the deep learning era 2. GANs 2014 : Generate realistic image by having two networks compete 3. Transformer 2017 : Google’s “Attention Is All You Need.” The architecture behind everything 4. GPT-3 2020 : OpenAI showed scale unlocks emergent abilities. 5. InstructGPT 2022 : OpenAI introduced RLHF. Turned raw LLMs into useful assistants. 6. Scaling Laws 2020 : Loss follows a clean power law 7. ViT 2020 : Split images into patches and use a Transformer for vision tasks. 8. Latent Diffusion 2021 : Denoising in compressed space. The design behind DALL·E. 9. DDPM 2020 : Add noise, then learn to reverse it. The foundation behind diffusion models. 10. CLIP 2021 : OpenAI connected images and text in one shared space. 11. Chain-of-Thought 2022 : A simple prompt that unlocked complex reasoning. 12. RAG 2020 : Retrieve real documents, then generate. Grounded LLMs in facts. Over to you: What paper is missing from this list? Monolithic vs Microservices vs Serverless A monolith is usually one codebase, one database, and one deployment. For a small team, that’s often the simplest way to build and ship quickly. The problem arises when the codebase grows. A tiny fix in the cart code requires redeploying the whole app, and one bad release can take down everything with it. Microservices try to solve that by breaking the system into separate services. Product, Cart, and Order run on their own, scale separately, and often manage their own data. That means you can ship changes to Cart without affecting the rest of the system. But now you are dealing with multiple moving parts. You generally need service discovery, distributed tracing, and request routing between services. Serverless is a different model. Instead of managing servers, you write functions that run when something triggers them, and the cloud provider handles the scaling. In many cases, you only pay when those functions actually run. However, in serverless, cold starts can add latency, debugging across lots of stateless functions can get messy, and the more you build around one cloud’s runtime, the harder it gets to switch later. Most production systems don’t use just one approach. There’s usually a monolith at the core, and over time teams spin up a few services where they need independent scaling or faster deploys. Serverless tends to show up later for things like notifications or background jobs. 7 Key Load Balancer Use Cases 1. Traffic Distribution: Load Balancers help evenly distribute traffic among multiple server instances. 2. SSL Termination: Load Balancers can offload the responsibility of SSL termination from the backend servers, thereby reducing their workload. 3. Session Persistence: Load Balancers ensure that all requests from a user hit the same instance to maintain session persistence. 4. High Availability: Improves the system’s availability by rerouting traffic away from failed or unhealthy servers to healthy ones. 5. Scalability: Load Balancers facilitate horizontal scaling when additional instances are added to the server pool to handle increased traffic. 6. DDoS Mitigation: Load Balancers can help mitigate the impact of DDoS attacks by rate limiting requests or distributing them across a wider surface. 7. Health Monitoring: Load Balancers also monitor the health and performance of server instances and remove failed or unhealthy servers from the pool. Over to you: Which other load balancer use case will you add to the list?