Видео

Bro I have shifted to new place so trying to get my setup ready so will take a bit of time .thanks much

Congratulations arfat .. please do share it on linkedin and tag pythoholic it really helps the channel. Thanks again

I will check and get back

​@@Pythoholicany luck on 11 hidden videos

I will update it . Thanks for the feedback

Thanks for the feedback. Will try and improve

Thanks siddb09

As of recent updates, Application Load Balancers do support AWS PrivateLink. You can create an endpoint service in your VPC and specify an ALB as the service provider. This allows you to offer the applications behind your ALB privately to other VPCs through AWS PrivateLink. If there are any specific documentation you can refer i can help you better where they have mentioned dropping support.

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.

DynamoDB might start with 2 partitions instead of 1 for your requirements of 3000 RCUs and 1000 WCUs to better balance the load and improve performance consistency, even if one partition can technically handle the capacity. This approach also enhances fault tolerance and operational flexibility by distributing the workload across multiple partitions from the start.

@@Pythoholic I think, I have figured out why 2 partitions are needed and not 1. One partition can deliver either 3000 rcu or 1000 wcu or mix of both (i.e. if it has 500 wcu it can have 1500 rcu). It is not possible for a partition to deliver both 3000 rcu and 1000 wcu. By this logic, if one partition delivers all the required 3000 rcu, one more partiton is required to deliver 1000 wcu. Since they are distributed equally among partitons, each partition will deliver 1500 rcu and 500 wcu.

The thing which is missing from most documentation online, is its not 3000 rcu and 1000 wcu. Its 3000 rcu or 1000 wcu or a mix of both. By this logic, one partition won't be able to handle that load. You must need two. I got this information from an AWS Events video posted on YT about DynamoDB.