Ngân hàng đề — AWS Certified Developer Associate

Đáp án

D, E và F.

• F — Mở cả cổng 80 và cổng 443.
• D — Gắn chứng chỉ SSL vào Load Balancer.
• E — Cấu hình EC2 instance chuyển hướng HTTP sang HTTPS.

Vì sao đúng

Đề đòi hai endpoint cùng hoạt động: HTTPS cho traffic thật, HTTP để chuyển hướng sang HTTPS.

F — mở cả hai cổng. Vì cả hai đều phải nhận request:

Port 443 → traffic đã mã hoá, đi tới ứng dụng
Port 80  → nhận request http:// rồi trả về 301 sang https://

Đóng cổng 80 thì URL bắt đầu bằng http:// không kết nối được — người dùng gõ tên miền vào trình duyệt (mặc định là HTTP) sẽ gặp lỗi. Đề nói rõ phải hỗ trợ URL bắt đầu bằng http://.

D — chứng chỉ ở load balancer. Đây là mẫu TLS termination chuẩn: load balancer giải mã, rồi chuyển traffic (thường là HTTP) tới instance. Nhờ đó CPU của instance không phải làm việc mã hoá, và chứng chỉ quản lý ở một chỗ thay vì trên từng máy.

Cấu hình qua .ebextensions:

option_settings:
  aws:elbv2:listener:443:
    Protocol: HTTPS
    SSLCertificateArns: arn:aws:acm:ap-southeast-1:123456789012:certificate/xxxx
  aws:elbv2:listener:80:
    Protocol: HTTP

E — chuyển hướng HTTP sang HTTPS. Đúng chiều: người dùng vào bằng http:// được đưa sang https://.

Vì sao các phương án khác sai

• A. Chỉ mở cổng 443 — URL http:// không kết nối được, vi phạm yêu cầu.
• C. Chỉ mở cổng 80 — không có HTTPS, mất hẳn vế mã hoá.
• B. "Chuyển hướng HTTPS sang HTTP" — đảo ngược chiều, và đây là lỗi bảo mật nghiêm trọng: nó đẩy người dùng từ kết nối an toàn xuống kết nối không mã hoá.

Ghi nhớ

Cấu hình HTTPS chuẩn cho ứng dụng web:

Người dùng ──HTTP:80──→  ALB  ──301 redirect──→  https://
Người dùng ──HTTPS:443─→ ALB (chứng chỉ ACM) ──HTTP──→ EC2

Ngày nay ALB có redirect action dựng sẵn, không cần cấu hình gì trên EC2:

{"Type": "redirect",
 "RedirectConfig": {"Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}

Và ba lưu ý về chứng chỉ:

• ACM miễn phí cho chứng chỉ công cộng và tự gia hạn
• Chứng chỉ cho CloudFront bắt buộc cấp ở us-east-1
• Nên bật HSTS (Strict-Transport-Security) để trình duyệt tự dùng HTTPS ở các lần sau

Đáp án

C — Tạo EC2 service role với quyền chỉ đọc bucket S3 và gắn vào instance profile của EC2.

Vì sao đúng

Đây là kết hợp của ba thực hành tốt nhất, và điểm phân biệt nằm ở loại role:

1. Dùng role, không dùng khoá tĩnh. Instance profile cấp thông tin xác thực tạm thời, tự xoay vòng; SDK tự tìm thấy chúng.

2. Đúng loại service role. Đây là điểm loại giữa C và A. Role phải có trust policy cho ec2.amazonaws.com — tức là EC2 mới là dịch vụ được phép assume role này:

{
  "Effect": "Allow",
  "Principal": {"Service": "ec2.amazonaws.com"},
  "Action": "sts:AssumeRole"
}

3. Đặc quyền tối thiểu. Chỉ cần đọc:

{"Effect": "Allow",
 "Action": ["s3:GetObject", "s3:ListBucket"],
 "Resource": ["arn:aws:s3:::kho-video", "arn:aws:s3:::kho-video/*"]}

Vì sao các phương án khác sai

• A. "S3 service role" — bẫy tinh vi nhất, và nó sai ở chiều của trust policy. Một "S3 service role" là role mà dịch vụ S3 assume (Principal: {"Service": "s3.amazonaws.com"}) — dùng khi S3 cần hành động thay mặt bạn, ví dụ cho replication. Ở đây chiều ngược lại: EC2 cần đọc S3, nên role phải cho EC2 assume. Role sai trust policy thì không gắn vào instance profile được.
• D. IAM user + chạy aws configure trên instance — ghi access key tĩnh vào ~/.aws/credentials. Chạy được, nhưng khoá nằm trên đĩa, không tự hết hạn, phải xoay vòng thủ công, và đi theo mọi AMI được nhân bản.
• B. IAM user + đặt thông tin xác thực trong user data — tệ nhất trong bốn phương án. User data đọc được bởi mọi tiến trình trên máy qua http://169.254.169.254/latest/user-data, kể cả ứng dụng đã bị chiếm quyền. Đây là cách cất bí mật tồi nhất có thể.

Ghi nhớ

Trust policy quyết định ai được assume role — và đó là thứ phân biệt các loại service role: | Role dành cho | Principal.Service | |---|---| | EC2 | ec2.amazonaws.com | | Lambda | lambda.amazonaws.com | | ECS task | ecs-tasks.amazonaws.com | | CodeBuild | codebuild.amazonaws.com | | S3 (cho replication) | s3.amazonaws.com |

Và nhớ mẹo làm bài: thấy "access key", "aws configure", hay "credentials trong user data" ⇒ gần như chắc chắn loại được phương án đó.

Nên bật thêm IMDSv2 để chống SSRF lấy thông tin xác thực từ metadata:

aws ec2 modify-instance-metadata-options --instance-id i-xxx --http-tokens required

Đáp án

B — Chiến lược ghi vào backend trước, rồi vô hiệu hoá cache.

Vì sao đúng

Yêu cầu quan trọng nhất: cache không bao giờ được lệch với backend — giá sản phẩm và mô tả phải luôn đúng.

Write-around + cache invalidation đảm bảo điều đó bằng thứ tự thao tác:

def cap_nhat_gia(ma_sp, gia_moi):
    rds.update("UPDATE san_pham SET gia = %s WHERE id = %s", (gia_moi, ma_sp))  # 1. ghi CSDL
    cache.delete(f"sp:{ma_sp}")                                                  # 2. XOÁ cache
    # Lần đọc tiếp theo sẽ trượt cache và nạp lại giá mới từ CSDL

Vì sao thứ tự này an toàn nhất:

Điểm mấu chốt: xoá cache an toàn hơn cập nhật cache. Một entry trống chỉ gây một lần đọc chậm; một entry sai gây dữ liệu sai cho tới khi hết TTL.

Vì sao các phương án khác sai

• C. Cập nhật cache và backend cùng lúc — vấn đề là không có tính nguyên tử: nếu ghi CSDL thành công mà ghi cache thất bại (hoặc ngược lại), hai bên lệch nhau vĩnh viễn mà không có cơ chế tự sửa. Đây chính là điều đề muốn tránh.
• A. Ghi vào cache trước, đồng bộ backend sau (write-back) — cho hiệu năng ghi cao nhất, nhưng rủi ro mất dữ liệu: cache node hỏng trước khi đồng bộ là mất hẳn lần cập nhật đó. Với dữ liệu giá cả trong đợt bán hàng, đây là rủi ro không chấp nhận được.
• D. Ghi backend trước rồi chờ cache hết hạn qua TTL — cache cố ý phục vụ dữ liệu cũ cho tới hết TTL. Với giá sản phẩm trong đợt sale, hiển thị giá sai dù chỉ vài phút cũng là vấn đề nghiêm trọng về nghiệp vụ.

Ghi nhớ

Bốn chiến lược cache và đánh đổi: | Chiến lược | Nhất quán | Hiệu năng ghi | Rủi ro | |---|---|---|---| | Write-around + invalidate | cao | tốt | lần đọc sau chậm | | Write Through | cao | chậm (ghi hai nơi) | cache đầy dữ liệu không dùng | | Write Back | thấp | nhanh nhất | mất dữ liệu khi node hỏng | | Lazy Loading + TTL | trung bình | tốt | dữ liệu cũ trong cửa sổ TTL |

Mẫu được dùng nhiều nhất trong thực tế cho dữ liệu quan trọng: Lazy Loading + TTL + invalidation khi ghi — kết hợp cả ba lớp bảo vệ. Lazy loading giữ cache nhỏ, invalidation đảm bảo đúng ngay, TTL là lưới an toàn khi invalidation thất bại.

Đáp án

A — GSI đang bị throttle, cần cấp thêm RCU và WCU cho GSI.

Vì sao đúng

Đây là khác biệt cốt lõi giữa hai loại secondary index của DynamoDB:

GSI có throughput riêng. Bảng chính có thể dư dả RCU/WCU trong khi GSI chạm trần và bị throttle — và đó là điều đang xảy ra: bảng chạy tốt suốt một năm, thêm index vào thì mới có vấn đề.

Có một hệ quả rất quan trọng và hay gây bất ngờ: nếu GSI hết WCU, lệnh ghi vào BẢNG CHÍNH cũng bị throttle. Lý do là DynamoDB phải cập nhật index đồng bộ với bảng — không ghi được index thì không ghi được bảng.

Cách chẩn đoán:

aws cloudwatch get-metric-statistics --namespace AWS/DynamoDB \
  --metric-name ThrottledRequests \
  --dimensions Name=TableName,Value=phim Name=GlobalSecondaryIndexName,Value=idx-the-loai

Metric của GSI có dimension riêng, nên phải xem đúng chỗ mới thấy.

Vì sao các phương án khác sai

• B. "LSI đang throttle, cần cấp thêm RCU/WCU cho LSI" — không cấp riêng cho LSI được. LSI dùng chung capacity với bảng gốc; muốn tăng thì tăng ở bảng. Câu này mô tả một thao tác không tồn tại.
• C. "Metric CloudWatch bị trễ, vài phút nữa sẽ thấy bảng chính peak" — throttle là lỗi thật trả về ngay tại lời gọi API (ProvisionedThroughputExceededException), không phải vấn đề hiển thị.
• D. "AWS khuyến nghị không thêm cả LSI lẫn GSI vào một bảng" — không có khuyến nghị nào như vậy. Dùng cả hai là hoàn toàn hợp lệ và phổ biến.

Ghi nhớ

Ba điều cần thuộc về capacity của index:

1. GSI có capacity RIÊNG — phải cấp và giám sát độc lập
2. LSI dùng chung capacity với bảng
3. GSI hết WCU ⇒ ghi vào bảng chính cũng bị throttle

Điểm thứ ba là nguyên nhân của rất nhiều sự cố khó hiểu: bảng nhìn còn dư throughput mà vẫn báo throttle. Luôn kiểm metric của từng GSI, không chỉ của bảng.

(Với chế độ on-demand, GSI tự co giãn cùng bảng và vấn đề này biến mất.)

Đáp án

A và E.

• E — Ứng dụng ghi response time ra tệp log, cài CloudWatch Agent đẩy log lên CloudWatch.
• A — Tạo CloudWatch alarm gửi SNS notification khi giá trị trung bình vượt ngưỡng.

Vì sao đúng

Yêu cầu: theo dõi thời gian phản hồi trung bình của ứng dụng và báo cho quản lý khi vượt ngưỡng — và giải pháp phải mở rộng được lên nhiều instance.

E — thu thập dữ liệu. Response time của ứng dụng không phải metric có sẵn trên EC2. Hypervisor chỉ thấy CPU, mạng, đĩa — nó không biết gì về ứng dụng bên trong. Nên ứng dụng phải tự ghi ra, và CloudWatch Agent đẩy lên:

{"logs": {"logs_collected": {"files": {"collect_list": [{
  "file_path": "/var/log/ung-dung/response-time.log",
  "log_group_name": "ung-dung/response-time",
  "log_stream_name": "{instance_id}"
}]}}},
 "metrics": {"append_dimensions": {"AutoScalingGroupName": "${aws:AutoScalingGroupName}"}}}

Kèm metric filter để biến dòng log thành metric số.

A — cảnh báo. CloudWatch alarm là cơ chế chuẩn: đặt trên thống kê Average của metric, và SNS làm target:

aws cloudwatch put-metric-alarm --alarm-name response-time-cao \
  --metric-name ResponseTime --namespace UngDung \
  --statistic Average --period 300 --threshold 2000 \
  --comparison-operator GreaterThanThreshold --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:...:canh-bao-quan-ly

Vế mở rộng cũng được đảm bảo: cài agent qua SSM State Manager thì mọi instance mới tự có, và alarm tính trung bình trên toàn nhóm.

Vì sao các phương án khác sai

• D. Dùng EventBridge rule để gửi SNS khi trung bình vượt ngưỡng — EventBridge không đánh giá ngưỡng metric. Nó định tuyến sự kiện, không so sánh số. Việc so với ngưỡng là của CloudWatch alarm. (EventBridge có thể nhận sự kiện thay đổi trạng thái của alarm — nhưng vẫn cần alarm trước.)
• B. Dùng SSM Agent để theo dõi response time — SSM Agent dùng để chạy lệnh, vá, kiểm kê. Nó không thu thập metric ứng dụng; công cụ đó là CloudWatch Agent.
• C. Dùng Amazon Inspector agent đọc log — Inspector quét lỗ hổng phần mềm và phơi nhiễm mạng. Nó không phải tác nhân thu log, và bản Inspector hiện nay còn không dùng agent riêng.

Ghi nhớ

Ba agent hay bị lẫn: | Agent | Vai trò | |---|---| | CloudWatch Agent | thu log và metric (bộ nhớ, đĩa, log ứng dụng) | | SSM Agent | chạy lệnh, vá, kiểm kê, Session Manager | | Inspector | quét lỗ hổng (nay dựa trên SSM Agent) |

Và nhớ ba metric không có sẵn trên EC2: bộ nhớ, dung lượng đĩa còn trống, swap — cộng với mọi metric của ứng dụng.

Đáp án

A — Nền tảng Docker multi-container.

Vì sao đúng

Yêu cầu rất cụ thể: mỗi EC2 instance chạy 3 container Docker khác nhau cùng lúc.

Elastic Beanstalk có hai nền tảng Docker, và chúng khác nhau đúng ở điểm đó:

Multi-container platform dùng ECS bên dưới, nên nó có đầy đủ khái niệm task definition, và bạn khai nhiều container trong một tệp:

{
  "AWSEBDockerrunVersion": 2,
  "containerDefinitions": [
    {"name": "web",   "image": "nginx",       "memory": 256,
     "portMappings": [{"hostPort": 80, "containerPort": 80}],
     "links": ["api"]},
    {"name": "api",   "image": "...ecr.../api:v1",  "memory": 512},
    {"name": "worker","image": "...ecr.../worker:v1","memory": 256}
  ]
}

Ba container này chạy trên cùng một instance, chia sẻ tài nguyên và liên lạc được với nhau qua links — đúng yêu cầu.

Vì sao các phương án khác sai

• C. Docker single-container platform — chỉ chạy được MỘT container trên mỗi instance. Đó chính là giới hạn mà đề cần vượt qua.
• D. Custom platform — cho phép dựng nền tảng riêng bằng Packer cho ngôn ngữ hoặc runtime mà Beanstalk chưa hỗ trợ. Rất nhiều công sức, và hoàn toàn không cần thiết vì multi-container platform đã làm sẵn.
• B. "Third-party platform" — không phải một loại nền tảng của Elastic Beanstalk. Beanstalk có nền tảng dựng sẵn (Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker) và custom platform — không có mục nào tên như vậy.

Ghi nhớ

Các nền tảng Docker của Elastic Beanstalk: | Nền tảng | Đặc điểm | |---|---| | Docker (single container) | 1 container/instance, đơn giản nhất | | Docker (multi-container) | nhiều container/instance, chạy trên ECS | | Preconfigured Docker | image dựng sẵn cho một số runtime |

Ghi chú thời sự: nền tảng Multi-container Docker (Amazon Linux AMI) đã bị AWS đánh dấu lỗi thời; với Amazon Linux 2 trở lên, cách được khuyến nghị là dùng ECS-managed Docker platform hoặc chuyển thẳng sang Amazon ECS. Với hệ thống mới cần nhiều container, ECS hoặc EKS thường là lựa chọn đúng hơn Beanstalk.

Đáp án

C — DynamoDB Transactions.

Vì sao đúng

Yêu cầu: cập nhật hai bảng cùng lúc hoặc không bảng nào — đó chính là định nghĩa của tính nguyên tử (atomicity).

TransactWriteItems đảm bảo đầy đủ tính chất ACID trên tối đa 100 thao tác, kể cả khi chúng nằm ở nhiều bảng khác nhau:

dynamodb.transact_write_items(TransactItems=[
    {'Update': {
        'TableName': 'AccountBalance',
        'Key': {'account_id': {'S': 'A-001'}},
        'UpdateExpression': 'SET so_du = so_du - :n',
        'ConditionExpression': 'so_du >= :n',        # không đủ tiền → HUỶ TẤT CẢ
        'ExpressionAttributeValues': {':n': {'N': '1000'}}}},
    {'Put': {
        'TableName': 'Exchanges',
        'Item': {'exchange_id': {'S': 'E-999'}, 'so_tien': {'N': '1000'}},
        'ConditionExpression': 'attribute_not_exists(exchange_id)'}}
])

Bất kỳ điều kiện nào không thoả — tài khoản không đủ số dư, hoặc giao dịch đã tồn tại — thì toàn bộ giao dịch bị huỷ, không bảng nào bị thay đổi.

Với ứng dụng ngân hàng, đây là yêu cầu không thể thoả hiệp: trừ tiền mà không ghi giao dịch, hoặc ghi giao dịch mà không trừ tiền, đều là lỗi nghiêm trọng.

Giới hạn cần biết: tối đa 100 thao tác hoặc 4 MB, mỗi item chỉ xuất hiện một lần, và chi phí gấp đôi ghi thường (2 WCU cho mỗi 1 KB) — cái giá của tính nguyên tử.

Vì sao các phương án khác sai

• A. DynamoDB Streams — ghi lại thay đổi dữ liệu để hệ khác tiêu thụ. Dùng nó để đồng bộ hai bảng sẽ cho mô hình eventual consistency: bảng thứ nhất ghi trước, Lambda cập nhật bảng thứ hai sau. Trong khoảng giữa, dữ liệu không nhất quán — và nếu Lambda hỏng thì hai bảng lệch nhau vĩnh viễn.
• B. DynamoDB Indexes — GSI và LSI mở ra kiểu truy vấn mới, hoàn toàn không liên quan tới tính nguyên tử khi ghi.
• D. DynamoDB TTL — tự động xoá item hết hạn. Chẳng liên quan gì tới giao dịch.

Ghi nhớ

Câu thần chú: "all-or-nothing", "at the same time or not at all", "simultaneously" ⇒ Transactions, KHÔNG phải Batch. BatchWriteItem chỉ gộp lời gọi để giảm round trip; từng thao tác vẫn thành công hoặc thất bại độc lập.

Đáp án

A — AWS CodeStar.

Vì sao đúng

Yêu cầu rất đặc trưng: cần một dashboard tổng thể cho toàn bộ nhu cầu CI/CD, và không cần kiểm soát chi tiết từng thành phần.

CodeStar là lớp bọc phía trên toàn bộ bộ công cụ Code của AWS. Nó cho một giao diện thống nhất với:

Chọn một project template (ngôn ngữ + nền tảng) là CodeStar tạo sẵn tất cả, cùng với IAM role, và hiển thị mọi thứ trên một dashboard: trạng thái pipeline, commit gần đây, issue từ JIRA hoặc GitHub, thành viên nhóm.

Đó chính là "one-stop dashboard" — đổi lại là ít quyền tuỳ chỉnh chi tiết, đúng như đề nói là chấp nhận được.

Vì sao các phương án khác sai

• D. CodePipeline — dịch vụ điều phối rất mạnh, và có giao diện xem tiến trình pipeline. Nhưng nó chỉ hiển thị pipeline: không có repository, không có issue tracking, không có quản lý thành viên. Nó là một thành phần, không phải cái nhìn tổng thể.
• B. CodeBuild — chỉ lo biên dịch và kiểm thử. Không điều phối, không triển khai, không có dashboard tổng thể.
• C. CodeDeploy — chỉ lo triển khai lên EC2, ECS, Lambda. Cũng chỉ là một mắt xích.

Ghi nhớ về chất lượng câu hỏi

AWS đã ngừng dịch vụ CodeStar — từ 31/7/2024, không tạo được project mới, và các project cũ cũng đã ngừng hoạt động.

Lựa chọn thay thế hiện hành: | Nhu cầu | Dịch vụ ngày nay | |---|---| | Dashboard tổng thể cho CI/CD | CodeCatalyst (thay thế trực tiếp của CodeStar) | | Kết nối tới GitHub/GitLab/Bitbucket | CodeConnections (trước là CodeStar Connections) | | Thông báo pipeline | CodeStar Notifications (vẫn còn, đổi tên thành AWS CodeConnections notifications) |

Điều thú vị: hai dịch vụ CodeStar Connections và CodeStar Notifications vẫn tồn tại và được dùng rộng rãi, dù CodeStar gốc đã biến mất — nên tên "CodeStar" vẫn xuất hiện trong tài liệu, dễ gây nhầm.

Hãy nhớ bài toán (cần cái nhìn tổng thể, không cần chi tiết), và biết rằng câu trả lời ngày nay là CodeCatalyst.

Đáp án

B — Elastic IP.

Vì sao đúng

Bối cảnh rất đặc thù: đây là dịch vụ DNS, và tên DNS trỏ thẳng vào địa chỉ IP của instance. Nghĩa là IP chính là danh tính của dịch vụ — client (và các resolver khác) đã ghi nhớ nó.

Elastic IP là địa chỉ IPv4 tĩnh mà bạn sở hữu và di chuyển được giữa các instance:

# 1. Dựng instance mới với phiên bản dịch vụ đã nâng cấp
# 2. Chuyển Elastic IP sang instance mới
aws ec2 associate-address --instance-id i-may-moi --allocation-id eipalloc-xxxx

Việc chuyển diễn ra trong vài giây, và địa chỉ IP không đổi — nên client vẫn kết nối tới đúng địa chỉ đó, không có gián đoạn đáng kể và không phụ thuộc vào TTL của DNS.

Đây là mẫu blue/green ở tầng thấp nhất: dựng máy mới, kiểm thử, rồi chuyển IP. Có sự cố thì chuyển ngược lại cũng trong vài giây.

Vì sao các phương án khác sai

• C. Dùng Route 53 — đây là bẫy hợp lý nhất, nhưng nó giải quyết sai bài toán. Route 53 quản lý bản ghi DNS, còn ở đây chính bạn đang vận hành một dịch vụ DNS, và client trỏ thẳng vào IP. Chuyển bằng cách đổi bản ghi DNS còn vướng TTL — trong nhiều phút vẫn có client đi vào máy cũ.
• A. Load Balancer + Auto Scaling group — ELB hoạt động tốt cho HTTP/HTTPS và TCP, nhưng dịch vụ DNS chủ yếu dùng UDP cổng 53. ALB không hỗ trợ UDP; NLB thì có, nhưng đây là thay đổi kiến trúc lớn cho một lần nâng cấp. Và ELB có tên DNS, không có IP tĩnh (trừ NLB).
• D. "Cấp một IP riêng tĩnh" — private IP chỉ dùng được trong VPC. Đây là dịch vụ công khai, nên nó phải có địa chỉ công khai.

Ghi nhớ

Đặc điểm của Elastic IP: | Đặc điểm | Chi tiết | |---|---| | Loại | IPv4 công khai, tĩnh | | Di chuyển giữa instance | ✅ trong vài giây | | Giới hạn mặc định | 5 EIP mỗi Region (nâng được) | | Chi phí | tính tiền khi KHÔNG gắn vào instance đang chạy |

Điểm cuối đáng lưu ý: từ 2024, AWS tính phí cho mọi IPv4 công khai, kể cả EIP đang được dùng. Nên đừng để EIP nhàn rỗi.

Bảng chọn theo tình huống: | Nhu cầu | Giải pháp | |---|---| | Giữ nguyên IP khi thay máy | Elastic IP | | Phân phối tải HTTP | ALB | | Cần IP tĩnh + cân bằng tải | NLB (có IP tĩnh mỗi AZ) | | Chuyển hướng theo tên miền | Route 53 |

Đáp án

A — Dùng chiến lược Write Through.

Vì sao đúng

Yêu cầu quyết định nằm ở giữa đề: "ensure that the latest data is served to the users (no stale data)" — tuyệt đối không được phục vụ dữ liệu cũ.

Write Through ghi vào cả cache lẫn CSDL ở mỗi lần ghi, nên cache luôn đồng bộ với backend:

def cap_nhat_bai_viet(bai_id, noi_dung):
    rds.update("UPDATE bai_viet SET noi_dung = %s WHERE id = %s", (noi_dung, bai_id))
    cache.set(f"bai:{bai_id}", noi_dung)     # cập nhật cache NGAY

So sánh với lazy loading:

Với ứng dụng blog trong đề, write through cũng hợp về mặt tải: bài viết được đọc rất nhiều, ghi rất ít, nên chi phí ghi thêm vào cache là không đáng kể, đổi lại mọi lần đọc đều trúng cache và luôn đúng.

Vì sao các phương án khác sai

• B. Lazy Loading không có TTL — tệ nhất cho yêu cầu này: entry nằm trong cache vô thời hạn với dữ liệu cũ, cho tới khi bị đẩy ra vì hết bộ nhớ. Người đọc có thể thấy bản cũ mãi mãi.
• D. Lazy Loading có TTL — TTL giới hạn mức độ cũ, nhưng vẫn có cửa sổ phục vụ dữ liệu lỗi thời cho tới khi entry hết hạn. Đề nói "no stale data", nên ngay cả vài phút cũng không đạt.
• C. Dùng DAX — DAX chỉ hoạt động với DynamoDB. Đề nói rõ đội đã chọn ElastiCache cho tải đọc, và không nhắc gì tới DynamoDB. Sai công cụ.

Ghi nhớ

Bốn chiến lược cache và đánh đổi: | Chiến lược | Nhất quán | Bộ nhớ cache | Hiệu năng ghi | |---|---|---|---| | Write Through | cao nhất | đầy cả dữ liệu không dùng | chậm hơn (ghi 2 nơi) | | Write-around + invalidate | cao | tiết kiệm | tốt | | Lazy Loading + TTL | trung bình | tiết kiệm | tốt | | Write Back | thấp | — | nhanh nhất, rủi ro mất dữ liệu |

Quy tắc chọn nhanh:

• "No stale data" là bắt buộc ⇒ Write Through
• Cache nhỏ hơn dataset ⇒ Lazy Loading
• Cả hai ⇒ Write Through kết hợp TTL để dọn dữ liệu nguội

(Xem thêm câu #5305 cùng chủ đề nhưng ràng buộc ngược lại — ở đó cache không chứa hết dataset nên lazy loading mới đúng.)