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

Đáp án

D — Thêm một cache behavior thứ hai vào cùng distribution, cùng origin, với path pattern là đường dẫn của trang đăng nhập và không giới hạn viewer access.

Vì sao đúng

Bối cảnh: distribution dùng OAI để đọc bucket S3, bucket từ chối mọi truy cập khác, và default cache behavior đang bật restricted viewer access (đòi signed URL/cookie).

Yêu cầu: cho người dùng chưa đăng nhập xem được trang login, trong khi nội dung riêng tư vẫn được bảo vệ.

Cache behavior là cơ chế đúng: một distribution có nhiều behavior, mỗi behavior khớp một path pattern và có cấu hình bảo mật riêng:

Distribution: d123.cloudfront.net
  ├─ Behavior "/login*"  → S3 origin, KHÔNG cần signed URL     ← ưu tiên cao hơn
  └─ Default behavior "*" → S3 origin, YÊU CẦU signed URL      ← mọi thứ còn lại

Behavior được đánh giá theo thứ tự ưu tiên, và default behavior luôn ở cuối cùng. Nên đặt behavior cho /login* với priority cao hơn là trang đăng nhập được phục vụ công khai, còn tất cả nội dung khác vẫn phải có chữ ký.

Cả hai behavior dùng cùng origin — không cần bucket thứ hai, không cần distribution thứ hai.

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

• A. Behavior thứ hai với path pattern là * — sai: * khớp mọi thứ, nên nó sẽ vô hiệu hoá luôn phần bảo vệ nội dung riêng tư. Path pattern phải hẹp, chỉ khớp trang đăng nhập.
• C. Tạo một distribution mới — làm được nhưng thừa và phiền: phải quản hai distribution, hai tên miền (hoặc hai chứng chỉ), hai bộ cấu hình cache. Một behavior thêm vào là đủ.
• B. Dùng failover origin — hiểu sai chức năng. Origin group là cơ chế dự phòng khi origin chính lỗi (trả về 5xx), không phải cơ chế định tuyến theo đường dẫn hay theo quyền truy cập.

Ghi nhớ

Cấu trúc của một CloudFront distribution:

Distribution
├── Origins (một hoặc nhiều: S3, ALB, HTTP endpoint)
└── Cache behaviors (đánh giá theo PRIORITY)
    ├── Behavior 1: path pattern hẹp nhất
    ├── Behavior 2: ...
    └── Default (*): luôn CUỐI CÙNG

Mỗi behavior cấu hình riêng được: origin, restrict viewer access (signed URL/cookie), cache policy, allowed HTTP methods, viewer protocol policy, Lambda@Edge / CloudFront Functions.

Ghi chú thời sự: OAI đã lỗi thời — AWS khuyến nghị dùng Origin Access Control (OAC), hỗ trợ SSE-KMS, mọi Region, và cả PUT/DELETE.

Đáp án

B — Mở rộng theo chiều ngang cho tầng web và tầng ứng dụng bằng Auto Scaling group + Application Load Balancer.

Vì sao đúng

Đề nêu ba manh mối: chậm khi có traffic spike, nút thắt ở tầng ứng dụng, và cần giải pháp lâu dài.

Horizontal scaling là câu trả lời đúng cho cả ba:

Với ALB phía trước và Auto Scaling group phía sau, hệ thống tự thêm máy khi traffic tăng và tự bớt khi giảm — đúng nghĩa "long term solution" cho vấn đề spike.

Đề cũng nói nút thắt ở tầng ứng dụng, và phương án này nhắm đúng vào đó (cùng với tầng web).

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

• C. Vertical scaling — dùng instance lớn hơn — đây là giải pháp ngắn hạn: nó có trần cứng (không có instance nào lớn vô hạn), việc thay đổi cần khởi động lại, và bạn trả tiền cho cấu hình đỉnh 24/7 dù spike chỉ vài giờ mỗi tuần. Trái yêu cầu "long term".
• A. SQS + Lambda bất đồng bộ để tách tầng ứng dụng và dữ liệu — đây là một cải tiến kiến trúc tốt trong nhiều trường hợp, nhưng đề nói rõ ứng dụng dùng giao dịch đồng bộ (synchronous transactions). Chuyển sang bất đồng bộ là thay đổi mô hình nghiệp vụ, không phải tối ưu hiệu năng — người dùng đang chờ kết quả ngay.
• D. Oracle RAC trên AWS cho tầng dữ liệu — nhắm sai tầng: đề nói nút thắt ở tầng ứng dụng, không phải CSDL. Oracle RAC cũng cực kỳ phức tạp và tốn kém, và không phải kiến trúc được khuyến nghị trên AWS.

