Serverless Architecture

এই লেসন শেষে তুমি পারবে

• ধাপে ধাপে একটা serverless mobile back end দাঁড় করাতে: API Gateway, Lambda আর DynamoDB দিয়ে HTTPS-এর ওপর REST API, Cognito user pool দিয়ে sign in, identity pool দিয়ে প্রত্যেক user-এর নিজের S3 folder, ঘন ঘন read-এর জন্য DAX, আর API Gateway caching।
• একটা global serverless website বানাতে: OAC সহ CloudFront দিয়ে S3 থেকে static file, একটা public REST API, DynamoDB global table, DynamoDB Streams, Lambda আর SES দিয়ে welcome email, আর S3 event দিয়ে thumbnail।
• Microservice-গুলোর মধ্যে synchronous আর asynchronous pattern, service discovery, আর microservice-এর সুবিধা-অসুবিধা বুঝিয়ে বলতে, আর serverless কোন সমস্যাগুলো মেটায় সেটা দেখাতে।
• Application একটুও না বদলে, সামনে CloudFront বসিয়ে EC2 Auto Scaling group-এর ঘাড় থেকে ভারী static download নামিয়ে দিতে।
• পুরো chapter জুড়ে সিদ্ধান্ত নিতে: Lambda নাকি Fargate নাকি EC2, DynamoDB নাকি RDS, API Gateway নাকি ALB, Step Functions নাকি SQS দিয়ে function জোড়া; আর Well-Architected serverless প্রশ্নগুলো দিয়ে একটা design যাচাই করতে।

#পুরো architecture কেন শিখব

Lesson 15.1 থেকে 15.7-এ আমরা একবারে একটা করে service শিখেছি। কিন্তু বাস্তব system, আর পরীক্ষার বেশিরভাগ প্রশ্ন, পাঁচ-ছয়টা service একসাথে জোড়ে। প্রশ্নে একটা চাহিদার তালিকা আসে (“বেশিরভাগ সময় read”, “user file upload করবে”, “সারা পৃথিবীর reader”, “welcome email পাঠাতে হবে”), আর প্রতিটা লাইনের জন্য ঠিক টুকরোটা তোমাকে বেছে নিতে হয়। এই লেসনে চারটা পরিচিত design দেখব, প্রতিটা একটা একটা চাহিদা ধরে গড়ে তুলব, তারপর একটা chooser আর একটা checklist দিয়ে chapter শেষ করব।

প্রতিটা চাহিদাকে একটা keyword হিসেবে পড়ো, যেটা একটা service-এর দিকে আঙুল তোলে:

#প্রথম ঘটনা: MyTodoList mobile app

ঢাকার একটা university-র ছাত্রছাত্রীদের জন্য একটা to-do app। চাহিদাগুলো আমাদের নিজের ভাষায়:

1. HTTPS-এর ওপর একটা REST API।
2. Serverless architecture: patch বা scale করার মতো কোনো instance থাকবে না।
3. User নিজের S3 folder-এ সরাসরি file পড়বে আর লিখবে।
4. User sign in করবে একটা managed, serverless authentication service দিয়ে।
5. User to-do লেখে, কিন্তু বেশিরভাগ সময় পড়ে।
6. Database-কে scale করতে হবে, আর অনেক বেশি read throughput দিতে হবে।

#REST layer

মূল কাঠামোটা serverless-এর সবচেয়ে চেনা চেহারা: client → API Gateway → Lambda → DynamoDB।

• API Gateway দেয় HTTPS endpoint, request যাচাই করে, throttle করে, আর অন্য কিছু চলার আগেই authentication যাচাই করে।
• Lambda-তে থাকে business logic। Request এলেই শুধু চলে, bill হয় request আর millisecond ধরে।
• DynamoDB-তে to-do থাকে userId-কে partition key করে, তাই “রিয়ার সব to-do” মানে একটা সস্তা Query, কখনো Scan না।

