Forem: JongHwa

[CS] Operating System

JongHwa — Thu, 12 Feb 2026 01:22:38 +0000

1.Process is an 'Independent House', Thread is a 'Roommate'

To understand how computer programs work, we can imagine them as houses.

🏠 Process = "An Independent House"

Definition: A basic unit of work that gets resources from the Operating System (OS).
Features:
- Independence: It is completely separate from other houses. If the house next door catches fire, your house is safe!
- Cost: Building a house (creating a process) is heavy work. It takes a lot of land (RAM) and time.

🧔 Thread = "Roommates in a House"

Definition: A unit of execution that actually does the work inside a process.
Features:
- Sharing: Roommates share the living room (Heap memory) and the fridge. Communication is very fast because they live together.
- Lightweight: Adding one person is much easier and faster than building a whole new house.
- Risk: If one roommate starts a fire (a critical error), the whole house (the process) burns down.
Example: This is why if your Chrome browser crashes, your KakaoTalk app still works fine. They are in different houses!

2. How to Stop Fighting (Synchronization)

When roommates share one fridge (Heap), they might fight. Here are two ways to keep the peace.

🔒 1. Synchronized (Pessimistic Lock)

"The world is dangerous. I will lock the door while I use the fridge!"

Pros:
- 100% Safe: Since the door is locked, the data never gets messy.
- Good for complex tasks: It is safe when you have many steps to do, like taking food out, cooking, and putting it back.
Cons:
- Deadlock Risk: Roommate A has the bathroom key, and B has the kitchen key. They both wait for each other forever, and the whole house stops.
- Slow Speed: If the line is long, other roommates must wait and do nothing.

⚛️ 2. Atomic / CAS (Optimistic Lock)

"I don't think anyone touched it while I was gone. Oh, they did? Then I'll try again!"

Pros:
- Very Fast: There is no locking or unlocking. It is great for simple tasks like adding numbers.
- No Waiting: Roommates don't stand in line. If they fail, they just try again immediately.
Cons:
- Infinite Loop: If 100 people try to open the fridge at the same time, they might keep failing and trying again forever. This makes the CPU very busy.
- The ABA Problem: If a value changes from 100 to 200 and back to 100 while you are away, the system thinks "Oh, nothing changed!" even though it did.

[System Design] Scaling for User Growth

JongHwa — Sun, 01 Feb 2026 18:57:40 +0000

Scaling from 1 to Millions: System Design Fundamentals

English Summary: In this post, I explore the fundamental concepts of system design, from a single server setup to a distributed architecture handling millions of users.

저처럼 시스템 설계에 막 입문하신 분들에게 도움이 되길 바라며, 공부한 내용을 직접 그린 도표와 함께 정리해 보았습니다.

1. 단일 서버 (Single Server Setup)

모든 위대한 시스템은 단 한 대의 서버에서 시작됩니다. 웹 앱, DB, 캐시가 모두 한 곳에 모여 있는 구조죠.

특징: 구성이 단순하지만, 서버 하나가 죽으면 서비스 전체가 중단되는 위험(SPOF)이 있습니다.

2. 데이터베이스 분리 (Separating the Database)

사용자가 늘어나면 웹 트래픽 처리용 서버와 데이터 보관용 DB 서버를 분리해야 합니다.

NoSQL이 필요한 경우: 아주 낮은 응답 지연시간이 필요하거나, 데이터 양이 폭발적으로 많을 때 비-관계형 DB가 좋은 대안이 될 수 있습니다.

3. 수직적 vs 수평적 확장 (Vertical vs Horizontal Scaling)

수직적 확장(Scale-up): 서버의 CPU나 메모리를 높이는 것. 한계가 명확하고 장애 대응이 어렵습니다.
수평적 확장(Scale-out): 서버 대수를 늘리는 것. 대규모 트래픽 처리를 위한 현대 시스템의 핵심입니다.

4. 부하 분산: 로드밸런서 (Load Balancer)

