Teduco Labs

Teduco Labs Software Engineering • AI • Architecture • Tech Career

TEDU là từ viết tắt của Technology Education, là một thương hiệu được xây dựng bắt đầu từ kênh dào tạo trực tuyến trên Youtube dưới dạng vBlog chia sẻ các video về thủ thuật và khóa học công nghệ miễn phí cho mọi người.

02/09/2026

Chào mừng Quốc khánh 2/9, TEDU giảm giá 60% các khoá học đến hết 9/9.

UUID không làm database chậm chỉ vì nó là UUID.Vấn đề thường nằm ở randomness + index size.Ví dụ UUID v4:a1f4... → 7c21....
28/08/2026

UUID không làm database chậm chỉ vì nó là UUID.

Vấn đề thường nằm ở randomness + index size.

Ví dụ UUID v4:

a1f4... → 7c21... → 03af... → d892...

Các record mới có thể được insert vào nhiều vị trí khác nhau trong B-Tree → dễ xảy ra page split, fragmentation và index lớn hơn.

Trong khi đó:

INT = 4 bytes
BIGINT = 8 bytes
UUID = 16 bytes

Nhưng nếu cần generate ID ở nhiều service thì auto-increment lại không phải lúc nào cũng phù hợp.

Đây là lúc UUID v7 khá hay.

UUID v7 vẫn là UUID, vẫn generate được ở application, nhưng có phần timestamp nên giá trị có xu hướng tăng theo thời gian → locality tốt hơn UUID v4.

Với .NET hiện tại có thể làm khá đơn giản:

public class Order
{
public Guid Id { get; set; } = Guid.CreateVersion7();

public decimal Amount { get; set; }
}

PostgreSQL:

CREATE TABLE orders (
id uuid PRIMARY KEY,
amount numeric(18,2)
);

EF Core:

modelBuilder.Entity()
.HasKey(x => x.Id);

Khi insert:

0198a7d0-...
0198a7d1-...
0198a7d2-...
0198a7d3-...

thay vì random hoàn toàn như UUID v4.

Tất nhiên UUID v7 không phải "magic bullet". Nó vẫn lớn hơn BIGINT, và hiệu quả thực tế còn phụ thuộc database engine, index và workload.

Nhưng với hệ thống .NET + PostgreSQL + microservices, UUID v7 là một option rất đáng cân nhắc:

Distributed ID generation + UUID semantics + better index locality than UUID v4.

Đừng hỏi đơn giản: "UUID hay INT cái nào nhanh hơn?"

Nên hỏi:

"Workload của hệ thống tôi là gì, và ID strategy nào phù hợp với nó?"

Nếu là một .NET Developer truyền thống và muốn bước sang AI, theo tôi không cần học lan man. Có thể chia thành 7 level k...
26/08/2026

Nếu là một .NET Developer truyền thống và muốn bước sang AI, theo tôi không cần học lan man. Có thể chia thành 7 level khá rõ:

**1. AI-Assisted Development**
Dùng AI để code, debug, refactor, viết test và tài liệu tốt hơn.

**2. LLM Fundamentals**
Hiểu token, context, embedding, structured output, tool calling, streaming và cách chọn model.

**3. RAG & AI Data**
Biết đưa dữ liệu của mình vào AI: embedding, vector database, semantic search, chunking, reranking.

**4. AI Agent Engineering**
Xây agent có tool, memory, planning, RAG và MCP để có thể thực sự thực hiện công việc.

**5. Evaluation & Testing**
Đo chất lượng AI, kiểm tra hallucination, regression, RAG/Agent evaluation thay vì chỉ thấy "chạy được".

**6. AI Security & Governance**
Xử lý prompt injection, data leakage, tool authorization, tenant isolation và bảo vệ dữ liệu.

**7. AI Production Engineering**
Đưa AI lên production: observability, model gateway, cost/token tracking, caching, rate limiting, fallback, scaling.