Sign in-এর জন্য app কথা বলে একটা Cognito user pool-এর সাথে। সে password যাচাই করে (MFA চালু থাকলে সেটাও), আর ফেরত দেয় JWT token: একটা ID token আর একটা access token, default মেয়াদ এক ঘণ্টা, সাথে একটা refresh token (default ৩০ দিন)। App token-টা Authorization header-এ পাঠায়। API Gateway method-এ বসানো একটা Cognito authorizer token-এর signature আর মেয়াদ যাচাই করে; মেয়াদ ফুরানো বা জাল token পায় 401, আর Lambda invoke-ও হয় না, bill-ও হয় না। Function user-এর ID নেয় যাচাই করা token থেকে (sub claim), request body থেকে কখনো না।

#প্রত্যেক user-কে তার নিজের S3 folder

৩ নম্বর চাহিদা বলছে user S3-এর সাথে কাজ করবে সরাসরি, Lambda হয়ে না। প্রতিটা ছবি Lambda দিয়ে পাঠালে compute-এর খরচ হতো, আর API Gateway (১০ MB) আর Lambda-র (synchronous invoke-এ ৬ MB) payload সীমায় আটকে যেত।

চিরাচরিত ভুল উত্তর হলো app-এর ভেতরে একটা IAM user-এর access key বসিয়ে দেওয়া। যে কেউ mobile app খুলে key বের করে নিতে পারে, আর সেই key দিয়ে চিরকালের জন্য সব user-এর folder খোলা যায়।

ঠিক উত্তর হলো একটা Cognito identity pool:

1. App তার user pool token-টা identity pool-কে দেয়।
2. Identity pool STS-কে call করে, আর তার authenticated IAM role-এর অস্থায়ী AWS credential (ঘণ্টাখানেক মেয়াদের) ফেরত দেয়।
3. সেই role-এর policy-তে থাকে একটা policy variable, যাতে প্রত্যেক user শুধু নিজের prefix-এ পৌঁছায়:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::todo-files-example/users/${cognito-identity.amazonaws.com:sub}/*"
}

Request-এর সময় IAM সেখানে caller-এর identity ID বসিয়ে দেয়। একটাই role সব user-এর জন্য, তবু আরেক ছাত্রের folder চাইলে উত্তর আসে 403 AccessDenied। অন্য service-এও একই কৌশল চলে: dynamodb:LeadingKeys condition key দিয়ে প্রত্যেক user শুধু সেই DynamoDB item-গুলোই query করতে পারে, যাদের partition key তার নিজের ID (lesson 15.7)।

#অনেক read throughput: DAX

User বেশিরভাগ সময় পড়ে, আর পরীক্ষার সপ্তাহে হাজার হাজার জন একই list বারবার খোলে। Lambda আর table-এর মাঝে বসাও DAX (DynamoDB Accelerator):

• এটা DynamoDB-র জন্য বানানো একটা in-memory, write-through cache, API-ও একই: code-এ শুধু client বদলায়।
• Cache hit ফেরত আসে microsecond-এ; spike-এর সময়ও table-এর read capacity প্রায় নড়ে না।
• Item cache-এর TTL default ৫ মিনিট।
• DAX দেয় eventually consistent read। Strongly consistent read সরাসরি table-এ চলে যায়।
• DAX cluster থাকে তোমার VPC-তে, তাই Lambda function-কেও সেই VPC-তে যুক্ত করতে হয় (lesson 15.3)।

#API Gateway-তে caching

যে response অনেক caller-এর জন্য একই, সেটা আরও এক ধাপ আগেই cache করো। একটা REST API stage response রেখে দিতে পারে একটা TTL পর্যন্ত (default ৩০০ সেকেন্ড, ০ থেকে ৩,৬০০)। Cache hit হলে Lambda আর DynamoDB পুরোপুরি বাদ। HTTP API-তে cache নেই; দরকার হলে REST API নাও, নয়তো সামনে CloudFront বসাও।

দুটো ফাঁদ:

• Cache key হলো resource path আর তুমি যে parameter বেছে দাও। User-ভিত্তিক response cache করার সময় key-তে Authorization header (বা user ID) না থাকলে, এক user আরেকজনের list পেয়ে যায়।
• Write করলে cache মোছে না। একটা POST-এর পরেও cache-এ থাকা GET TTL শেষ না হওয়া পর্যন্ত পুরনো থাকে। বদলাতে থাকা data-র জন্য ছোট TTL দাও, নয়তো client-কে Cache-Control: max-age=0 পাঠাতে দাও (তাদের execute-api:InvalidateCache অনুমতি লাগবে)।

#Mobile ঘটনা থেকে যা শিখলাম

• একটা serverless REST API: HTTPS, API Gateway, Lambda, DynamoDB।
• Authentication সামলায় Cognito; কোনো code চলার আগেই API Gateway সেটা যাচাই করে।
• Cognito identity pool app-এর user-দের অস্থায়ী, কড়াভাবে সীমিত credential দেয়, যাতে তারা সরাসরি AWS call করতে পারে (এখানে S3; DynamoDB বা Lambda-ও একইভাবে)।
• দুই স্তরের caching: database read-এর জন্য DAX, পুরো response-এর জন্য API Gateway caching।

#দ্বিতীয় ঘটনা: MyBlog.com website

ঢাকা, লন্ডন আর টরন্টো থেকে পড়া একটা বাংলাদেশি travel blog। চাহিদাগুলো:

1. Website-কে সারা পৃথিবীতে scale করতে হবে।
2. Post লেখা হয় কম, পড়া হয় বেশি।
3. Site-এর একটা অংশ শুধুই static file; বাকিটা একটা dynamic REST API।
4. যেখানে সম্ভব cache করতে হবে।
5. প্রত্যেক নতুন subscriber একটা welcome email পাবে।
6. Upload করা প্রতিটা ছবির একটা thumbnail তৈরি হবে।

#Static content, সারা পৃথিবীতে আর নিরাপদে

HTML, CSS, JavaScript আর ছবি থাকে একটা S3 bucket-এ, আর CloudFront সেগুলো দেয় প্রত্যেক reader-এর কাছের edge location থেকে। একটা edge-এর কাছের প্রথম reader-এর জন্য S3 থেকে একবার আনা হয়; তারপর সবাই পায় edge cache থেকে। “কম লেখা, বেশি পড়া”, ঠিক এই চেহারার কাজের জন্যই CDN বানানো।

Bucket private রাখতে Origin Access Control (OAC) ব্যবহার করো:

• CloudFront S3-এ পাঠানো request SigV4 দিয়ে sign করে।
• Bucket policy s3:GetObject দেয় শুধু cloudfront.amazonaws.com principal-কে, AWS:SourceArn condition এই distribution-এর সমান হলে।
• Block Public Access চালুই থাকে। সরাসরি S3 URL পায় 403, তাই কেউ CloudFront-এর geo restriction, WAF নিয়ম বা caching এড়িয়ে যেতে পারে না।

ফাঁদ: OAC কাজ করে bucket-এর REST endpoint-এর সাথে। CloudFront-কে S3 static website endpoint-এ পাঠালে সেটা custom origin, OAC আর চলে না, তখন bucket public করতেই হয় (lesson 10.3 আর 11.1)। OAC এসেছে পুরনো origin access identity (OAI)-এর জায়গায়।

#একটা public REST API

Comment আর like-এর সংখ্যা বদলায়, তাই এগুলো আসে API Gateway → Lambda → DynamoDB থেকে (read খুব বেশি হলে সাথে DAX)। Post যে কেউ পড়তে পারে, তাই এই API public: Cognito লাগে না। Public API-কে রক্ষা করো throttling, usage-এর সীমা আর AWS WAF দিয়ে (lesson 21.6)।

#DynamoDB global table

Reader তিন মহাদেশে। Table-টাকে global table বানাও: বেছে নেওয়া প্রতিটা Region-এ একটা replica, প্রতিটা replica read আর write দুটোই নেয়, আর পরিবর্তন asynchronously ছড়িয়ে যায়, সাধারণত এক সেকেন্ডের মধ্যে। প্রতিটা Region-এ API stack deploy করো, আর Route 53-এর latency routing আর health check দিয়ে reader-কে পাঠাও (lesson 8.3, 8.4)।

• Default-এ Region-গুলোর মধ্যে replica eventually consistent। একই মুহূর্তে দুই Region-এ একই item-এ দুটো write হলে মীমাংসা হয় last writer wins নিয়মে, তাই একটা edit চুপচাপ হারিয়ে যায়। এটা জরুরি হলে একটা item-এর সব write একটা home Region-এ পাঠাও।
• পাশের কথা: ২০২৫ থেকে global table-এ multi-Region strong consistency-ও আছে (তিনটা Region, বা দুটো replica আর একটা witness), data একটুও না হারানোর জন্য, বিনিময়ে write latency বেশি। তবে “global, কম latency-র read আর write” প্রশ্নে পরীক্ষার default উত্তর এখনো সাধারণ global table।
• Relational বিকল্প হলো Aurora Global Database: একটা writer Region, বাকি secondary Region-গুলো read-only, replication সাধারণত এক সেকেন্ডের কম, আর দুর্যোগে একটা secondary-কে promote করা যায় (lesson 7.3)।

#Welcome email-এর পথ

Sign-up function শুধু subscriber-এর row save করে সাথে সাথে উত্তর দেয়। Email পাঠায় আলাদা একটা পথ:

1. Users table-এ DynamoDB Streams চালু। প্রতিটা নতুন item একটা INSERT record হয়ে আসে, থাকে ২৪ ঘণ্টা, প্রতিটা item-এর ক্রম ঠিক রেখে।
2. একটা event source mapping stream poll করে, আর record-এর একটা batch দিয়ে Welcome function-কে invoke করে। Poll করে Lambda নিজেই; তুমি দাও শুধু invocation-এর দাম।
3. Function-এর execution role-এ ses:SendEmail অনুমতি আছে, তাই সে SDK দিয়ে Amazon SES-কে call করে। Email পাঠানোর serverless উপায় হলো SES: কোনো mail server চালাতে হয় না (lesson 25.2)।

Sign-up function-এর ভেতরেই email পাঠালে সমস্যা কী? Mail service ধীর হলে sign-up ধীর হতো, ব্যর্থ হলে sign-up-ও ব্যর্থ হতো। Stream থাকায় sign-up দ্রুত, আর email নিজে নিজেই retry হয়।

যে ব্যর্থতাটা জানা দরকার: stream-এর বেলায় Lambda default-এ ব্যর্থ batch-কে record-এর মেয়াদ ফুরানো পর্যন্ত retry করে, আর তার পেছনে shard আটকে থাকে। Retry-র সর্বোচ্চ সংখ্যা আর record-এর বয়স বেঁধে দাও, bisect batch on function error চালু করো, আর ব্যর্থগুলো পাঠাও একটা on-failure destination-এ (SQS, SNS বা S3)। নতুন AWS account-ও শুরু হয় SES sandbox-এ (প্রতিটা Region-এ আলাদা করে): production access চাওয়ার আগ পর্যন্ত শুধু verified address-এ mail যায়, ২৪ ঘণ্টায় সর্বোচ্চ ২০০টা, আর সেকেন্ডে সর্বোচ্চ ১টা।

#Thumbnail-এর পথ

লেখক ছবি upload করেন হয় CloudFront হয়ে bucket-এ (OAC upload-ও sign করে), নয়তো S3 Transfer Acceleration দিয়ে; দুই ক্ষেত্রেই byte-গুলো AWS network-এ ঢোকে কাছের একটা edge দিয়ে (lesson 10.6)।

একটা S3 event notification (s3:ObjectCreated:*) Thumbnail function-কে asynchronously invoke করে। Function ছবিটা পড়ে, ছোট একটা copy লেখে আলাদা একটা thumbnails bucket-এ, আর CloudFront দুটোই দেয়। ব্যর্থ async event দুবার আবার চেষ্টা হয়, তারপর যায় DLQ বা on-failure destination-এ।

S3 চাইলে event-গুলো SQS বা SNS-এও পাঠাতে পারে (diagram-এর ঐচ্ছিক ধাপ):

• S3 → SQS → Lambda হঠাৎ চাপ (ভ্রমণের পর ৫০০ ছবি) ধরে রাখে, visibility timeout দিয়ে প্রতিটা ব্যর্থ ছবি আবার চেষ্টা করে, আর বিষাক্ত message রেখে দেয় dead-letter queue-তে। S3 event-এর destination হতে হবে standard queue আর topic, FIFO না।
• S3 → SNS → কয়েকটা SQS queue একটা upload-কে অনেক consumer-এর কাছে ছড়িয়ে দেয় (thumbnail, virus scan, search index)।
• S3 → EventBridge দেয় content দেখে filter আর অনেক target (lesson 19.5)।

যে bucket (বা prefix) function-কে চালায়, output কখনো সেখানেই লিখো না: প্রতিটা thumbnail আরেকটা thumbnail চালাবে। S3, SQS, SNS আর EventBridge custom bus-এর বেলায় Lambda-র recursive loop detection প্রায় ১৬টা invocation-এর পর শিকলটা থামায়, তবু আলাদা bucket বা prefix filter ব্যবহার করো।

#এক ছবিতে পুরো website

• Static content: S3 + CloudFront, OAC দিয়ে bucket private।
• Dynamic content: একটা public serverless REST API (API Gateway, Lambda), Cognito নেই, কারণ পড়তে কাউকে sign in করতে হয় না।
• Global data: DynamoDB global table (relational data হলে Aurora Global Database)।
• Event: welcome email-এর জন্য DynamoDB Streams → Lambda (SES অনুমতিসহ role) → SES; thumbnail-এর জন্য S3 event → Lambda (সরাসরি, বা SQS কিংবা SNS হয়ে)।

#তৃতীয় ঘটনা: microservice

ঢাকার একটা online shop তার monolith ভেঙে microservice বানাতে চায়: অনেকগুলো service, যারা API দিয়ে একে অপরের সাথে কথা বলে, আর প্রত্যেকটা বানানো যার যেমন দরকার তেমন করে। উদ্দেশ্য, প্রতিটা team-এর হালকা development lifecycle: নিজের service নিজের সময়ে deploy, scale আর ঠিক করা।

একটা সাধারণ পরিবেশ দেখতে এমন, প্রতিটা service-এর Route 53-এ নিজের DNS নাম:

এই স্বাধীনতাই আসল কথা: দুটো service-কে একই compute বা একই database নিতে কেউ বাধ্য করে না।

#Synchronous আর asynchronous pattern

সোজা নিয়ম: synchronous call তখনই, যখন caller-এর এই মুহূর্তেই উত্তর লাগে (checkout-এর সময় একটা item-এর দাম)। বাকি সব (shipping, invoice, loyalty point, email) হোক event। Synchronous call এড়ানো না গেলে ছোট timeout, backoff সহ retry, circuit breaker আর cache করা বিকল্প উত্তর দিয়ে সেটাকে রক্ষা করো।

#একে অপরকে খুঁজে পাওয়া: service discovery

Service-গুলোকে hard-code করা IP address ছাড়াই একে অপরকে খুঁজে পেতে হয়, কারণ container আর function আসে-যায়:

• প্রতিটা service-এর সামনের দরজার জন্য Route 53 নাম (ALB বা API Gateway custom domain-এ alias record), ওপরের table-এর মতো।
• AWS Cloud Map: service instance-গুলোর একটা registry, DNS বা API দিয়ে জিজ্ঞেস করা যায়; ECS task-গুলো নিজে থেকেই এতে নাম লেখায়।
• ECS Service Connect: ECS namespace-এর ভেতরে http://catalog-এর মতো একটা নাম, সাথে একটা managed proxy যে retry আর metric যোগ করে (lesson 14.2)।
• পাশের কথা: Amazon VPC Lattice built-in auth সহ VPC আর account পেরিয়ে service জোড়ে; পরীক্ষায় কমই আসে।

#Microservice-এর দাম, আর serverless যা মেটায়

Microservice বিনা খরচে আসে না। সাধারণ সমস্যাগুলো:

• প্রতিটা নতুন service-এর জন্য একই খাটুনি বারবার: একটা pipeline, monitoring, একটা load balancer, একটা cluster, security setup।
• Server ভালোভাবে ভরে না: অনেক ছোট service, প্রত্যেকের নিজের অর্ধেক-অলস instance।
• একসাথে অনেক service-এর অনেক version চলে, তাতে test আর rollback জটিল হয়।
• Client-এর code বাড়ে: প্রতিটা client-কে অনেক আলাদা endpoint-এর সাথে জুড়তে হয়।

Serverless pattern এই কষ্টের একটা অংশ দূর করে:

• API Gateway আর Lambda নিজে থেকেই scale করে, আর দাম দাও যতটুকু ব্যবহার ততটুকু, তাই অলস অবস্থায় ছোট একটা service-এর খরচ প্রায় শূন্য, server density নিয়ে কাউকে মাথা ঘামাতে হয় না।
• একটা template থেকে API clone করা যায়, পুরো environment আবার বানানো যায় (AWS Serverless Application Model, CloudFormation, CDK)।
• API-র OpenAPI (Swagger) definition থেকে API Gateway client SDK বানিয়ে দিতে পারে, তাই client-কে হাতে integration code লিখতে হয় না।

#চতুর্থ ঘটনা: software update-এর বোঝা নামানো

বাংলাদেশের একটা accounting software কোম্পানি update file দেয় তিনটা AZ জুড়ে একটা Auto Scaling group-এর EC2 instance থেকে, একটা load balancer-এর পেছনে, file-গুলো পড়ে EFS থেকে। বছরের বেশিরভাগ সময় সব শান্ত। Release-এর দিন হাজার হাজার installation একসাথে একই ৩০০ MB file নামায়: ASG বাড়তে থাকে, EC2 থেকে network transfer আকাশ ছোঁয়, bill-ও তার পেছনে। শর্ত: application বদলানো যাবে না, কিন্তু খরচ আর CPU কমাতে হবে।

উত্তর: আগের load balancer-এর সামনে CloudFront বসাও:

• Architecture-এ কোনো পরিবর্তন নেই: ALB হয়ে যায় CloudFront-এর origin, আর download hostname distribution-এর দিকে দেখায়।
• Update file static: একবার একটা version publish হলে আর কখনো বদলায় না, edge-এ cache করার জন্য একদম আদর্শ।
• EC2 instance serverless না, কিন্তু CloudFront serverless, আর আমাদের হয়ে সে-ই scale করে। প্রতিটা file origin থেকে আসে মোটামুটি প্রতি edge-এ একবার (বা regional edge cache প্রতি একবার), প্রতি customer-এ একবার না।
• ASG প্রায় বাড়েই না, তাই EC2-ঘণ্টা, EFS throughput আর origin bandwidth-এ সাশ্রয়, আর spike edge-এ শুষে যাওয়ায় availability-ও বাড়ে।

যে দুটো বিশেষ ক্ষেত্রের জন্য design করবে:

• নাম একই, ভেতরটা নতুন: latest.zip বদলে দিলে edge-গুলো TTL পর্যন্ত (default ২৪ ঘণ্টা) পুরনো file-ই রাখে। File-এর নামে version রাখো (update-7.2.1.zip), তাহলে প্রতিটা release একটা নতুন cache key; জরুরি অবস্থায় একটা invalidation বানাও (মাসে প্রথম ১,০০০টা path বিনা খরচে)।
• CloudFront এড়িয়ে যাওয়া: ALB-র security group-এ শুধু CloudFront-এর managed prefix list allow করো, নয়তো CloudFront VPC origin ব্যবহার করো, যাতে ALB internal থাকতে পারে (lesson 11.2)।

Global Accelerator কেন না? সে তোমার instance পর্যন্ত network পথটা দ্রুত করে, কিন্তু cache করে না: প্রতিটা byte তখনো EC2 থেকেই আসত। File-গুলো S3-এ সরালে কেন না? সেটা কাজ করত, আরও সস্তাও হতো, কিন্তু তাতে application বদলায়, যেটা প্রশ্নে নিষেধ।

#পুরো chapter জুড়ে বেছে নেওয়া

ওপরের প্রতিটা ঘটনায় ঘুরেফিরে একই কয়েকটা সিদ্ধান্ত নিতে হয়েছে। এখানে সেগুলো পাশাপাশি।

#Compute: Lambda, Fargate নাকি EC2

#Data: DynamoDB নাকি RDS / Aurora

সব ধরনের database পাশাপাশি তুলনা আছে chapter 16-এ (16.1)।

#সামনের দরজা: API Gateway নাকি ALB

#Workflow: Step Functions নাকি function-এর মাঝে SQS

#একটা Well-Architected serverless checklist

Well-Architected Framework-এর জন্য AWS একটা Serverless Applications Lens প্রকাশ করে (chapter 26, lesson 26.1)। ছোট করে, প্রতিটা pillar ধরে:

#কোথায় ভুল হয়

#System design-এ serverless architecture

• চাহিদার তালিকা থেকে শুরু করো, আর ওপরের table-এর মতো প্রতিটা লাইনকে একটা টুকরোর সাথে মেলাও। পরীক্ষার বেশিরভাগ উত্তর ঠিক এই মেলানোটাই।
• Request-এর পথ থেকে কাজ সরাও: user-কে দ্রুত উত্তর দাও, ধীর অংশগুলো করুক stream, S3 event আর queue।
• যে স্তরে পারো cache করো: static আর cache-যোগ্য response-এর জন্য CloudFront, বারবার আসা API উত্তরের জন্য API Gateway caching, ঘন ঘন পড়া DynamoDB item-এর জন্য DAX।
• নিরাপদ হলে user-কে সরাসরি AWS-এর সাথে কথা বলতে দাও (identity pool credential বা presigned URL দিয়ে S3 upload), Lambda দিয়ে byte না ঠেলে।
• গতানুগতিক কাজে managed service নাও: sign in-এর জন্য Cognito, email-এর জন্য SES, workflow-এর জন্য Step Functions।
• কখন serverless আর লাভজনক না, সেটা জানো: একটানা অনেক traffic, ১৫ মিনিটের বেশি কাজ, GPU, বা ভারী relational report হলে container, EC2 আর RDS-এর দিকে তাকাও।

#নিজে করে দেখো

MyBlog.com design-এর কয়েকটা টুকরো, ap-southeast-1-এ, account 111122223333। Output ছোট করে দেখানো।

# 1. Template থেকে একটা serverless API (API Gateway + Lambda + DynamoDB) বানিয়ে deploy করো
sam init --name blog-api-example --runtime python3.13 --app-template hello-world
sam build && sam deploy --guided
#   Outputs: ApiUrl = https://a1b2c3d4e5.execute-api.ap-southeast-1.amazonaws.com/Prod/

# 2. Users table-এ DynamoDB Streams চালু করো (welcome email-এর জন্য new image-ই যথেষ্ট)
aws dynamodb update-table --table-name blog-users-example \
  --stream-specification StreamEnabled=true,StreamViewType=NEW_IMAGE
#   "LatestStreamArn": "arn:aws:dynamodb:ap-southeast-1:111122223333:table/blog-users-example/stream/2026-10-28T09:12:44.123"

# 3. Stream-কে Welcome function-এর সাথে জোড়ো, ব্যর্থতা সামলানোর নিরাপদ setting সহ
aws lambda create-event-source-mapping --function-name welcome-email-example \
  --event-source-arn arn:aws:dynamodb:ap-southeast-1:111122223333:table/blog-users-example/stream/2026-10-28T09:12:44.123 \
  --starting-position LATEST --batch-size 10 \
  --maximum-retry-attempts 3 --maximum-record-age-in-seconds 3600 --bisect-batch-on-function-error \
  --destination-config '{"OnFailure":{"Destination":"arn:aws:sqs:ap-southeast-1:111122223333:welcome-failed-example"}}'
#   "State": "Creating", "MaximumRetryAttempts": 3, "BisectBatchOnFunctionError": true

# 4. SES দিয়ে একটা test email পাঠাও (sandbox-এ দুটো address-ই verified হতে হবে)
aws sesv2 send-email --from-email-address hello@blog.example \
  --destination ToAddresses=nusrat@reader.example \
  --content 'Simple={Subject={Data=Welcome},Body={Text={Data=Thanks for subscribing}}}'
#   "MessageId": "0100018f-example-0000"

# 5. Thumbnail চালাও শুধু uploads/-এর জন্য, যাতে thumbs/-এর output কখনো ফিরে loop না বানায়
aws s3api put-bucket-notification-configuration --bucket blog-photos-example \
  --notification-configuration '{"LambdaFunctionConfigurations":[{
     "LambdaFunctionArn":"arn:aws:lambda:ap-southeast-1:111122223333:function:thumbnail-example",
     "Events":["s3:ObjectCreated:*"],
     "Filter":{"Key":{"FilterRules":[{"Name":"prefix","Value":"uploads/"}]}}}]}'

# 6. ফ্রাঙ্কফুর্টে একটা replica যোগ করে table-কে global table বানাও
aws dynamodb update-table --table-name blog-comments-example \
  --replica-updates '[{"Create":{"RegionName":"eu-central-1"}}]'
#   "Replicas": [{"RegionName": "eu-central-1", "ReplicaStatus": "CREATING"}]

# 7. একজন mobile user identity pool থেকে অস্থায়ী credential নেয়
aws cognito-identity get-id --identity-pool-id ap-southeast-1:11111111-2222-3333-4444-555555555555 \
  --logins cognito-idp.ap-southeast-1.amazonaws.com/ap-southeast-1_Example=eyJraWQiOi...
#   "IdentityId": "ap-southeast-1:9f8e7d6c-1234-5678-9abc-def012345678"
aws cognito-identity get-credentials-for-identity \
  --identity-id ap-southeast-1:9f8e7d6c-1234-5678-9abc-def012345678 \
  --logins cognito-idp.ap-southeast-1.amazonaws.com/ap-southeast-1_Example=eyJraWQiOi...
#   "Credentials": { "AccessKeyId": "ASIAEXAMPLE", "Expiration": "2026-10-28T10:15:00+06:00", ... }

# 8. Software update: আবার ব্যবহার করা একটা file নাম সব edge থেকে invalidate করো
aws cloudfront create-invalidation --distribution-id E2EXAMPLE1234 --paths "/latest.zip"
#   "Status": "InProgress"

#সারসংক্ষেপ

মূল কথাগুলো

• Mobile back end (MyTodoList): API Gateway → Lambda → DynamoDB দিয়ে HTTPS REST; Cognito user pool user-কে sign in করায় আর Lambda চলার আগেই API Gateway JWT যাচাই করে; Cognito identity pool অস্থায়ী credential দেয়, যা ${cognito-identity.amazonaws.com:sub} দিয়ে প্রত্যেক user-এর নিজের S3 folder-এ সীমিত, app-এ key কখনো না; অনেক read throughput-এর জন্য DAX; বারবার আসা response-এর জন্য API Gateway caching (REST API, default ৩০০ সেকেন্ড), cache key-তে user রেখে।
• Global website (MyBlog.com): static file একটা private S3 bucket-এ, সামনে OAC সহ CloudFront (bucket policy একটা distribution-এর জন্য, শুধু REST endpoint); public REST API-তে Cognito লাগে না; global data-র জন্য DynamoDB global table (বা Aurora Global Database), conflict হলে last writer wins।
• Event: welcome email-এর জন্য DynamoDB Streams → Lambda → SES (function-এর IAM role SES-এর অনুমতি দেয়); thumbnail-এর জন্য S3 event → Lambda, বা SQS / SNS হয়ে। আলাদা output bucket; stream retry-র সীমা; DLQ।
• Microservice: প্রতিটা service-এর নিজের চেহারা আর নিজের DNS নাম; synchronous (API Gateway, load balancer) availability-কে জুড়ে দেয়, asynchronous (SQS, SNS, Kinesis, Lambda trigger) ব্যর্থতা শুষে নেয়; Route 53, Cloud Map, Service Connect দিয়ে service discovery। Serverless খাটুনি কমায়: নিজে থেকে scale, ব্যবহার অনুযায়ী দাম, clone করা environment, বানিয়ে দেওয়া client SDK।
• Software update-এর বোঝা নামানো: আগের ALB-র সামনে CloudFront বসাও: application বদলায় না, static file edge-এ cache হয়, ASG প্রায় বাড়ে না, বিশাল সাশ্রয়। Global Accelerator না (cache নেই)।
• বেছে নেওয়া: ছোট event-driven কাজে Lambda, সারাক্ষণ চলা container-এ Fargate, GPU আর একটানা চাপে EC2; জানা key access-এ বিশাল scale হলে DynamoDB, join থাকলে RDS/Aurora; API feature আর হঠাৎ traffic-এ API Gateway, একটানা traffic আর লম্বা request-এ ALB; orchestration-এ Step Functions, একটা ধাপ buffer করতে SQS।

নিজেকে যাচাই করো: serverless architecture৩৩টি প্রশ্ন