Ghi nhớ

Bộ ba mở rộng chuẩn cho ứng dụng web trên AWS:

Route 53 → CloudFront → ALB → Auto Scaling group (nhiều AZ) → RDS Multi-AZ + read replica

Nguyên tắc: luôn ưu tiên horizontal scaling; vertical scaling chỉ là biện pháp tạm thời hoặc cho những tầng không mở rộng ngang được (thường là CSDL ghi).

Đáp án

C — Bật DAX cho DynamoDB và CloudFront cho S3.

Vì sao đúng

Manh mối quyết định: 80% request đọc là giống nhau giữa mọi người dùng — tức là tải rất cache được. Và có hai loại dữ liệu ở hai dịch vụ, nên cần hai giải pháp cache khác nhau.

DAX cho DynamoDB — vì tiêu chí là "least development effort":

Với DAX, tích hợp chỉ là đổi client:

import amazondax
db = amazondax.AmazonDaxClient.resource(endpoint_url='dax://cum...')

Không phải viết một dòng logic cache nào — đó là khác biệt lớn nhất so với ElastiCache.

CloudFront cho S3 — nội dung tĩnh được cache tại hơn 600 edge location, nên vừa nhanh hơn cho người dùng ở xa vừa giảm chi phí: request trúng cache không tính vào request của S3, và phí truyền dữ liệu từ CloudFront rẻ hơn.

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

• B. ElastiCache Redis cho DynamoDB + CloudFront cho S3 — vế S3 đúng, nhưng vế DynamoDB đòi tự viết toàn bộ logic cache-aside: đọc cache trước, trượt thì đọc DynamoDB rồi ghi lại, và xử lý vô hiệu hoá khi dữ liệu đổi. Nhiều công sức hơn hẳn DAX.
• A và D. ElastiCache Memcached cho S3 — sai công cụ cho nội dung tĩnh. Memcached là cache trong bộ nhớ cho ứng dụng, nằm trong VPC ở một Region; nó không phục vụ nội dung web cho người dùng cuối và không có mặt ở edge location. CloudFront mới là CDN.

Ghi nhớ

Chọn cache theo nguồn dữ liệu: | Nguồn | Cache đúng | |---|---| | DynamoDB | DAX (tương thích API, ít sửa mã nhất) | | S3 / nội dung tĩnh | CloudFront | | RDS / CSDL quan hệ | ElastiCache | | API động toàn cầu | CloudFront (cache ngắn) |

Ba lưu ý về DAX: nó chỉ hoạt động trong VPC, ghi phải đi qua DAX thì cache mới tự cập nhật, và nó eventually consistent — cần đọc nhất quán mạnh thì phải gọi thẳng DynamoDB.

Đáp án

B — Cấu hình provisioned concurrency cho hàm Lambda.

Vì sao đúng

Yêu cầu rất cụ thể: tối ưu thời gian khởi động (startup time) của hàm — tức là cold start.

Provisioned concurrency là cơ chế duy nhất của Lambda loại bỏ cold start: AWS khởi tạo sẵn số môi trường thực thi bạn yêu cầu, chạy xong phần init (nạp runtime, mã ngoài handler, mở kết nối), rồi giữ chúng ở trạng thái ấm.

aws lambda put-provisioned-concurrency-config \
  --function-name phan-hoi-khach-hang \
  --qualifier prod \
  --provisioned-concurrent-executions 50

Kết quả: request tới được phục vụ ngay lập tức, không phải chờ khởi tạo môi trường.

Kết hợp với Application Auto Scaling để lượng dự phòng lên xuống theo lịch hoặc theo tải, tránh trả tiền giữ sẵn 24/7.

Lưu ý bắt buộc: provisioned concurrency chỉ áp cho một version hoặc alias cụ thể, không áp cho $LATEST.

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

• A. Reserved concurrency — đây là bẫy trung tâm của câu hỏi. Reserved concurrency chỉ ĐẶT TRẦN số lần chạy đồng thời; nó không giữ môi trường nào ấm và không giúp gì cho cold start. Đặt nó xong cold start vẫn nguyên vẹn, mà giờ còn thêm nguy cơ bị throttle.

  	Reserved	Provisioned
  Tác dụng	đặt trần	khởi tạo sẵn
  Với cold start	không giúp	loại bỏ
  Chi phí	miễn phí	trả tiền giữ sẵn