서버를 여러 대 두었다면, 트래픽을 골고루 나눠주는 '교통경찰'이 필요합니다.

역할: 특정 서버에 부하가 몰리는 것을 방지하고, 한 서버가 죽어도 다른 서버로 유저를 안내합니다.

5. 데이터 안정성: DB 다중화 (DB Replication)

DB도 여러 대를 두어 '주(Master)-부(Slave)' 구조로 관리합니다.

장점: 성능 향상은 물론, 자연재해 등으로 서버가 파괴되어도 데이터를 안전하게 보존할 수 있습니다.

6. 더 빠른 응답을 위한 캐시 & CDN

Cache: 자주 찾는 데이터를 메모리에 저장해 DB 부하를 줄입니다.
CDN: 이미지나 영상 같은 정적 콘텐츠를 유저와 가까운 곳에서 빠르게 전달합니다.

7. 무상태(Stateless) 웹 계층

웹 서버를 수평적으로 확장하려면 상태 정보를 서버에서 제거해야 합니다. 세션 데이터를 DB나 Redis 같은 공유 저장소에 보관하여 어떤 웹 서버든 요청을 처리할 수 있게 만듭니다.

8. 데이터 센터 (Data Center)

지리적으로 떨어진 여러 곳에 데이터 센터를 구축하여 가용성을 높이고 유저에게 더 빠른 응답을 제공합니다. (지리적 라우팅)

9. 메시지 큐 (Message Queue)

메시지 큐는 서비스 간의 결합도를 낮추고, 비동기 처리를 가능하게 하는 핵심 컴포넌트입니다.

비동기 처리: 시간이 오래 걸리는 작업(예: 이메일 발송, 이미지 프로세싱)을 큐에 던져두고, 웹 서버는 즉시 응답을 반환할 수 있습니다.
서버 간 결합도 완화(Decoupling): 생산자(Producer)는 메시지를 발행하고, 소비자(Consumer)는 이를 받아 처리하므로 두 서비스가 서로를 직접 몰라도 작동합니다.
안정성: 트래픽이 갑자기 몰려도 메시지 큐가 버퍼 역할을 해주어 소비자 서버가 죽지 않고 차례대로 일을 처리할 수 있게 돕습니다.

10. 로그, 메트릭 그리고 자동화

시스템이 커지면 모니터링은 필수입니다.

로그: 오류 추적
메트릭: 시스템 성능 수치화
자동화: CI/CD를 통한 안정적인 배포

11. 데이터베이스의 규모 확장 (Sharding)

DB의 부하를 나누기 위해 샤딩(Sharding)을 도입합니다. 데이터를 여러 서버에 분산 저장하여 개별 DB의 크기를 줄이는 방식입니다.

12. 백만 사용자, 그리고 그 이상

결국 대규모 시스템 설계는 반복적인 개선 과정입니다. 무상태 계층, 다중화, 캐시, 그리고 샤딩까지 도입된다면 백만 명 이상의 사용자도 거뜬히 감당할 수 있는 구조가 됩니다.

Part 4: Advanced Strategies for High Traffic

JongHwa — Thu, 29 Jan 2026 18:18:24 +0000

Intro

In the previous parts, we built the foundation. But in a real production environment, we face tougher challenges: System crashes, Data loss, and Database bottlenecks. Here is how we solve them.

1. Guaranteeing Atomicity with Lua Scripts

When checking stock and issuing a coupon, we must ensure these two steps happen as one single unit. If another request sneaks in between, we might over-issue coupons.

The Solution:
We use a Redis Lua Script. Redis executes the script in a single thread, meaning no other operation can interrupt it. It’s the perfect way to prevent "Race Conditions."

2. Database Protection: Throttling & Batching

Even if Redis is fast, the Database (MySQL) can be a bottleneck. If we send 10,000 "Insert" queries at once, the DB connection pool will be exhausted.

The Solution:

Message Queue (Kafka/RabbitMQ): We send the results to a queue first.
Worker Throttling: A background worker pulls data from the queue at a controlled speed (e.g., 200 records/sec).
Batch Insert: Instead of 1,000 separate queries, we group them into one single INSERT query to reduce IO overhead.