Với một .NET Developer đã có nền tảng **backend, database, architecture, DevOps và security**, tôi nghĩ đây là cách khá thực tế để chuyển sang AI Engineering mà không phải bỏ đi những gì mình đã tích lũy.

Dạo này tôi thấy khá nhiều anh em nói về Rate Limiting, nên chia sẻ một cách đơn giản về 3 strategy tôi hay gặp nhất.1. ...
24/08/2026

Dạo này tôi thấy khá nhiều anh em nói về Rate Limiting, nên chia sẻ một cách đơn giản về 3 strategy tôi hay gặp nhất.

1. Fixed Window
Cứ mỗi 1 phút cho phép tối đa 100 request. Dễ hiểu, dễ implement, hiệu năng tốt.
Nhược điểm là có thể gặp boundary problem — cuối phút gửi 100 request, sang phút mới lại gửi tiếp 100 request.

2. Sliding Window
Thay vì chia cứng theo từng phút, hệ thống luôn nhìn lại 60 giây gần nhất. Vì vậy kiểm soát chính xác hơn và tránh được vấn đề của Fixed Window.

3. Token Bucket
Tưởng tượng có một cái bucket chứa token. Mỗi request lấy 1 token, token được refill đều đặn.
Cách này khá hay khi hệ thống cần chịu burst traffic nhưng vẫn muốn giới hạn tốc độ trung bình.

Nếu nhớ nhanh thì:

Fixed Window → đơn giản
Sliding Window → chính xác hơn
Token Bucket → chịu burst tốt

Không có strategy nào luôn tốt nhất. Quan trọng là hiểu traffic của hệ thống mình rồi chọn cho đúng.

Làm integration nhiều rồi tôi nhận ra: API gọi được nhau chỉ mới là phần dễ.7 thứ tôi luôn quan tâm khi tích hợp 2 hệ th...
24/08/2026

Làm integration nhiều rồi tôi nhận ra: API gọi được nhau chỉ mới là phần dễ.

7 thứ tôi luôn quan tâm khi tích hợp 2 hệ thống:

1. Identity – Ai đang gọi? Authenticate, Authorize, Signature, mTLS...

2. Contract – Hai bên hiểu cùng một schema, business rule và version.

3. Reliability – Timeout, retry, backoff, circuit breaker. Network chắc chắn sẽ có lúc lỗi.

4. Idempotency – Request gửi lại 2-3 lần cũng không được tạo duplicate. Đặc biệt quan trọng với Payment, Order, Loyalty.

5. Consistency – Đừng nghĩ HTTP 200 = mọi thứ thành công. Phải có transaction tracking và **reconciliation** để phát hiện lệch dữ liệu.

6. Observability – Có Correlation ID, log, metric, tracing để biết request đã đi đâu và chết ở đâu.

7. Change Management – API sẽ thay đổi. Phải có versioning, backward compatibility, contract testing và deprecation strategy.

Tóm lại:

> Integration tốt không phải là gọi API thành công, mà là khi network lỗi, request duplicate, response mất hoặc partner thay đổi API, hệ thống vẫn giữ được business consistency và recover được.

**Lộ trình cho một .NET Backend Developer đã có nền tảng về máy tính và lập trình 🧵**Nếu bạn đã có kiến thức cơ bản về m...
23/08/2026

**Lộ trình cho một .NET Backend Developer đã có nền tảng về máy tính và lập trình 🧵**

Nếu bạn đã có kiến thức cơ bản về máy tính và lập trình, mình nghĩ không cần học .NET theo kiểu “học hết mọi thứ”.

Hãy đi theo roadmap từ **language → data → web → deployment → architecture**.

**1/ C # từ cơ bản đến intermediate**

Tập trung vào những thứ thực sự dùng hàng ngày:

* Syntax & Type System
* OOP
* Collections & LINQ
* Exception & Resource Management
* File & I/O
* Delegate, Event
* Generics
* Async/Await & Threading
* Một số Design Patterns phổ biến

