Guys where are the likes? please , like the video, I came from linux Academy looking to expand my knowledge base for the, I found this channel and I do like it most!! this is a really good content.
See my dear if you are showing your customers running 1000s or lakhs to view their daily account statement and running the code with lambda that 10,000 or more customers view in a day then will this solution become cheaper when 10,000 times or execution happen on daily basis. Will it be cost effective that the Ec2 which you will provision for capacity of 15000 viewing per day which also give to the limit 25000 viewing with a fixed cost. I dont think when billed as per the number execution it really becomes cost effective .
Polling is the wait time .. Let suppose I tell you put a timer of 20 secs in your code and post completion of 20 second only then you will make the next call to get the status. That's called a polling interval of 20 secs. In SQS within the polling interval of these 20 secs it will not make an attempt to check for new message. U need to understand that polling is different than visibility timeout.
You can definitely send payloads directly to Amazon SNS without using AWS Lambda or Amazon SQS. The choice to use services like Lambda or SQS before SNS often depends on the specific requirements of your architecture and the nature of the data processing involved. Here are some reasons why you might use AWS Lambda or Amazon SQS before sending a message to SNS: 1. **Data Processing with Lambda:** - **Complex Transformations:** If the payload needs to be processed or transformed before sending the notification, using Lambda is a common approach. For example, you might need to extract specific information from a larger dataset or format the message in a particular way. - **Conditional Logic:** Lambda allows you to implement complex logic to determine whether a notification should be sent. For instance, you might only want to trigger an SNS notification under certain conditions after inspecting the incoming data. - **Integration Logic:** Sometimes, the decision to send a notification via SNS depends on the results of integrating with other services. Lambda can handle these integrations (e.g., querying a database or calling an external API) before deciding to send a message to SNS. 2. **Decoupling with SQS:** - **Rate Limiting and Throttling:** If your system produces notifications at a high rate, you might use SQS to buffer these messages. This helps in managing throughput to SNS, especially if there are many subscribers or if the subscribers have rate limits. - **Reliability and Durability:** SQS provides a reliable queueing system that ensures that messages are not lost between your application and the notification service. If your system requires a high degree of reliability, using SQS as a buffer can help protect against data loss in case of transient errors. - **Retry Logic and Dead Letter Queues:** SQS can be used to manage retries in a more controlled manner. If a message fails to be processed or sent to SNS, it can be retried or moved to a Dead Letter Queue (DLQ) for further investigation. This helps in isolating problematic messages and ensures that your system remains resilient. 3. **Direct Use of SNS:** - **Simplicity:** If your application simply needs to send a notification with minimal processing, sending the payload directly to SNS is the simplest approach. This reduces the complexity and operational overhead of your architecture. - **Real-Time Notifications:** For scenarios where you need immediate notification without any delay, sending direct messages to SNS is preferable. This ensures that there is minimal latency between the event occurrence and the notification being sent out. 4. **Cost Considerations:** - Using Lambda or SQS introduces additional costs based on their usage (invocations for Lambda and the number of messages for SQS). Directly using SNS might be more cost-effective if the additional features provided by Lambda or SQS are not required for your use case. In summary, while sending payloads directly to SNS is a common and straightforward approach, using Lambda or SQS as intermediaries can provide additional flexibility, processing capabilities, and reliability features based on your specific needs.
🍀Timelines for your convenience:
00:00 // Introduction
01:30 // What was the need for AWS lambda serverless?
03:52 // AWS lambda - architecture design 1
05:00 // Difference between EC2 and Lambda
07:05 // Introduction to Lambda serverless
11:38 // AWS Lambda Trigger Points
14:56 // AWS lambda features
18:20 // AWS lambda pricing model
25:14 // AWS lambda - Design 1 discussion
27:08 // AWS lambda - Design 2 discussion
28:38 // Outro
Guys where are the likes? please , like the video, I came from linux Academy looking to expand my knowledge base for the, I found this channel and I do like it most!! this is a really good content.
easy understanding and for writing the notes we can copy your elaborated content.
Thanks for your broad explanation with animations.
Thanks arjun
Excellent content! Appreciate your visual presentation and explanation
Unbelievably on youtube Amazing !!! Thank you, Sir
This is really good content. Thanks. Could you please create some content on ECS service or provide a link if you have already done?
It's on the way mostly it's going be out by first week of Jan. Thanks 👍.
See my dear if you are showing your customers running 1000s or lakhs to view their daily account statement and running the code with lambda that 10,000 or more customers view in a day then will this solution become cheaper when 10,000 times or execution happen on daily basis. Will it be cost effective that the Ec2 which you will provision for capacity of 15000 viewing per day which also give to the limit 25000 viewing with a fixed cost. I dont think when billed as per the number execution it really becomes cost effective .
thanks bro, you are the best.
Amazing!! Thanks a lot
thank you so much it is so clear
Goods sir, next tuotorials plz
Already out in the playlist ✅
Can you explain what is meant by polling? I've seen it multiple times in SQS as well as Lambda but never understood what it meant :(
Polling is the wait time ..
Let suppose I tell you put a timer of 20 secs in your code and post completion of 20 second only then you will make the next call to get the status. That's called a polling interval of 20 secs.
In SQS within the polling interval of these 20 secs it will not make an attempt to check for new message.
U need to understand that polling is different than visibility timeout.
@@Pythoholic Thank you so much, I finally got it! Very well explained
Any specific reason we are using Lambda or SQS before SNS, can't we send payload directly to SNS??
You can definitely send payloads directly to Amazon SNS without using AWS Lambda or Amazon SQS. The choice to use services like Lambda or SQS before SNS often depends on the specific requirements of your architecture and the nature of the data processing involved.
Here are some reasons why you might use AWS Lambda or Amazon SQS before sending a message to SNS:
1. **Data Processing with Lambda:**
- **Complex Transformations:** If the payload needs to be processed or transformed before sending the notification, using Lambda is a common approach. For example, you might need to extract specific information from a larger dataset or format the message in a particular way.
- **Conditional Logic:** Lambda allows you to implement complex logic to determine whether a notification should be sent. For instance, you might only want to trigger an SNS notification under certain conditions after inspecting the incoming data.
- **Integration Logic:** Sometimes, the decision to send a notification via SNS depends on the results of integrating with other services. Lambda can handle these integrations (e.g., querying a database or calling an external API) before deciding to send a message to SNS.
2. **Decoupling with SQS:**
- **Rate Limiting and Throttling:** If your system produces notifications at a high rate, you might use SQS to buffer these messages. This helps in managing throughput to SNS, especially if there are many subscribers or if the subscribers have rate limits.
- **Reliability and Durability:** SQS provides a reliable queueing system that ensures that messages are not lost between your application and the notification service. If your system requires a high degree of reliability, using SQS as a buffer can help protect against data loss in case of transient errors.
- **Retry Logic and Dead Letter Queues:** SQS can be used to manage retries in a more controlled manner. If a message fails to be processed or sent to SNS, it can be retried or moved to a Dead Letter Queue (DLQ) for further investigation. This helps in isolating problematic messages and ensures that your system remains resilient.
3. **Direct Use of SNS:**
- **Simplicity:** If your application simply needs to send a notification with minimal processing, sending the payload directly to SNS is the simplest approach. This reduces the complexity and operational overhead of your architecture.
- **Real-Time Notifications:** For scenarios where you need immediate notification without any delay, sending direct messages to SNS is preferable. This ensures that there is minimal latency between the event occurrence and the notification being sent out.
4. **Cost Considerations:**
- Using Lambda or SQS introduces additional costs based on their usage (invocations for Lambda and the number of messages for SQS). Directly using SNS might be more cost-effective if the additional features provided by Lambda or SQS are not required for your use case.
In summary, while sending payloads directly to SNS is a common and straightforward approach, using Lambda or SQS as intermediaries can provide additional flexibility, processing capabilities, and reliability features based on your specific needs.
Can you please do demo as well
Coming up later in the day today
Thanks for the feedback
Thank you for putting efforts