3. Handling Failures: Eventual Consistency

What happens if the Redis operation succeeds, but the Database save fails? This is a Data Integrity issue.

The Strategy:

Retry with Back-off: The system automatically retries the save operation.
Dead Letter Queue (DLQ): If it fails after 3-5 tries, the data is moved to a DLQ. Engineers can then check the logs and manually fix the data.
The Goal: We accept that data might be delayed for a few seconds, but we ensure it is eventually consistent.

Conclusion

Building a high-performance system is a balance between Speed and Safety. By using Redis for speed and Message Queues for safety, we can build a backend that never crashes.

Part 3: Final Architecture & Lessons Learned

JongHwa — Thu, 29 Jan 2026 18:08:23 +0000

Intro

The Opener Market project is finally coming to an end. In this final post, I will review the overall system architecture and share the key lessons learned from building a high-concurrency e-commerce platform.

1. The Big Picture: System Architecture

Our system is divided into three main domains, each solving a specific high-traffic problem:

Coupon Domain: Uses Redis Lua Scripts for atomic stock control and a Write-Back pattern to ensure data consistency without slowing down the user.
Order Domain: Implements Database Locking (Pessimistic/Optimistic) to prevent over-selling and ensure transaction integrity.
Search Domain: Powered by QueryDSL for type-safe dynamic queries and optimized with composite indexes for sub-second latency.

2. Performance Milestones

Search Latency: Reduced from 1.8s to 0.5s (72% improvement).
Throughput: Successfully handled high-concurrency coupon issuance using Redis memory instead of DB locks.
Consistency: Guaranteed atomic transactions across Balance, Stock, and Points.

3. Key Lessons

Memory-First Strategy: For high-traffic events, the Database should be the last resort. Redis is essential for protecting the core system.
Asynchronous Processing: Decoupling the user response from heavy tasks (like DB persistence) is the secret to a smooth UX.
Data Integrity vs. Speed: In e-commerce, speed is important, but accuracy is everything. Always use @Transactional and proper locking strategies.

Final Thoughts

Building Opener Market was a deep dive into the world of scalable backend systems. This project taught me how to balance complex requirements with performance optimization.

Part 2: Optimizing Search Performance"

JongHwa — Thu, 29 Jan 2026 18:02:14 +0000

Intro

As data grows, search speed becomes a major bottleneck. In this post, I will share how I optimized product search from 1.8s to 0.5s using QueryDSL and Database Indexing.

1. The Challenge: Dynamic Queries

Users want to filter products by category, price, and rating, while sorting by sales or newest arrival.

The Problem: Writing raw SQL for every combination is impossible to maintain.
The Goal: Build a type-safe, dynamic search engine that stays fast even with 1M+ records.

2. Implementation: QueryDSL

I used QueryDSL to handle complex filtering logic without losing type safety.

public Page<Item> searchItems(ItemSearchCondition condition, Pageable pageable) {
    return queryFactory
        .selectFrom(item)
        .where(
            nameContains(condition.getName()),
            categoryEq(condition.getCategoryName())
        )
        .orderBy(getSortOrder(condition.getSortType()))
        .offset(pageable.getOffset())
        .limit(pageable.getPageSize())
        .fetch();
}

3. Performance Tuning: Indexing

Even with good code, a query is slow if it scans the entire table.

The Problem: Sorting 1 million rows took over 1.8 seconds.
The Solution: I analyzed the execution plan and applied Composite Indexes on frequently used columns (e.g., Category + SalesVolume).
The Result: Latency dropped to under 0.5s (72% improvement).

4. Advanced: N+1 Problem

When fetching items with their categories, Hibernate often executes too many queries. I solved this by using fetchJoin(), reducing the database load significantly.

Conclusion

Optimizing search is not just about writing queries; it's about understanding how the database reads data. In the next part, we will dive into high-concurrency coupon systems.

