Server · Client
Server / Client
What is a server?
- Client = the side that requests
- Server = the side that provides
- The two exchange requests and responses
What this distinction really changes is the line that decides whose problem it is. When a report comes in that a screen is broken, if it breaks only in one employee's browser, the problem is on the client side; if every employee sees the same symptom at the same time, it is on the server side. That single question, 'Is it just me, or is it everyone?', cuts the scope of what you need to check in half. The moment you say 'which side is broken' instead of 'the site is broken', your outsourced developer starts replying faster.
In practice, three clues tell you where the boundary lies. The first is the error number. A convention used across the web says that errors like 404 and 403 that start with 4 are a problem on the requesting side (the client), while errors like 500 and 502 that start with 5 are a problem on the processing side (the server). The second is where the data persists. A value that disappears on refresh lives on the client; a value that stays the same when you log in from another device is stored on the server. The third is speed. Something like a color change on mouse hover is handled instantly by the client, but every trip to the server adds a 0.3–2 second round trip.
The most common misconception is that “if it isn’t on screen, it isn’t there.” Anyone can open the code and data sent down to the client with a single press of F12. Incidents keep recurring in which an AI API key is hard-coded into the browser code of an internal tool built through vibe coding, and outsiders then flood that key with calls, leaving the company with a huge bill. Handle price calculations, permission checks, and secret keys on the server, without exception, and leave only the display to the client. Holding just this line prevents most incidents. Hiding an admin button on screen is not security.
Jaryong KooMarketing PhD and authority in AI, data analytics, and personal branding
John KimAuthor of B2B Marketing Design and CEO of Nanum ConsultingIt comes from the “client-server model” established in the 1970s and 80s, when many terminals connected to a central computer, and it became the basic structure of the web in the 1990s.
Consider a hypothetical case: the online store of Company A, a household goods distributor with 120 employees and annual revenue of about KRW 40 billion (≈ US$29,926,700). Over three months, customer service inquiries saying “I can’t add items to my cart” piled up to 60 a month. Each time, the operations team only told the outsourced development agency that “the site is acting strange,” and getting an answer took 3 days on average.
- When Operations Associate Kim sorted 60 inquiries into “only one person hits this” and “several people hit this at the same time,” 41 turned out to be client-side problems coming from a single customer.
- The agency’s PM asked them to “capture the error screen and send it along with the time of access,” so the team added fields asking for the error number and access time to the customer service reply template.
- For the remaining 19 cases, the logs showed they were all 502 errors around 8 p.m.: the server couldn’t handle the concurrent connections when a promotional notification went out to 50,000 people at once.
- When the IT lead split notification sending from one batch at exactly 8:00 into three batches 10 minutes apart, 502 errors the following month fell from 19 to 2.
- Six months later, cart-related inquiries fell from 60 a month to 17, and the time to hear back from the development agency dropped from an average of 3 days to 4 hours.