Mục tiêu: **viết được C # tốt trước khi viết ASP.NET Core.**

**2/ Database & SQL**

Chọn **một** hệ quản trị để học thật chắc:

* SQL Server
* PostgreSQL
* MySQL

Nắm được:

* Relational Database
* Table, Index, Constraint
* JOIN
* Transaction
* Query optimization
* Ex*****on Plan
* Normalization
* Stored Procedure / Function ở mức cần thiết

Đừng chỉ học cách dùng EF Core mà không hiểu database phía dưới.

**3/ ASP.NET Core & REST API**

Đây là phần bắt đầu trở thành Backend Developer thực sự.

Học theo thứ tự:

* HTTP & Web fundamentals
* ASP.NET Core Web Application
* Request Pipeline & Middleware
* Dependency Injection
* Routing
* Controller / Minimal API
* Model Binding & Validation
* JSON & Serialization
* Entity Framework Core
* Authentication & Authorization
* Caching
* Logging & Error Handling
* API Documentation
* Clean Architecture

Mục tiêu không phải chỉ là “tạo được CRUD API”, mà phải hiểu **một request đi qua hệ thống như thế nào**.

**4/ Deployment & Linux**

Một Backend Developer nên biết đưa application của mình lên server.

Có thể bắt đầu với:

**Windows:**NET + IIS

hoặc

**Linux:**NET + Nginx

Sau đó học tiếp:

* DNS
* HTTPS / SSL
* Reverse Proxy
* Process Management
* Environment Configuration
* Docker
* CI/CD

Đến đây, bạn đã có thể tự xây dựng và vận hành một Backend Application tương đối hoàn chỉnh.

**5/ Sau đó mới đi sâu**

Khi nền tảng đã chắc, mới tiếp tục:

* Distributed Systems
* Message Queue
* Redis
* Microservices
* Observability
* Security
* Cloud / AWS / Azure
* Kubernetes
* System Design

Một sai lầm khá phổ biến là **học Microservices, Docker, Kubernetes, AWS... khi còn chưa hiểu rõ HTTP, SQL, async/await và ASP.NET Core pipeline.**

Học Backend không phải là học càng nhiều technology càng tốt.

Quan trọng hơn là xây dựng năng lực theo đúng thứ tự:

**C # → Database → Web → API → Deployment → Architecture → Distributed Systems**

Đó là con đường mình nghĩ khá phù hợp cho một .NET Backend Developer từ junior lên senior.

22/08/2026

Email lạ? Đây là cách phishing hoạt động
Phishing không chỉ là email giả. Hiểu cách kẻ xấu dựng kịch bản, dẫn dắt nạn nhân vào web giả và chiếm thông tin đăng nhập để phòng tránh tốt hơn.

22/08/2026

2FA hoạt động như thế nào?
Video giải thích cơ chế 2FA bằng ví dụ cụ thể: mật khẩu, mã OTP, TOTP, hạn chế của SMS và cách chọn phương thức phù hợp. Hướng đến người muốn hiểu bản chất kỹ thuật trước khi áp dụng.

12/08/2026

Ba Lớp Sản Phẩm Dev AI
Hiểu ngay 3 tầng commodity, product, moat để xây sản phẩm AI không bị sao chép. Video thực chiến cho dev, có ví dụ và lưu ý trade-off.

10/08/2026

Monolith, Modular hay Microservices? Chọn sao cho đúng?
So sánh nhanh Monolith, Modular và Microservices: đặc điểm, ưu nhược điểm và điều kiện nên dùng. Video rút gọn cho dev cần chọn kiến trúc thực tế.

Address

Tầng 2 Tòa Nhà Detech Tower, Số 8 Tôn Thất Thuyết, Cầu Giấy
Hanoi
10000

Telephone

+84966036626

Website

Alerts

Be the first to know and let us send you an email when Teduco Labs posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Contact The Business

Send a message to Teduco Labs:

Shortcuts

Share