Part 1: Reliable Payment & Transaction

JongHwa — Thu, 29 Jan 2026 17:58:45 +0000

Intro

In e-commerce, the checkout process must be atomic. If one step fails, everything must roll back. Here is how I built a reliable payment system using Spring Boot.

1. The Core Workflow

When a user buys an item, three things must happen as a single unit:

Balance: Withdraw money from the wallet.
Stock: Decrease quantity. If 0, set status to SOLD_OUT.
Points:
- Spend: Users decide the exact amount (Min 1).
- Earn: Get 2.5% back from the final payment.

2. Implementation: `@Transactional`

I used Spring's transaction management to ensure Data Integrity. If the stock reduction fails, the money withdrawal is automatically canceled.

@Transactional
public void processOrder(OrderRequest request) {
    // 1. Validation (Check Sold Out)
    // 2. Point Usage & Balance Deduction
    // 3. Stock Reduction (Atomic)
    // 4. Point Accrual (2.5% Reward)
}

3. Solving the "Logical Gap"

In Step 1, simple subtraction was enough. But in a real system, Concurrency is the enemy.

The Problem: If two users buy the last item at the same time, we might get "Negative Stock."
The Solution: I researched Database Locking to ensure only one process can update the stock at a time, preventing over-selling.

4. Failure Recovery

Validation First: Always check stock status before touching the balance.
Rollback: If an exception occurs during point accrual, the entire transaction is reverted by the @Transactional manager.

Conclusion

Data consistency is more important than speed in payments. Using @Transactional and strict validation is the first step toward a professional e-commerce backend.

[Simple SNS Project] Step 4. Search Implementation & Logging Strategy

JongHwa — Sat, 10 Jan 2026 20:11:18 +0000

Introduction

In Step 3, I connected users via the Follow system. Now, in Step 4, I implemented a Search Feature to let users find content.
More importantly, I established a Logging Strategy. I'm not just printing logs to the console; I'm saving user search patterns to a file to analyze trends later.

1. Search Implementation: LIKE Query

For the search functionality, I used the standard SQL LIKE operator.

// FeedRepository.java
Page<Feed> findByContentContainingOrderByCreatedAtDesc(String keyword, Pageable pageable);

How it works: It translates to SELECT * FROM feed WHERE content LIKE '%keyword%'.
Performance Note: Starting a query with a wildcard (%) prevents the database from using standard B-Tree indexes (Full Table Scan).
Future Improvement: For a production-level application with millions of rows, I would switch to Full-Text Search (MySQL) or a dedicated search engine like Elasticsearch. But for this project scope, LIKE is sufficient.

2. Logging Strategy: Why File Logging?

Console logs disappear when the server restarts. To analyze user behavior (e.g., "What are people searching for?"), logs must be persisted.

I configured logback in application.yml to write logs to a specific file (logs/simple-sns.log).

logging:
  file:
    name: logs/simple-sns.log
  logback:
    rollingpolicy:
      max-history: 7 # Keep logs for 7 days

And in the Service layer, I added a structured log message:

log.info("[SEARCH] keyword: {}", keyword);

This specific format [SEARCH] acts as a tag that will make parsing easier in Step 6 (Statistics).

3. Conclusion

This step was about preparing for the future. By logging user actions, I am laying the groundwork for data-driven features like "Trending Keywords".

[Simple SNS Project] Step 3. Building the Follow System & Timeline (N:M Relationship)

JongHwa — Fri, 09 Jan 2026 21:28:20 +0000

Introduction