• D. Bật API caching ở API Gateway — cache phản hồi, nên request trúng cache không gọi Lambda chút nào. Nhưng nó không tối ưu thời gian khởi động của hàm — request trượt cache vẫn gặp cold start y nguyên. Và với dữ liệu phản hồi ý kiến khách hàng, cache thường không phù hợp.

• C. Interface VPC endpoint qua PrivateLink — giảm độ trễ mạng khi gọi API Gateway từ trong VPC. Nó không liên quan gì tới thời gian khởi tạo môi trường Lambda.

Ghi nhớ

Cách chữa theo triệu chứng: | Vấn đề | Giải pháp | |---|---| | Cold start | provisioned concurrency | | Hàm chạy chậm (CPU-bound) | tăng bộ nhớ | | Bị throttle | tăng reserved concurrency hoặc hạn mức tài khoản | | Bảo vệ downstream khỏi quá tải | reserved concurrency |

Vài cách giảm cold start mà không tốn tiền: giảm kích thước gói triển khai, khởi tạo SDK client ngoài handler, chọn runtime khởi động nhanh (Python, Node.js nhanh hơn Java, .NET), và với Java thì cân nhắc SnapStart.

Đáp án

B — S3ReadPolicy.

Vì sao đúng

SAM cung cấp một tập policy template dựng sẵn — các mẫu IAM policy được tham số hoá, giúp bạn cấp quyền cho Lambda mà không phải tự viết JSON:

Resources:
  HamDocTep:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: python3.12
      Policies:
        - S3ReadPolicy:
            BucketName: !Ref KhoDuLieu

SAM tự mở rộng thành policy đầy đủ:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:GetObjectAcl", "s3:GetLifecycleConfiguration",
             "s3:ListBucket", "s3:GetBucketLocation"],
  "Resource": ["arn:aws:s3:::<bucket>", "arn:aws:s3:::<bucket>/*"]
}

Đề nói rõ hàm "read files and extract key metadata" — chỉ đọc, nên S3ReadPolicy là đúng phạm vi, tuân thủ đặc quyền tối thiểu.

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

• D. S3CrudPolicy — bẫy sát nhất. Nó có tồn tại và cũng cấp quyền S3, nhưng phạm vi rộng hơn nhiều: Create, Read, Update, Delete — bao gồm cả s3:PutObject và s3:DeleteObject. Hàm chỉ cần đọc mà được quyền xoá là vi phạm đặc quyền tối thiểu, và là rủi ro thật: một lỗi trong mã có thể xoá dữ liệu.
• A. LambdaInvokePolicy — cho phép hàm gọi một hàm Lambda khác. Không liên quan tới S3.
• C. SQSPollerPolicy — cho phép hàm kéo message từ SQS queue. Cũng không liên quan.

Ghi nhớ

Các policy template hay dùng của SAM: | Template | Cấp quyền | |---|---| | S3ReadPolicy | đọc bucket | | S3CrudPolicy | đọc + ghi + xoá bucket | | DynamoDBReadPolicy | đọc bảng | | DynamoDBCrudPolicy | đọc + ghi bảng | | SQSPollerPolicy | kéo message | | SNSPublishMessagePolicy | publish lên topic | | KMSDecryptPolicy | giải mã bằng một khoá | | VPCAccessPolicy | tạo ENI để chạy trong VPC |

Quy tắc chọn: luôn ưu tiên bản Read nếu hàm chỉ đọc. Chọn Crud khi thực sự cần ghi — và khi ấy nên cân nhắc viết inline policy hẹp hơn nữa (chỉ PutObject, không DeleteObject).

Đáp án

A và E.

• A — Dùng tính năng data key caching của AWS Encryption SDK.
• E — Giảm tần suất request và dùng backoff + retry.

Vì sao đúng

Lỗi ThrottlingException từ KMS nghĩa là vượt request rate quota — mỗi Region có trần số lời gọi API mật mã mỗi giây (ví dụ 5.500–30.000 tuỳ Region và tuỳ loại thao tác).

Nguyên nhân trong đề: ứng dụng gửi giao dịch theo lô, và nếu mỗi giao dịch gọi KMS một lần thì số lời gọi tăng theo số giao dịch — rất dễ chạm trần.

A — data key caching. Đây là cách chữa nguyên nhân gốc: thay vì gọi GenerateDataKey cho mỗi lần mã hoá, tái sử dụng một data key cho nhiều thao tác trong một khoảng thời gian:

from aws_encryption_sdk import LocalCryptoMaterialsCache, CachingCryptoMaterialsManager
cache = LocalCryptoMaterialsCache(capacity=100)
cmm = CachingCryptoMaterialsManager(
    master_key_provider=kms_provider,
    cache=cache,
    max_age=300.0,           # dùng lại tối đa 5 phút
    max_messages_encrypted=100)   # hoặc tối đa 100 message

Với cấu hình này, 100 giao dịch chỉ tốn 1 lời gọi KMS thay vì 100 — giảm hai bậc.

E — giảm tần suất và backoff. Biện pháp tức thời và bắt buộc phải có: throttling mang tính tạm thời, nên chờ tăng dần rồi thử lại sẽ vượt qua được các đợt spike ngắn.

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

• B. Bucket-level key cho SSE-KMS — S3 Bucket Keys là tính năng thật và rất hiệu quả (giảm tới 99% lời gọi KMS), nhưng nó chỉ áp dụng khi S3 mã hoá object bằng SSE-KMS. Đề mô tả ứng dụng tự mã hoá dữ liệu trước khi gửi tới ứng dụng kế toán — không có S3 trong đường đi này. Sai bối cảnh.
• C. Viết truy vấn CloudWatch Logs Insights để theo dõi rồi xin nâng quota — theo dõi là việc tốt và xin nâng quota có thể cần thiết, nhưng đây không phải cách sửa lỗi: xin nâng mất thời gian xét duyệt, và dù quota bao nhiêu thì vẫn có trần. Không giải quyết việc gọi KMS quá nhiều một cách không cần thiết.
• D. Gửi CloudTrail event của KMS sang CloudWatch Logs — chỉ là thu thập dữ liệu để quan sát. Nó giúp chẩn đoán nhưng không giảm được một lời gọi nào.

Ghi nhớ

Ba cách giảm lời gọi KMS: | Cách | Bối cảnh | |---|---| | Data key caching (Encryption SDK) | ứng dụng tự mã hoá | | S3 Bucket Keys | S3 với SSE-KMS | | Envelope encryption | mã hoá dữ liệu lớn — một data key cho cả tệp |

Và nguyên tắc chung cho mọi ThrottlingException trên AWS: exponential backoff + jitter. Jitter (thêm độ ngẫu nhiên) rất quan trọng — không có nó, nhiều client bị throttle cùng lúc sẽ cùng thử lại sau đúng N giây, tạo ra một đợt dội mới.

Đánh đổi của data key caching: tái sử dụng khoá làm giảm mức độ cô lập mật mã. Đặt max_age và max_messages_encrypted đủ nhỏ để cân bằng giữa hiệu năng và bảo mật.

Đáp án

B — Dựng worker environment kèm tệp cron.yaml.

Vì sao đúng

Hai yêu cầu của đề — tác vụ lặp lại theo lịch và xử lý bất đồng bộ — đều là đặc trưng của worker environment.

Elastic Beanstalk có hai kiểu môi trường:

cron.yaml đặt ở gốc gói mã nguồn, khai các tác vụ định kỳ:

version: 1
cron:
  - name: "xu-ly-video"
    url: "/tasks/xu-ly-video"
    schedule: "0 */2 * * *"          # 2 giờ một lần
  - name: "don-tep-tam"
    url: "/tasks/don-dep"
    schedule: "0 3 * * *"            # 3 giờ sáng hằng ngày

Cách nó hoạt động: Beanstalk tự đẩy message vào SQS queue theo lịch, và daemon sqsd trên mỗi instance kéo message rồi POST tới đường dẫn đã khai ở localhost.

Điểm rất đáng giá: Beanstalk đảm bảo tác vụ chỉ chạy trên MỘT instance tại một thời điểm, kể cả khi môi trường có nhiều máy — bạn không phải tự dựng cơ chế bầu chọn leader.

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

• A. Web server environment + cron.yaml — cron.yaml chỉ có tác dụng trong worker environment. Đặt nó vào web server environment thì nó bị bỏ qua hoàn toàn, không có lỗi gì báo ra.
• D. Worker environment + .ebextensions — đúng kiểu môi trường nhưng sai tệp. .ebextensions dùng để cấu hình môi trường (cài gói, tạo tệp, chạy lệnh lúc deploy), không phải để khai lịch định kỳ.
• C. Web server environment + .ebextensions — sai cả hai vế.

Ghi nhớ

