Beyond Vibe Coding: What Really Happens When Someone Uses Your App?
Part 1 of 10: APIs, Web Traffic & Request Handling
Imagine you just built an online shopping application using ChatGPT, Claude, Cursor, or another AI coding tool.
It looks beautiful. Customers can browse products, add items to their carts, and place orders. You test it with a few friends, and everything works perfectly.
Congratulations! You’ve built an application.
Now imagine that a popular influencer shares your website. Suddenly, 10,000 people visit it within minutes.
Pages become slow. Customers start getting errors. Some orders are submitted twice. Your payment provider temporarily rejects requests because you’ve exceeded its API limits.
Your application worked perfectly yesterday.
What happened?
You have just discovered the difference between building software and engineering software for the real world.
Welcome to Part 1 of our Beyond Vibe Coding series.
1. What Happens When Someone Clicks a Button?
When a customer clicks “Place Order,” several things may happen behind the scenes.
- The browser sends a request over the internet.
- A reverse proxy or load balancer may route that request.
- An API receives and processes the order.
- The application checks inventory and pricing.
- A database stores the order.
- A payment provider processes the transaction.
- The application sends a response to the customer.
For a simple application, some of these steps happen within one server. For a larger application, they may involve multiple services and machines.
Here’s the important part: any one of these steps can fail.
A well-engineered application doesn’t just work when everything goes right. It knows what to do when something goes wrong.
Let’s explore ten important concepts.
2. API Rate Limits: Why You Can’t Make Unlimited Requests
Imagine a restaurant with only five chefs. If 500 customers suddenly order food at the same time, the kitchen cannot serve everyone immediately.
APIs face a similar problem.
An API rate limit controls how many requests a user or system can make within a specified period.
For example, an API might permit 100 requests per minute for a particular client.
What happens when the client sends 500?
The API may reject excess requests with an HTTP 429 Too Many Requests response.
Why this matters for vibe coding: AI-generated applications sometimes call APIs far more frequently than necessary. Without proper rate-limit handling, the app may fail during busy periods or incur unexpectedly high charges.
A good application respects API limits, avoids unnecessary requests, and knows when to slow down.
3. Traffic Load Balancing: Sharing the Work
Imagine a supermarket with one checkout counter.
Even with excellent staff, a long queue develops as the store gets busier.
Now imagine opening five checkout counters and directing customers toward available cashiers.
That’s roughly what a load balancer does.
Instead of sending every request to one application server, a load balancer distributes traffic across multiple healthy servers.
This helps increase capacity and availability.
However, load balancing alone doesn’t guarantee scalability. Your database, application state, and other shared resources must also handle the traffic.
Example: If your application suddenly receives thousands of simultaneous visitors, a properly designed load-balancing setup can distribute incoming requests rather than overwhelming one server.
4. Reverse Proxy Layers: The Reception Desk
A reverse proxy sits in front of one or more application servers.
Think of it as the reception desk of a large office building.
Visitors don’t directly walk into whichever office they want. They approach reception, which directs them to the appropriate destination.
A reverse proxy can:
- Forward requests to the correct application
- Terminate HTTPS connections
- Apply security and traffic controls
- Cache certain responses
- Hide details about internal servers
Popular technologies include NGINX, HAProxy, and various cloud-managed services.
Why it matters: Your AI-generated application may function perfectly on localhost, but exposing it safely and reliably to the internet introduces additional responsibilities.
5. API Gateways: Managing Multiple Services
As an application grows, it may contain several services.
An e-commerce platform might have separate services for customer accounts, inventory, orders, and payments.
Should the mobile app communicate directly with all four?
Sometimes, but an API gateway can provide a single entry point.
The gateway can direct requests, enforce authentication policies, apply rate limits, and standardize certain API behaviors.
Think of a shopping mall with one main information desk that directs visitors to different stores.
A gateway can simplify access to multiple services, although it also introduces its own operational considerations.
For a small application, you might not need one. Understanding when to introduce it is part of good engineering.
6. Request Timeouts: Don’t Wait Forever
Imagine calling customer service and being placed on hold indefinitely.
Wouldn’t it be better if the system eventually told you it couldn’t complete your request?
That’s what a timeout accomplishes.
A request timeout limits how long a system waits for an operation to finish.
Suppose your application calls a payment API, but the provider stops responding.
Without a timeout, your application could keep waiting, tying up resources and leaving the customer wondering what happened.
With an appropriate timeout, it can stop waiting and take a controlled next step.
But there’s an important detail.
A timeout does not necessarily mean the original operation failed.
Your payment might have succeeded even though your application never received the confirmation.
This brings us to retries.
7. Retry Logic: What Happens When Something Fails Temporarily?
Suppose your application requests information from another server.
The server is temporarily unavailable.
Should your application immediately give up?
Not always.
Retry logic allows software to attempt an operation again after a failure.
This is useful for temporary network interruptions and certain server errors.
But retries are dangerous when implemented carelessly.
Imagine your application sends a payment request, receives no response, and retries the request three times.
If the payment system doesn’t recognize duplicate operations, the customer could potentially be charged more than once.
The lesson: Retry operations only when doing so is safe, and use safeguards such as idempotency keys for payments and other sensitive operations.
8. Exponential Backoff: Stop Hammering a Failing Server
Imagine repeatedly knocking on someone’s door every second because they aren’t answering.
That probably won’t help.
Exponential backoff uses progressively longer delays between retry attempts.
For example:
- First retry: after roughly 1 second
- Second retry: after roughly 2 seconds
- Third retry: after roughly 4 seconds
- Fourth retry: after roughly 8 seconds
In practice, systems often add random variation, called jitter, to prevent thousands of clients from retrying simultaneously.
This is especially valuable when a service is overloaded.
Instead of making the problem worse by flooding the server with more requests, your application gives it time to recover.
9. Circuit Breakers: Knowing When to Stop Trying
Think about the circuit breaker in your home.
When an electrical problem occurs, the breaker cuts power to protect the system.
Software circuit breakers follow a similar principle.
If a dependent service repeatedly fails, the circuit breaker temporarily prevents additional requests to that service.
Instead of allowing every user request to wait for an unhealthy dependency, the application can fail quickly or provide a fallback.
After a recovery period, the system can test whether the service is healthy enough to resume normal traffic.
Example: A shopping application might temporarily hide personalized recommendations when the recommendation service is unavailable, while allowing customers to continue purchasing products.
The entire application doesn’t have to fail because one optional feature has stopped working.
10. API Versioning: What Happens When Your App Changes?
Suppose your mobile application uses an API that returns customer information in a particular format.
Thousands of users have already installed the app.
Now your developer—or AI coding assistant—changes the API response structure.
The new version might work perfectly with your updated website.
But older mobile apps may suddenly stop functioning.
This is where API versioning becomes useful.
For example:
/api/v1/customers
/api/v2/customers
Versioning can help organizations introduce breaking changes while maintaining compatibility with existing clients.
Not every API needs URL-based versions. There are other approaches, and many nonbreaking changes don’t require a new version.
The fundamental lesson is simple: when you change an API, think about the applications that already depend on it.
11. Webhook Design: When Another System Calls You
Most people understand the idea of an application requesting information from an API.
A webhook reverses that relationship.
Instead of constantly asking another system whether something has happened, your application receives an HTTP request when an event occurs.
For example:
A customer completes a payment through an external payment provider.
The provider sends a webhook to your application.
Your application receives the event, verifies its authenticity, and updates the order status.
Sounds simple, right?
Now consider these questions:
- What if the webhook arrives twice?
- What if your server is temporarily offline?
- What if events arrive out of order?
- How do you verify that the request genuinely came from the payment provider?
- What if your database update fails halfway through?
Reliable webhook systems must be designed to handle these situations.
For important operations, this usually includes verifying signatures, preventing duplicate processing, and ensuring failures can be recovered safely.
12. How These Ten Concepts Work Together
Let’s return to our shopping application.
A customer places an order.
A reverse proxy receives the incoming request and routes it appropriately.
A load balancer may distribute the request to an available application server.
An API gateway, if the architecture uses one, applies relevant access and traffic policies.
Rate limits help prevent excessive requests.
The application calls a payment provider using an appropriate timeout.
If a temporary error occurs, carefully designed retry logic may attempt the request again.
Exponential backoff prevents retries from overwhelming the payment provider.
A circuit breaker can limit further calls when the provider is experiencing a prolonged outage.
API versioning helps older clients remain compatible as the application evolves.
Finally, a verified webhook can notify the application when the payment status changes.
These concepts aren’t ten unrelated technical terms.
They are pieces of a larger engineering puzzle.
And remember: not every application needs every component. A good engineer knows which ones solve real problems and which ones would introduce unnecessary complexity.
13. What Should You Ask Your AI Coding Assistant?
You don’t necessarily need to implement all these systems manually.
Modern AI coding tools can help write API clients, configure reverse proxies, implement retry policies, and design webhook handlers.
But you should know what to ask.
For your next project, try giving your AI assistant this instruction:
“Review my application’s API and request-handling architecture for production readiness. Identify missing rate limits, unsafe retries, timeout risks, duplicate-request handling, API compatibility issues, webhook security weaknesses, and potential traffic bottlenecks. Explain the highest-priority risks before suggesting code changes.”
Don’t simply accept every recommendation.
Ask the AI to explain the trade-offs, how to test each change, and which changes are actually necessary for your application’s size and complexity.
This is where AI-assisted development becomes much more powerful.
14. Final Thoughts: Vibe Coding Is the Beginning, Not the End
I believe AI-assisted coding is one of the most exciting developments in software engineering.
Someone with a great idea can now build an application in days rather than months.
That’s extraordinary.
But generating code and operating reliable software are two different responsibilities.
You don’t have to become an expert in every infrastructure technology before building your first application.
You do need to understand that software will eventually face imperfect networks, unexpected traffic, unreliable services, and unpredictable user behavior.
AI can help you build the application. Engineering makes it survive the real world.
In Part 2 of our Beyond Vibe Coding series, we’ll explore Messaging, Queues & Asynchronous Systems—including how applications handle background jobs, communicate through events, and manage work that doesn’t need to happen immediately.
This article is part of Danson Solutions’ 10-part Beyond Vibe Coding series, expanding on Vijayesh (VJ) Sainju’s original LinkedIn article, “Vibe Coding Is Cute. Production Is Brutal. 101 Things You Need to Know.”
At Danson Solutions, we help organizations turn ideas and AI-assisted prototypes into secure, scalable, production-ready applications.