In Step 2, I built a personal feed. Now, in Step 3, I transformed the application into a real social network by implementing the Follow System.
The biggest challenge was modeling the relationship between users and efficiently retrieving the Timeline (a mix of my posts and my friends' posts).

1. Database Modeling: The N:M Relationship

A user can follow many people, and can be followed by many. This is a classic Many-to-Many (N:M) relationship.
To handle this in a Relational Database (MySQL), I introduced a mapping table called Follows.

@Entity
@Table(
    name = "follows",
    uniqueConstraints = {
        @UniqueConstraint(columnNames = {"follower_id", "followee_id"}) // Prevent duplicate follows
    }
)
public class Follow {
    @ManyToOne
    private User follower; // Who follows

    @ManyToOne
    private User followee; // Who is followed
}

I also added a UniqueConstraint to ensure data integrity at the database level, preventing a user from following the same person twice.

2. The Timeline Query: Pull Model

How do we show the timeline?
I adopted the Pull Model (Fan-out on Read) strategy for this stage. When a user requests their timeline, the system dynamically queries the database.

The Logic:

Find all users that I follow.
Extract their IDs.
Query the Feed table using an IN clause.

// FeedRepository.java
Page<Feed> findAllByUserInOrderByCreatedAtDesc(List<User> users, Pageable pageable);

Why this approach?

Pros: Simple to implement and data consistency is guaranteed.
Cons: As the number of followings grows, the IN query can become slow.
Future Improvement: For a large-scale system, I would consider the Push Model (Fan-out on Write), where feeds are pre-distributed to followers' timelines upon creation. But for this project, the Pull Model is sufficient and efficient enough.

3. Frontend Integration

I updated the React frontend to allow users to input a User ID and follow them. The timeline now seamlessly mixes my posts with my friends' posts, sorted by time.

4. Conclusion

Handling relationships is the core of backend development. Through this step, I learned how to map entities using JPA and how to construct complex queries using Spring Data JPA's method naming conventions.

[Simple SNS Project] Step 2. Optimizing Feed Performance: DB Indexing & Rate Limiting

JongHwa — Mon, 29 Dec 2025 22:59:44 +0000

Following the user registration feature in Step 1, I moved on to the core feature of any SNS: The Feed.

However, simply storing and retrieving data isn't enough. I had to consider performance (how fast can we retrieve feeds?) and stability (how do we prevent abuse?).

In this post, I will share how I optimized database queries using Composite Indexes and implemented a custom Rate Limiter in Spring Boot.

1. Database Indexing Strategy

The most common query for a feed is: "Show me the latest posts written by User A."

Without an index, the database performs a Full Table Scan, checking every single row. To optimize this, I applied a Composite Index.


@Entity
@Table(name = "feeds", indexes = {
    @Index(name = "idx_user_created_at", columnList = "user_id, created_at")
})
public class Feed { ... }

Why user_id? To filter posts by the specific user.
Why created_at? To sort them in descending order (latest first).
Result: The database can now jump directly to the user's data and read it sequentially, significantly reducing query time.

2. Protecting the Server: Rate Limiting

One of the requirements was to limit users to 5 requests per minute to prevent spamming or DDoS-like behavior.

Instead of using heavy external tools like Redis immediately, I implemented a lightweight In-Memory Rate Limiter using Java's ConcurrentHashMap.

How it works:

Storage: A Map stores the request count for each user ID.
Check: Before processing a request, check if the count exceeds 5.
Reset: A @Scheduled task clears the map every minute.


@Component
public class RateLimiter {
    private final Map<Long, Integer> requestCounts = new ConcurrentHashMap<>();

    public boolean isAllowed(Long userId) {
        int count = requestCounts.getOrDefault(userId, 0);
        if (count >= 5) return false; // Block request
        requestCounts.put(userId, count + 1);
        return true;
    }

    @Scheduled(cron = "0 * * * * *") // Reset every minute
    public void resetCounts() {
        requestCounts.clear();
    }
}

3. Frontend Integration (React)

On the frontend, I handled the 429 Too Many Requests error gracefully. If the server rejects a request due to the rate limit, the user sees a friendly alert message instead of a crash.


} catch (error) {
  if (error.response?.status === 429) {
    alert("You are posting too fast! Please wait a moment. 🛑");
  }
}

4. Conclusion

In this step, I learned that backend development is not just about logic, but about resource management.

Indexes save CPU and I/O.
Rate Limiters save the server from being overwhelmed.

