EP226: API Concepts Every Software Engineer Should Know

Autonomous Software Development for the Enterprise (Sponsored)

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.

Try on your codebase today

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
• 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 ... 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

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

Join Rebuild YouTube with AI →

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?