กรอบการสัมภาษณ์ด้านการออกแบบระบบ
เรียนรู้กรอบ RADIO ห้าขั้นตอน (Requirements, API, Data, Infrastructure, Optimise) และฝึกนำไปใช้กับบริการย่อลิงก์ URL
กรอบการสัมภาษณ์ด้านการออกแบบระบบ เป็นบทเรียน DSA Interview Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน DSA Interview Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส DSA Interview Prep มีบทเรียนทั้งหมด 4 บทเรียน
เหตุใดการออกแบบระบบจึงสำคัญในการสัมภาษณ์
การสัมภาษณ์การออกแบบระบบ ทดสอบความสามารถในการคิดเมื่อระบบมีขนาดใหญ่ — คุณจะออกแบบทวิตเตอร์, YouTube หรือเครื่องย่อลิงก์สำหรับผู้ใช้หลายพันล้านคนอย่างไร ต่างจากโจทย์การเขียนโค้ดที่มีคำตอบถูกต้องเพียงคำตอบเดียว การออกแบบระบบเป็นโจทย์ปลายเปิด: คุณต้องตัดสินใจเลือกข้อแลกเปลี่ยนและอธิบายเหตุผล บทบาทระดับอาวุโสและระดับสตาฟมักใช้เวลา 30–45 นาทีกับรอบนี้โดยเฉพาะ
ผู้สัมภาษณ์ประเมินว่าคุณสามารถชี้แจงข้อกำหนด ประเมินภาระงาน เสนอสถาปัตยกรรมระดับสูง เจาะลึกองค์ประกอบสำคัญ และอภิปรายข้อแลกเปลี่ยนได้หรือไม่ โดยยังสื่อสารอย่างชัดเจนไปพร้อมกัน กรอบงานที่มีโครงสร้างช่วยป้องกันไม่ให้คุณพูดวกวน และทำให้ครอบคลุมประเด็นสำคัญทั้งหมด
# System design is not about a single correct answer.
# Interviewers look for:
eval_criteria = [
'Ability to clarify requirements before designing',
'Back-of-envelope capacity estimation',
'High-level architecture with clear components',
'Data modelling and storage choice',
'Handling scalability (10x, 100x load)',
'Trade-off discussion (consistency vs availability, etc.)',
'Communication: talking through decisions as you make them',
]
for c in eval_criteria:
print('-', c)ภาพรวมกรอบงาน RADIO
กรอบงาน RADIO มอบโครงสร้าง 5 ขั้นตอนที่ใช้ซ้ำได้สำหรับการสัมภาษณ์การออกแบบระบบทุกแบบ:
- R — ข้อกำหนด: ด้านการทำงานและด้านที่ไม่ใช่การทำงาน
- A — การออกแบบเอพีไอ: ระบบเปิดให้เรียกใช้การดำเนินการใดบ้าง
- D — แบบจำลองข้อมูล: จัดเก็บข้อมูลใดและจัดเก็บอย่างไร
- I — โครงสร้างพื้นฐาน: องค์ประกอบระดับสูง (เซิร์ฟเวอร์ คิว แคช)
- O — เพิ่มประสิทธิภาพ: คอขวด การแคช การแบ่งส่วน การทำสำเนา
ดำเนินตามขั้นตอนเหล่านี้ตามลำดับเสมอ แต่ย้อนกลับไปปรับปรุงขั้นตอนก่อนหน้าได้เมื่อเกิดความเข้าใจใหม่ ใช้เวลาในแต่ละระยะใกล้เคียงกัน อย่าข้ามไปวาดกล่องทันทีโดยยังไม่ได้ชี้แจงข้อกำหนด
RADIO = {
'R': 'Requirements — What must the system do? What scale?',
'A': 'API — Define endpoints/operations the system exposes',
'D': 'Data Model — Entities, schemas, storage types',
'I': 'Infra — High-level architecture: servers, queues, caches, CDN',
'O': 'Optimise — Identify and address bottlenecks, trade-offs',
}
for step, desc in RADIO.items():
print(f'[{step}] {desc}')
print('\nTiming guide for a 45-min interview:')
print(' R: 5 min | A: 5 min | D: 10 min | I: 15 min | O: 10 min')ขั้น R: ชี้แจงข้อกำหนด
อย่าเริ่มออกแบบโดยไม่ชี้แจงข้อกำหนด ถามเกี่ยวกับ ข้อกำหนดด้านการทำงาน (ระบบทำอะไร) และ ข้อกำหนดที่ไม่ใช่ด้านการทำงาน (ขนาดระบบ เวลาแฝง ความพร้อมใช้งาน) สำหรับเครื่องย่อลิงก์:
- ด้านการทำงาน: ย่อลิงก์ที่อยู่เว็บ เปลี่ยนเส้นทางไปยังที่อยู่เว็บต้นฉบับ และอาจรองรับชื่อแฝงที่กำหนดเองกับวันหมดอายุ
- ด้านที่ไม่ใช่การทำงาน: วันหนึ่งมีที่อยู่เว็บกี่รายการ เน้นการอ่านหรือการเขียน ข้อกำหนดด้านความพร้อมใช้งาน (99.9% เทียบกับ 99.99%) เวลาแฝงที่ยอมรับได้
การระบุสมมติฐานอย่างชัดเจนแสดงถึงวุฒิภาวะ ผู้สัมภาษณ์มักให้ข้อกำหนดที่คลุมเครือโดยตั้งใจเพื่อดูว่าคุณถามคำถามที่ถูกต้องหรือไม่ การใช้เวลาชี้แจงสองนาทีช่วยไม่ให้คุณออกแบบระบบผิดแบบ
# Requirements questions for URL Shortener:
functional = [
'Shorten a given URL to a 7-character alias',
'Redirect short URL to original URL',
'Allow custom aliases (optional)',
'URL expiry (optional)',
'Analytics: click count per URL (optional)',
]
non_functional = [
'100 million new URLs per day (write: ~1160/sec)',
'10:1 read:write ratio => 11,600 redirects/sec',
'Redirects must be < 100ms p99 latency',
'99.99% availability (< 1 hr downtime/year)',
'URLs must be globally accessible',
]
print('Functional:')
for f in functional: print(' -', f)
print('\nNon-functional:')
for nf in non_functional: print(' -', nf)ขั้น R: การประมาณการแบบคร่าว ๆ จากหลังซอง
หลังจากได้ข้อกำหนดแล้ว ให้ประมาณการความจุรองรับ วิธีนี้แสดงว่าคุณสามารถใช้เหตุผลเกี่ยวกับขนาดระบบก่อนเสนอคำตอบ ตัวเลขสำคัญที่ควรหา ได้แก่ คำขอต่อวินาที (RPS) พื้นที่จัดเก็บที่ต้องใช้ต่อวัน/ปี แบนด์วิดท์ และหน่วยความจำสำหรับการแคช
ใช้ตัวเลขกลม ๆ และประมาณโดยอิสระ ผู้สัมภาษณ์ให้ความสำคัญกับลำดับขนาดมากกว่าตัวเลขที่แม่นยำ ตัวอย่างสำหรับเครื่องย่อลิงก์: การเขียน 100M รายการ/วัน ÷ 86400 ≈ 1160 รายการ/วินาที การอ่าน 10B รายการ/วัน ÷ 86400 ≈ 115K รายการ/วินาที ระเบียนที่อยู่เว็บแต่ละรายการมีขนาดประมาณ 500 ไบต์: 100M × 500 ไบต์ = 50 GB/วัน, 18 TB/ปี
# Back-of-envelope for URL Shortener
writes_per_day = 100_000_000 # 100 million URLs/day
read_write_ratio = 100 # 100:1 read/write
reads_per_day = writes_per_day * read_write_ratio
bytes_per_url = 500 # url string + metadata
years_to_store = 5
print('=== Capacity Estimation ===')
print(f'Writes/sec: {writes_per_day / 86400:.0f}')
print(f'Reads/sec: {reads_per_day / 86400:,.0f}')
print(f'Storage/day: {writes_per_day * bytes_per_url / 1e9:.1f} GB')
print(f'Storage total ({years_to_store}y): {writes_per_day * bytes_per_url * 365 * years_to_store / 1e12:.1f} TB')
cache_hit_rate = 0.80
hot_urls = reads_per_day * (1 - cache_hit_rate)
print(f'\n80% cache hit rate: {cache_hit_rate*100}% of reads from cache')
print(f'DB reads/sec: {hot_urls / 86400:,.0f}')ขั้น A: การออกแบบเอพีไอ
กำหนด ขอบเขตเอพีไอ — การดำเนินการที่ระบบเปิดให้ไคลเอนต์และบริการภายในเรียกใช้ ระบุวิธีการร้องขอแบบเอชทีทีพี เส้นทางปลายทาง พารามิเตอร์คำขอ และรูปแบบการตอบกลับให้ชัดเจน สิ่งนี้เป็นหลักยึดให้การออกแบบส่วนที่เหลือ: ทุกอย่างมีอยู่เพื่อใช้งานเอพีไอเหล่านี้
สำหรับเครื่องย่อลิงก์ เอพีไอหลักสองรายการคือ: (1) POST /shorten เพื่อสร้างลิงก์สั้น (2) GET /{alias} เพื่อเปลี่ยนเส้นทาง ตัวเลือกเพิ่มเติม: DELETE /{alias} เพื่อลบ และ GET /{alias}/stats สำหรับการวิเคราะห์ ระบุรหัสตอบกลับด้วย (201 สร้างสำเร็จ, 301 เปลี่ยนเส้นทาง, 404 ไม่พบ)
# API Design for URL Shortener
apis = [
{
'method': 'POST',
'path': '/api/v1/shorten',
'request': '{"long_url": "https://...", "alias": "optional", "expires_at": "optional"}',
'response': '201 Created: {"short_url": "https://short.ly/abc1234", "alias": "abc1234"}',
},
{
'method': 'GET',
'path': '/{alias}',
'request': 'No body',
'response': '301 Redirect to long_url (or 404 Not Found)',
},
{
'method': 'GET',
'path': '/api/v1/{alias}/stats',
'request': 'Optional: date range query params',
'response': '200 OK: {"clicks": 42000, "unique_visitors": 15000}',
},
]
for api in apis:
print(f'{api["method"]} {api["path"]}')
print(f' Request: {api["request"]}')
print(f' Response: {api["response"]}')
print()ขั้น D: แบบจำลองข้อมูล
แบบจำลองข้อมูล กำหนดว่าจะจัดเก็บอะไรและจัดเก็บอย่างไร ระบุเอนทิตีหลักและแอตทริบิวต์ของเอนทิตีเหล่านั้น สำหรับเครื่องย่อลิงก์: ตาราง urls ที่มี alias (คีย์หลัก), long_url, created_at, expires_at และ user_id อาจมีตาราง clicks เพิ่มเติมสำหรับการวิเคราะห์
การเลือกประเภทพื้นที่จัดเก็บที่เหมาะสมเป็นสิ่งสำคัญ: ฐานข้อมูลเชิงสัมพันธ์สำหรับข้อมูลที่มีโครงสร้างและคำค้นหาซับซ้อน พื้นที่จัดเก็บแบบคีย์-ค่า (รีดิส, DynamoDB) สำหรับการค้นหาชื่อแฝงแบบ O(1) ในระบบขนาดใหญ่ และพื้นที่จัดเก็บออบเจกต์ (เอสทรี) สำหรับข้อมูลก้อนใหญ่ สำหรับเครื่องย่อลิงก์ พื้นที่จัดเก็บแบบคีย์-ค่าที่ใช้ชื่อแฝงเป็นคีย์เหมาะอย่างยิ่งสำหรับการอ่าน โดยมีฐานข้อมูลเชิงสัมพันธ์สำหรับการเขียนและการจัดการ
# Data model for URL Shortener
# Core table (PostgreSQL)
urls_schema = '''
CREATE TABLE urls (
alias VARCHAR(16) PRIMARY KEY, -- e.g., 'abc1234'
long_url TEXT NOT NULL,
user_id UUID REFERENCES users(id),
created_at TIMESTAMP DEFAULT NOW(),
expires_at TIMESTAMP,
click_count BIGINT DEFAULT 0
);
CREATE INDEX ON urls(user_id);
'''
# Cache layer (Redis) for hot reads
redis_schema = '''
alias => long_url # O(1) GET on cache hit
TTL = 24 hours (or until expiry)
Cache eviction: LRU
'''
print('PostgreSQL schema:')
print(urls_schema)
print('Redis cache:')
print(redis_schema)
print('Storage split: Redis for hot reads (~80%), PostgreSQL for writes and cold reads')ขั้น I: โครงสร้างพื้นฐานระดับสูง
ร่าง โครงสร้างพื้นฐาน ระดับสูง: เซิร์ฟเวอร์ใดรับผิดชอบงานใด ข้อมูลไหลระหว่างองค์ประกอบอย่างไร และใช้บริการภายนอกใดบ้าง สำหรับเครื่องย่อลิงก์ในระบบขนาดใหญ่:
- ตัวกระจายโหลด: กระจายการรับส่งข้อมูลไปยังชุดจำลองบริการเขียนและอ่าน
- บริการเขียน: สร้างชื่อแฝง ตรวจสอบความไม่ซ้ำ เขียนลงฐานข้อมูล และทำให้แคชใช้ไม่ได้
- บริการอ่าน/เปลี่ยนเส้นทาง: ตรวจสอบแคชรีดิสก่อน หากไม่พบจึงใช้ฐานข้อมูล
- ฐานข้อมูลเชิงสัมพันธ์: แหล่งข้อมูลจริง (พร้อมชุดจำลองสำหรับอ่าน)
- คลัสเตอร์รีดิส: แคชการจับคู่ที่อยู่เว็บยอดนิยมเพื่อการอ่านในระดับต่ำกว่าหนึ่งมิลลิวินาที
# ASCII architecture sketch
architecture = '''
Clients
|
[Load Balancer]
/ \\
[Write API] [Read/Redirect API]
| | |
[Alias Gen] [Redis Cache]
| |
[PostgreSQL]---->[Read Replicas]
Alias Generation:
- Base62 encoding of auto-incrementing ID
- 62^7 = 3.5 trillion unique URLs (enough for 5 years at 100M/day)
- OR random 7-char Base62 with collision check
'''
print(architecture)
print('Key design decisions:')
print(' - Read/Write split: separate services for scalability')
print(' - Cache-aside pattern: read from Redis, fallback to DB')
print(' - 301 vs 302 redirect: 301 cached by browser (less load), 302 always hits server (analytics)')ขั้น O: เพิ่มประสิทธิภาพและจัดการคอขวด
ระยะ เพิ่มประสิทธิภาพ จัดการคอขวดและขยายระบบ สำหรับเครื่องย่อลิงก์ ประเด็นสำคัญคือ เวลาแฝงของการเปลี่ยนเส้นทาง (วางรีดิสไว้ใกล้ผู้ใช้ด้วย CDN หรือแคชขอบเครือข่าย) ความไม่ซ้ำของชื่อแฝงในระบบขนาดใหญ่ (ใช้เซิร์ฟเวอร์ออกหมายเลขกลาง หรือใช้แฮชพร้อมการตรวจจับการชนกัน) และคอขวดการเขียนฐานข้อมูล (เขียนเป็นชุดหรือเขียนแบบไม่พร้อมกันผ่านคิว)
อภิปรายข้อแลกเปลี่ยนอย่างชัดเจน: การเปลี่ยนเส้นทางแบบ 301 ลดภาระเซิร์ฟเวอร์แต่ทำให้ความแม่นยำของการวิเคราะห์ลดลง ส่วนการเปลี่ยนเส้นทางแบบ 302 ติดตามได้แต่เพิ่มเวลาแฝง การแคชที่มีวันหมดอายุยาวนานช่วยลดภาระฐานข้อมูล แต่เสี่ยงทำให้ที่อยู่เว็บล้าสมัย การแสดงว่าคุณเข้าใจความตึงเครียดเหล่านี้บ่งบอกถึงแนวคิดระดับอาวุโส
# Key optimisation discussion points
optimisations = {
'Read latency': [
'Redis cluster in multiple regions (CDN-edge caching)',
'301 redirect for non-tracked URLs (client caches)',
'302 redirect when click analytics are needed',
],
'Write throughput': [
'Async writes: accept request, enqueue to Kafka, batch-commit to DB',
'Ticket server (centralised ID generator) to avoid UUID collision',
'Or: hash(user_id + timestamp + random) with retry on collision',
],
'Availability': [
'Multi-AZ PostgreSQL with automatic failover',
'Redis Sentinel or Redis Cluster for HA cache',
'Health checks + circuit breaker on each service',
],
'Storage': [
'Partition urls table by hash(alias) for horizontal scaling',
'Archive expired URLs to cold storage (S3)',
],
}
for area, points in optimisations.items():
print(f'{area}:')
for p in points: print(f' - {p}')
print()การสร้างชื่อแฝง: การเข้ารหัสเบส 62
รายละเอียดทางเทคนิคหลักของเครื่องย่อลิงก์คือวิธีสร้างชื่อแฝงที่สั้นและไม่ซ้ำกัน แนวทางมาตรฐานคือใช้ รหัส ID ที่เพิ่มขึ้นอัตโนมัติ จากฐานข้อมูล แล้วเข้ารหัสเป็น เบส 62 (ตัวเลข 0-9 ตัวอักษร a-z และ A-Z) สตริงเบส 62 ยาว 7 อักขระสามารถแทนที่อยู่เว็บที่ไม่ซ้ำกันได้ประมาณ 62^7 ≈ 3.5 ล้านล้านรายการ ซึ่งเพียงพอสำหรับหลายทศวรรษหากสร้างวันละ 100M รายการ
วิธีนี้ไม่มีการชนกัน (แต่ละ ID ไม่ซ้ำกัน) และสร้างสตริงสั้นที่ใช้ในที่อยู่เว็บได้อย่างปลอดภัย การจับคู่ ID→ชื่อแฝงกำหนดได้แน่นอนและย้อนกลับได้ ข้อแลกเปลี่ยนคือ ID แบบเรียงลำดับทำให้ชื่อแฝงคาดเดาได้ (เป็นข้อกังวลด้านความปลอดภัย) ให้สลับชุดอักขระเบส 62 หรือใช้ค่าชดเชยตัวนับเพื่อลดความสามารถในการคาดเดา
import string
BASE62_CHARS = string.digits + string.ascii_lowercase + string.ascii_uppercase
BASE = 62
def encode_base62(num):
if num == 0:
return BASE62_CHARS[0]
result = ''
while num:
result = BASE62_CHARS[num % BASE] + result
num //= BASE
return result
def decode_base62(s):
result = 0
for c in s:
result = result * BASE + BASE62_CHARS.index(c)
return result
# Generate aliases for IDs 1, 100, 1000, 10^9
for id_ in [1, 100, 1000, 1_000_000, 10**9, 3_521_614_606207]:
alias = encode_base62(id_)
decoded = decode_base62(alias)
print(f'ID {id_:20,} => alias "{alias}" (len={len(alias)}) => decoded={decoded}')การประยุกต์ใช้ RADIO กับการออกแบบฟีดทวิตเตอร์
ลองนำ RADIO มาประยุกต์ใช้กับ การออกแบบฟีดข่าวแบบทวิตเตอร์ โดยสังเขป เพื่อแสดงให้เห็นว่ากรอบงานนี้ใช้ได้กับกรณีทั่วไป:
- R: ผู้ใช้โพสต์ข้อความ ติดตามผู้อื่น และดูฟีดข้อความจากคนที่ตนติดตาม ขนาดระบบ: ผู้ใช้ 300M คน ข้อความ 500M รายการ/วัน ฟีดต้องโหลดเสร็จในเวลา <2 วินาที
- A:
POST /tweets,GET /feed,GET /timeline/{user_id} - D: ตาราง
tweets(รหัส, รหัสผู้ใช้, เนื้อหา, เวลาที่สร้าง); ตารางfollows(รหัสผู้ติดตาม, รหัสผู้ถูกติดตาม); แคชฟีดแยกตามผู้ใช้ - I: บริการกระจายข้อความจะเขียนข้อความใหม่ลงในฟีดของผู้ติดตาม (คำนวณไว้ล่วงหน้า); แคสซานดราสำหรับตารางการติดตาม/ข้อความที่เน้นการเขียน; รีดิสสำหรับแคชฟีด
# Fan-out on Write vs Fan-out on Read trade-off
fan_out_strategies = {
'Fan-out on Write (Push)': {
'How': 'When user A posts, immediately write to all followers feeds',
'Pro': 'O(1) feed read — feed is precomputed',
'Con': 'Celebrities with 10M followers => 10M writes per post; very slow write',
'Best for': 'Users with few followers (regular users)',
},
'Fan-out on Read (Pull)': {
'How': 'When user reads feed, query followees tweets and merge',
'Pro': 'Writes are fast (one DB write per tweet)',
'Con': 'Feed read is slow: must query all N followees',
'Best for': 'Celebrity accounts (few reads per post)',
},
'Hybrid': {
'How': 'Push for regular users, pull for celebrities',
'Pro': 'Balances read and write cost',
'Con': 'More complex implementation',
'Best for': 'Production systems like Twitter',
},
}
for strategy, details in fan_out_strategies.items():
print(f'{strategy}:')
for k, v in details.items(): print(f' {k}: {v}')
print()ข้อผิดพลาดที่พบบ่อยในการสัมภาษณ์การออกแบบระบบ
โปรดหลีกเลี่ยงข้อผิดพลาดที่เกิดขึ้นบ่อยเหล่านี้ ซึ่งอาจทำให้การสัมภาษณ์การออกแบบระบบไม่ราบรื่น:
- รีบเสนอวิธีแก้ไข: การวาดกล่องต่าง ๆ ก่อนทำความเข้าใจข้อกำหนดให้ชัดเจน แสดงให้เห็นถึงนิสัยการทำงานด้านวิศวกรรมที่ไม่ดี
- ไม่ประเมินขนาด: การออกแบบโดยไม่รู้ขนาดของระบบเป็นเพียงการคาดเดา
- ออกแบบเกินความจำเป็น: การออกแบบเพื่อรองรับผู้ใช้ 1 พันล้านคน ทั้งที่โจทย์ระบุว่ามี 10,000 คน เป็นการเสียเวลาในการสัมภาษณ์
- ไม่พูดถึงข้อแลกเปลี่ยน: ทุกทางเลือกมีข้อดีและข้อเสีย การไม่กล่าวถึงสิ่งเหล่านี้แสดงให้เห็นถึงความเข้าใจที่ผิวเผิน
- เงียบ: ผู้สัมภาษณ์จำเป็นต้องได้ยินกระบวนการคิดของคุณ โปรดอธิบายเหตุผลของการตัดสินใจขณะตัดสินใจ
# Checklist: before you stop talking, verify you covered:
checklist = [
'[ ] Asked clarifying questions about scale and constraints',
'[ ] Made capacity estimates (RPS, storage, bandwidth)',
'[ ] Defined the API surface clearly',
'[ ] Described the data model and storage choices',
'[ ] Drew a high-level architecture with named components',
'[ ] Identified the main bottleneck and proposed a solution',
'[ ] Discussed at least one trade-off explicitly',
'[ ] Verified the design meets the stated requirements',
]
for item in checklist:
print(item)ตรวจสอบความเข้าใจ
ทดสอบความเข้าใจเกี่ยวกับแนวคิดโครงสร้างข้อมูล & อัลกอริทึม — การเตรียมตัวสำหรับการสัมภาษณ์การเขียนโปรแกรมจากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า กรอบงาน RADIO ใช้จัดโครงสร้างการสัมภาษณ์การออกแบบระบบเป็นข้อกำหนด, API, แบบจำลองข้อมูล, โครงสร้างพื้นฐาน และการเพิ่มประสิทธิภาพ, ควรทำความเข้าใจข้อกำหนดด้านการทำงานและข้อกำหนดที่ไม่ใช่ด้านการทำงานให้ชัดเจนเสมอ รวมทั้งประเมินความจุก่อนเสนอการออกแบบ และ ควรพูดถึงข้อแลกเปลี่ยนอย่างชัดเจน — ทุกการตัดสินใจด้านการออกแบบมีข้อดีและข้อเสียที่ผู้สัมภาษณ์คาดหวังให้คุณอธิบาย บทถัดไปเราจะสำรวจวิธีเลือกระหว่างที่จัดเก็บข้อมูลแบบ SQL และ NoSQL โดยพิจารณาจากรูปแบบการเข้าถึง ความสอดคล้อง และขนาดของระบบ
คำถามที่พบบ่อย
บทเรียน “กรอบการสัมภาษณ์ด้านการออกแบบระบบ” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “กรอบการสัมภาษณ์ด้านการออกแบบระบบ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส DSA Interview Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส DSA Interview Prep มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “กรอบการสัมภาษณ์ด้านการออกแบบระบบ”
เรียนรู้กรอบ RADIO ห้าขั้นตอน (Requirements, API, Data, Infrastructure, Optimise) และฝึกนำไปใช้กับบริการย่อลิงก์ URL คุณปฏิบัติ DSA Interview Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน DSA Interview Prep หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน DSA Interview Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน
บทเรียน “กรอบการสัมภาษณ์ด้านการออกแบบระบบ” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน DSA Interview Prep นี้ได้ไหม
ได้ บทเรียน DSA Interview Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- กรอบการสัมภาษณ์ด้านการออกแบบระบบ
- การจัดเก็บข้อมูลที่ขยายขนาดได้: SQL กับ NoSQL
- แคช, CDN และการกระจายโหลด
- การออกแบบตัวจำกัดอัตราและฟีด Twitter