[Simple SNS Project] Step 1. User Registration & Handling Forbidden Words with Spring Boot

JongHwa — Mon, 29 Dec 2025 22:52:41 +0000

I have started a new side project called "Very Simple SNS" to strengthen my full-stack development skills using Spring Boot and React. The goal is not just to write code, but to understand the "Why" behind every architectural decision, such as database indexing, traffic handling, and system design.

In this first step, I focused on setting up the environment and implementing the User Registration feature.

Tech Stack

Backend: Spring Boot 3.x, Spring Data JPA, MySQL
Frontend: React (Vite)
Collaboration: Git (Monorepo structure)

1. The Core Logic: Forbidden Word Filter

One of the key requirements for Step 1 was to prevent users from using specific keywords (e.g., "admin", "operator") in their nicknames to avoid confusion.

I faced a design decision: Where should I put this validation logic?

Inside the Entity? (User.java)
Inside the Service Layer? (UserService.java)

My Decision: The Service Layer.

Entities should focus on their own internal integrity (e.g., length check, null check). Checking against a list of "forbidden words" is a business policy that might change over time or require external data sources (like a DB table or Redis). Therefore, it belongs in the Service layer to keep the Entity pure.


@Service
@RequiredArgsConstructor
public class UserService {

    // In a real-world scenario, this would be fetched from a DB or Cache
    private static final List<String> FORBIDDEN_WORDS = List.of("admin", "operator");

    @Transactional
    public Long signup(SignupRequest request) {
        // Validation Logic
        if (containsForbiddenWord(request.getNickname())) {
            throw new IllegalArgumentException("This nickname is not allowed.");
        }

        // ... saving user logic
    }

    private boolean containsForbiddenWord(String nickname) {
        return FORBIDDEN_WORDS.stream().anyMatch(nickname::contains);
    }
}

2. What I Learned

Monorepo Setup: Managing both Backend and Frontend in a single Git repository makes it easier to track changes for a specific feature.
Separation of Concerns: Distinguishing between Domain logic (Entity) and Business logic (Service) is crucial for maintainability.

Stop Asking for Data! Master the "Tell, Don't Ask" Principle

JongHwa — Fri, 19 Dec 2025 00:57:48 +0000

One of the most common mistakes in Object-Oriented Programming (OOP) is treating objects like simple data structures. We often pull data out of an object, perform some logic, and then put the result back in.
This violates the "Tell, Don't Ask" (TDA) principle.

In this post, I will explain what TDA is and how it improves your code using a simple Shop and Account example.

What is "Tell, Don't Ask"?

The principle is simple:

Don't Ask: Don't ask an object for its data to perform logic on it yourself.
Tell: Tell the object what to do, and let it handle its own state.

When you follow TDA, you improve Encapsulation and Cohesion.

The Problem: Procedural Code in OOP ❌

Let's look at a common anti-pattern. Here, the Shop class is managing the logic that belongs to the Account.

package com.mateandgit.programming.chapter1_2.problem;

public class Shop {

    public void sell(Account account, Product product) {
        // ❌ BAD: Asking for data (getMoney)
        long price = product.getPrice();
        long mileage = account.getMoney();

        // ❌ BAD: The Shop is deciding if the account has enough money
        if (mileage >= price) {
            // ❌ BAD: Modifying the account's state externally
            account.setMoney(mileage - price);
            System.out.println(product.getName() + " purchased.");
        } else {
            System.out.println("Insufficient balance.");
        }
    }
}

Why is this bad?

Violation of Encapsulation: The Shop knows too much about how the Account works (it knows it has "money" and knows how to calculate the balance).
Logic Duplication: If another class (e.g., SubscriptionService) needs to deduct money, you have to duplicate this if (balance >= price) logic there too.
Hard to Maintain: If the validation rule changes (e.g., "minimum balance must remain 100"), you have to fix it in every class that accesses Account.

The Solution: Tell the Object What to Do ✅

Refactoring this to follow TDA means moving the logic into the Account class. The Shop should just command the Account to pay.