Hai tệp cấu hình đặc trưng của Beanstalk: | Tệp | Vị trí | Vai trò | |---|---|---| | cron.yaml | gốc, worker environment | lịch tác vụ định kỳ | | .ebextensions/*.config | gốc, mọi môi trường | cấu hình môi trường |

Mẫu kiến trúc chuẩn:

Web server environment  (nhận request, trả lời NGAY)
        ↓ SendMessage
     SQS queue  ←──── cron.yaml đẩy message theo lịch
        ↓ sqsd kéo
Worker environment      (xử lý nặng, không ai chờ)

Nguyên tắc lớn hơn: tách việc chậm ra khỏi đường đi của request — đây cũng là lý do tồn tại của SQS, Step Functions và mọi hàng đợi nền.

Đáp án

B và E.

• B — Triển khai X-Ray daemon dưới dạng sidecar container.
• E — Cấp IAM task role đúng cho container X-Ray.

Vì sao đúng

Kiến trúc X-Ray đòi một daemon làm trung gian: SDK gửi segment qua UDP cổng 2000 tới daemon cục bộ, daemon gom lô rồi gửi lên dịch vụ X-Ray qua HTTPS.

Với Fargate, bạn không có quyền truy cập host — không cài được gì lên máy bên dưới. Nên daemon phải chạy như một container trong cùng task:

"containerDefinitions": [
  {
    "name": "ung-dung",
    "image": "...ecr.../app:v1",
    "environment": [{"name": "AWS_XRAY_DAEMON_ADDRESS", "value": "127.0.0.1:2000"}]
  },
  {
    "name": "xray-daemon",
    "image": "public.ecr.aws/xray/aws-xray-daemon:latest",
    "cpu": 32, "memoryReservation": 256,
    "portMappings": [{"containerPort": 2000, "protocol": "udp"}]
  }
]

Vì các container trong cùng một task chia sẻ network namespace, ứng dụng gửi tới 127.0.0.1:2000 là tới được daemon.

E — task role. Fargate không có instance để gắn instance profile, nên quyền phải đến từ task role:

{"Effect": "Allow",
 "Action": ["xray:PutTraceSegments", "xray:PutTelemetryRecords"],
 "Resource": "*"}

Cách nhanh nhất là gắn managed policy AWSXRayDaemonWriteAccess vào task role.

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

• A. Triển khai daemon dưới dạng daemon set trên ECS — "daemon set" là khái niệm của Kubernetes, và ECS có daemon scheduling strategy tương ứng — nhưng nó chỉ hoạt động với EC2 launch type (chạy một task trên mỗi container instance). Fargate không có container instance, nên chiến lược này không áp dụng.
• C. Chạy daemon như một tiến trình trên EC2 instance — với Fargate không có EC2 instance nào để bạn chạm vào. Đây là cách đúng cho ECS trên EC2, không phải Fargate.
• D. Cấp IAM instance role cho EC2 instance — cùng lý do: Fargate không có instance, nên không có instance role. Phải là task role.

Ghi nhớ

Daemon X-Ray triển khai thế nào, theo nền tảng: | Nền tảng | Daemon | Quyền từ | |---|---|---| | Lambda | có sẵn | execution role | | ECS Fargate | sidecar container | task role | | ECS trên EC2 | sidecar hoặc daemon service | task role hoặc instance role | | EC2 | tự cài | instance profile | | On-premises | tự cài | thông tin xác thực riêng |

Và phân biệt hai role của ECS — bị nhầm rất thường xuyên: | Role | Ai dùng | |---|---| | Task execution role | ECS agent — kéo image từ ECR, ghi log | | Task role | mã trong container — gọi S3, DynamoDB, X-Ray… |

Đáp án

A — CloudWatch Events (EventBridge).

Vì sao đúng

Yêu cầu: gọi Lambda mỗi giờ, theo cách serverless.

EventBridge scheduled rule làm đúng việc đó, và không có hạ tầng nào để quản:

aws events put-rule --name chay-moi-gio --schedule-expression "rate(1 hour)"
aws events put-targets --rule chay-moi-gio \
  --targets "Id=1,Arn=arn:aws:lambda:ap-southeast-1:123456789012:function:xu-ly"
aws lambda add-permission --function-name xu-ly \
  --statement-id events-invoke --action lambda:InvokeFunction \
  --principal events.amazonaws.com --source-arn <arn-rule>

Hai cú pháp lịch: | Kiểu | Ví dụ | |---|---| | rate() | rate(1 hour), rate(5 minutes), rate(7 days) | | cron() | cron(0 * * * ? *) — mỗi giờ; cron(0 3 ? * MON-FRI *) — 3h sáng các ngày làm việc |

Lưu ý về cron của EventBridge: nó có sáu trường (phút, giờ, ngày-trong-tháng, tháng, ngày-trong-tuần, năm), và một trong hai trường ngày phải là ?. Giờ mặc định là UTC.

Bước cấp quyền là bắt buộc: EventBridge cần được phép gọi hàm, qua resource-based policy của Lambda. Console tự thêm; qua CLI hoặc CloudFormation thì phải khai.

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

• B. Amazon S3 — kích hoạt Lambda khi có object được tạo hoặc xoá. Đó là sự kiện, không phải lịch.
• C. Kinesis — kích hoạt khi có bản ghi mới trong stream. Cũng theo sự kiện.
• D. SQS — kích hoạt khi có message trong hàng đợi. (Có thể mô phỏng lịch bằng DelaySeconds, nhưng tối đa chỉ 15 phút và đó là cách chắp vá.)

Ghi nhớ

Hai lựa chọn lên lịch trên AWS: | | EventBridge Rules | EventBridge Scheduler | |---|---|---| | Lịch | rate(), cron() | thêm one-time, múi giờ, flexible time window | | Target | ~20 loại | hơn 270 API AWS | | Số lịch | giới hạn theo rule | hàng triệu | | Khuyến nghị | vẫn dùng tốt | cho thiết kế mới |

EventBridge Scheduler (ra mắt 2022) là lựa chọn tốt hơn cho hệ thống có nhiều lịch hoặc cần múi giờ địa phương — nó xử lý được cả giờ mùa hè, điều mà cron UTC không làm được.

Đáp án

D — Dùng chiến lược Lazy Loading kèm TTL.

Vì sao đúng

Đề nêu hai ràng buộc, và mỗi ràng buộc chọn một nửa của đáp án:

Ràng buộc 1 — "toàn bộ dữ liệu không nằm vừa cache" ⇒ Lazy Loading.

Với ứng dụng mạng xã hội, một số người dùng nổi tiếng được đọc rất nhiều, phần lớn còn lại gần như không ai xem. Lazy loading tự nhiên chỉ giữ nhóm nóng trong cache — đúng điều đề cần.

def lay_nguoi_dung(uid):
    du_lieu = cache.get(uid)
    if du_lieu is None:                       # trượt cache
        du_lieu = rds.query(uid)
        cache.setex(uid, 3600, du_lieu)       # ghi vào cache kèm TTL
    return du_lieu

Ràng buộc 2 — TTL để chống dữ liệu cũ. Nhược điểm cố hữu của lazy loading là cache có thể lỗi thời: dữ liệu đổi trong CSDL nhưng bản trong cache vẫn nguyên. TTL giới hạn mức độ cũ đó — sau N giây, entry tự hết hạn và lần đọc sau sẽ lấy bản mới.

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

• A. Lazy Loading không có TTL — đúng chiến lược nhưng thiếu lớp bảo vệ: entry nằm trong cache vô thời hạn cho tới khi bị đẩy ra vì hết bộ nhớ. Người dùng đổi ảnh đại diện có thể thấy ảnh cũ mãi mãi.
• B và C. Write Through — sai chiến lược cho ràng buộc thứ nhất: nó ghi mọi dữ liệu vào cache ở mỗi lần ghi, kể cả dữ liệu không ai đọc. Với dataset lớn hơn cache, phần lớn bộ nhớ cache bị chiếm bởi dữ liệu vô dụng — đúng điều đề muốn tránh ("cannot sit in ElastiCache without incurring tremendous costs").

Ghi nhớ

Ba chiến lược cache và đặc điểm: | Chiến lược | Ưu điểm | Nhược điểm | |---|---|---| | Lazy Loading | chỉ cache dữ liệu được dùng, node hỏng không nghiêm trọng | lần đọc đầu chậm, dữ liệu có thể cũ | | Write Through | dữ liệu luôn mới | cache đầy dữ liệu không dùng, ghi chậm hơn | | TTL | giới hạn độ cũ | vẫn có cửa sổ dữ liệu cũ |

Mẫu được dùng nhiều nhất trong thực tế: Lazy Loading + TTL — đơn giản, tiết kiệm bộ nhớ, và kiểm soát được mức độ lỗi thời. Cần dữ liệu luôn chính xác tuyệt đối thì thêm bước vô hiệu hoá cache tường minh khi ghi (write-through kết hợp invalidation).