package com.mateandgit.programming.chapter1_2.solution;

public class Shop {

    public void sell(Account account, Product product) {
        // ✅ GOOD: Just asking a question (canAfford)
        if (account.canAfford(product.getPrice())) {

            // ✅ GOOD: Telling the object to do something (withdraw)
            account.withdraw(product.getPrice());
            System.out.println(product.getName() + " purchased.");
        } else {
            System.out.println("Insufficient balance.");
        }
    }
}

(Inside the Account class, you would have methods like canAfford() and withdraw() that encapsulate the logic.)

Why is this better?

Better Encapsulation: The Shop doesn't know how the withdrawal happens. It just sends a message.
Reusable Logic: The validation rules (canAfford) are centralized in the Account class.
Readability: The code reads like a sentence: "If account can afford, withdraw."

Conclusion

Object-Oriented Programming is about sending messages, not manipulating data.
If you find yourself writing getSomething(), changing it, and calling setSomething(), stop and think:

"Should this logic belong to the object I'm getting data from?"

Apply the Tell, Don't Ask principle to keep your objects independent and your logic clean.

Key Takeaways

Don't: get data -> calculate -> set data.
Do: Create a method in the object and tell it to perform the action.
Result: High cohesion, low coupling, and better encapsulation.

My Service is Slow! Where Do I Start? (Performance Tuning Basics)

JongHwa — Thu, 18 Dec 2025 22:05:50 +0000

We've all been there. You deploy your application, and everything seems fine until traffic spikes. Suddenly, the API response takes 5 seconds, and users are complaining.

"Where do I even start looking?"

In this post, I will summarize the core concepts of server performance tuning, focusing on metrics, scaling, and the critical database connection pool.

1. Throughput vs. Latency (Response Time)

Before fixing anything, we need to know what we are measuring. There are two main metrics:

Latency (Response Time): How long does it take to process one request? (e.g., "The API took 200ms to return data.")
Throughput: How many requests can the system handle per second? (e.g., "The server handles 1,000 TPS/RPS.")

💡 Key Insight: Improving Latency usually improves Throughput, but not always. You must decide which metric is more important for your specific service goal.

2. Finding the Bottleneck

A system is only as fast as its slowest component. This is called the Bottleneck.

Common bottlenecks include:

CPU: Heavy calculations or infinite loops.
Memory: Memory leaks or frequent Garbage Collection (GC).
I/O (Input/Output): Slow database queries, network calls to external APIs, or disk read/write.
❌ Bad Practice: Guessing. "Maybe we need a bigger server?"
✅ Best Practice: Monitoring. Use tools (like APM, Prometheus, or Grafana) to identify exactly where the request is getting stuck.

3. Scaling: Vertical vs. Horizontal

Once you find the bottleneck, you generally have two ways to expand capacity:

Vertical Scaling (Scale Up)

What is it? Upgrading the server hardware (e.g., increasing RAM from 8GB to 32GB).
Pros: Simple configuration. No code changes required.
Cons: Expensive and has a physical limit.

Horizontal Scaling (Scale Out)

What is it? Adding more servers (nodes) to share the load.
Pros: Infinite scalability. High availability (if one server dies, others survive).
Cons: Complexity. You need a Load Balancer and need to handle distributed data consistency.

4. The Silent Killer: DB Connection Pool

In many web applications (especially Spring Boot), the bottleneck is often the Database Connection Pool. Establishing a connection to a database is expensive. Therefore, we use a "Pool" to reuse connections.

Connection Pool Size

Too Small: Threads have to wait in a queue for a connection to open. (High Latency)
Too Large: Too many connections overwhelm the CPU with "Context Switching." (Low Throughput)

Connection Wait Time (Timeout)

If the pool is full, how long should a request wait before throwing an error? If set too long, the user waits 30 seconds just to see an error. It is better to fail fast so the system can recover.

5. Server Caching

The fastest query is the one you never make. If your service reads data that doesn't change often, use Caching.

Local Cache (Ehcache, Caffeine): Extremely fast, stored in the application's RAM.
Global Cache (Redis): Shared across multiple servers.

By caching frequently accessed data, you can drastically reduce the load on your database and improve Latency.

Conclusion

Performance tuning isn't magic. It starts with understanding the difference between Throughput and Latency, identifying the Bottleneck, and then optimizing resources like the DB Connection Pool.

✅ Checklist for slow services:

Are my queries slow? (Check DB Indexes)
Is my Connection Pool size appropriate? (Check HikariCP settings)
Can I cache this data? (Use Local or Global Cache)
Do I need to Scale Up or Scale Out? (Vertical vs Horizontal Scaling)

Forem: JongHwa

[CS] Operating System

1.Process is an 'Independent House', Thread is a 'Roommate'

🏠 Process = "An Independent House"

🧔 Thread = "Roommates in a House"

2. How to Stop Fighting (Synchronization)

🔒 1. Synchronized (Pessimistic Lock)

⚛️ 2. Atomic / CAS (Optimistic Lock)

[System Design] Scaling for User Growth

Scaling from 1 to Millions: System Design Fundamentals

1. 단일 서버 (Single Server Setup)

2. 데이터베이스 분리 (Separating the Database)

3. 수직적 vs 수평적 확장 (Vertical vs Horizontal Scaling)

4. 부하 분산: 로드밸런서 (Load Balancer)

5. 데이터 안정성: DB 다중화 (DB Replication)

6. 더 빠른 응답을 위한 캐시 & CDN

7. 무상태(Stateless) 웹 계층

8. 데이터 센터 (Data Center)

9. 메시지 큐 (Message Queue)

10. 로그, 메트릭 그리고 자동화

11. 데이터베이스의 규모 확장 (Sharding)

12. 백만 사용자, 그리고 그 이상

Part 4: Advanced Strategies for High Traffic

Intro

1. Guaranteeing Atomicity with Lua Scripts

2. Database Protection: Throttling & Batching

3. Handling Failures: Eventual Consistency

Conclusion

Part 3: Final Architecture & Lessons Learned

Intro

1. The Big Picture: System Architecture

2. Performance Milestones

3. Key Lessons

Final Thoughts

Part 2: Optimizing Search Performance"

Intro

1. The Challenge: Dynamic Queries

2. Implementation: QueryDSL

3. Performance Tuning: Indexing

4. Advanced: N+1 Problem

Conclusion

Part 1: Reliable Payment & Transaction

Intro

1. The Core Workflow

2. Implementation: @Transactional

3. Solving the "Logical Gap"

4. Failure Recovery

Conclusion

[Simple SNS Project] Step 4. Search Implementation & Logging Strategy

Introduction

1. Search Implementation: LIKE Query

2. Logging Strategy: Why File Logging?

3. Conclusion

[Simple SNS Project] Step 3. Building the Follow System & Timeline (N:M Relationship)

Introduction

1. Database Modeling: The N:M Relationship

2. The Timeline Query: Pull Model

The Logic:

Why this approach?

3. Frontend Integration

4. Conclusion

[Simple SNS Project] Step 2. Optimizing Feed Performance: DB Indexing & Rate Limiting

1. Database Indexing Strategy

2. Protecting the Server: Rate Limiting

3. Frontend Integration (React)

4. Conclusion

[Simple SNS Project] Step 1. User Registration & Handling Forbidden Words with Spring Boot

1. The Core Logic: Forbidden Word Filter

2. What I Learned

Stop Asking for Data! Master the "Tell, Don't Ask" Principle

What is "Tell, Don't Ask"?

The Problem: Procedural Code in OOP ❌

Why is this bad?

The Solution: Tell the Object What to Do ✅

Why is this better?

Conclusion

Key Takeaways

My Service is Slow! Where Do I Start? (Performance Tuning Basics)

1. Throughput vs. Latency (Response Time)

2. Finding the Bottleneck

2. Implementation: `@Transactional`