Hello everyone, welcome. Today we are going to talk about tracking says with CDK and typescript. I hope you discovered and seeing after this session honeycomb CTO cart manager said observability isn't just about knowing what's happening in your system right now. It's about being able to ask any question of persistent at end time. But let's put it plainly, it's like having a crystal ball for your software where you can summon answers to your burning questions whenever curiosity strikes. Hey system, why did you decide to take a cough break during peak trap? What is with the hiccups every time we deploy a new code? So to achieve it, we are going to use CDK. So I'm going to give you a brief smell about the benefits of CDK. So what is CDK? CDK is a framework that allows developers to define cloud infrastructure, a YAAC basically like terraform, using familiar programming languages like typeScript, typescript, Python, Java and C sharp. Today we are going to use typescript. Okay, so basically what is the benefits when using AWS CDK you can abstract your cloudformation complexity. You can use reuse and share components. You can integrate everything with AWS ecosystem because yeah, it was built by AWS. Let's to the star of the night star of the night is SES. What is SES says is like your digital postman. Ensure your emails reach their destination safely and on time. In the chaotic Internet world, it's your superhero sidekick, managing your email, saving them from the dead, red spam folder and cyberspace fight, all while wearing a virtual cape and mask. I hope so. If you'll take a look here into this GiF, you can have an idea about the role of okay, so let's go to how SES works. Says works here in the first part. In the first one here, we have sender. Then sender send the email to the SES. In the first part here, client application sends emails. So picture this. Your client app feeling like a hotshot email sender send a request says to whisk away your message to its lucky recipients. In the second part here says play the email fairy. So says being the gracious host it is, accepts the email with open arms. It's like getting the golden chick to the email party. In the 30 part here, the great Internet, you would say. In fact, like the SES takes your email by hand and sends it flying through the Internet at a lightning speed, like a digital superhero delivering messages faster than a pizza on a Friday night. Fourth one here they email destiny revealed, in fact. So we have the receivers here. And in the first scenario, for instance, like three scenarios here, the first one is inbox nirvana. The recipient's ICP happily delivers your email straight to the inboxes like a smooth entry into email paradise. The second scenario, we can have the phantom email like oops. Turns out the recipient's email address is a ghost town. The ICP sends a bounce notification back to SES like here informing that it's a ghost and says notification back to says, which turn gently breaks the news to you. So bounce to the SES and then bounce again to the center. The 30 scenario it's the span saga. Your email arrives, but oh no, it says demon, the black sheep of the inbox and Mercad Aspen. The recipient hits the panic button and complains to the ICP. Says being the messenger of truth relays the complaint back to you like a carry pinion with some bad news. So it's a brief explaining about the flow of Mayo Sandy and you can take a look in more detail if you want in the documentation. But the big picture is basically this. So let's take a look on the SAS components. SES components we have two components basically here to explain this in a summarized way. So what is a verified identity? Well, it's like having your name on the guest list. It proves you are legit and not just in email pressure trying to sneak into the party. So whether it's your domain, subdomain or email address, getting verified is like getting the stamp of approval for the email gods. From the email gods you have also got these things called configuration lets. Think of them as your party playlist. There are ses of rules you can apply to your verified identities to make sure your emails hit all the right notes with the congregation set you can fine tune how emails behave and where they go. Want to track who is opening your mails? Done. Need to monitor boss ranks or complaints? Easy peasy. Configuration set let you call the shots and keep your email game on point. So next time you are sending out those email invites or blasting out your latest new latest newsletter, remember, verified identities and configuration sets are your backstage crew making sure your email rock the box. Okay, so let's go to our common problems when using lets. Basically we have two common problems to summarize here. The biggest problem in my perspective is the email deliverability issue because we are trying to ensuring that email reach recipients in box and avoid being mercury as span could be challenging. Maintaining a good sender reputation, adhering to email sending best practices and regularly monitoring email deliverability metrics are essential to mitigate this issue and the second one is monitoring SES metrics. We have a lack of monitoring and reporting because we don't have things made directly by the AWS. So when we are analyzing mayo delivery data, we think it's a kind of essential thing for identifying issues and optimizing email campaigns. Users should regularly review bounce rates, complaint rates and other metrics to improve email deliverability and engagement. Like you are trying to figure out how many people clicked on your campaign about the new sneakers that you released yesterday. This kind of thing. You can improve your product, for instance, and give you more arguments and more things to think when you are trying to create a new product or trying to prove your concept to the product managers and something like that. Why should I track it? Yeah, tracking salesmetrics is a crucial because it's like having a dashboard for your mayor campaigns. It lets you see how your email perform, who is opening and ignoring them and where they get lost in the digital winderns. With this data, you can fine tune your email strategies, improve engagement and ensure your messages hit the mark every time. It's like having a GPS for email journey, helping you navigate the twists and turns of the digital landscape with let's understand a little bit about sesmetrics. Says metrics play a crucial role in the email delivery because this provide us insights into the performance and healthy over Mayo campaigns. These metrics help email senders understand how recipients engage with their email and identify areas for improvement. And here's why says metrics are significant. I'm going to explain a little bit about each metric so delivery hate the first metric here is SES metrics that track the delivery rate, indicating the percentage of email successfully delivered to recipients in boxes. High delivery rates ensure that emails reach intended recipients and are not lost or market as a spam. The open rate metrics show the percentage of recipients hoping at the email. A higher open rate suggests that the email content is engaging and relevant to recipients. The click through rate CTR CTR metrics measure the percentage of recipients who clicked on links within the email. A higher CTR indicates that the email contains resolated with recipients and encouraged to then to take an action. Important thing when you tracking to track your audience. After that we have bounce rate. I explained a little bit before, but bounce rate metrics track the percentage of emails that were not delivered successfully due to various reasons such as value email addresses or full inboxes. High bounce rate may indicate issues with email list, IGN or deliverability. There are two types of bounce we have hard bounce. Basically it's the email brick wall. Imagine your email hitting a brick wall but with few words instead of bricks. Yeah, that's a hard bounce. It's like sending a letter to Hogwarts where you are a Morgo and it's just not going to happen. Soft bounce is the Mayo trampoline. Picture this, your mayo hits a trampoline side of brick wall. It's a soft bounce like when you throw a ball too hard and it bounces back. The mailbox might be full or the Internet might be having a melted off. Then we have complaint rate. Complaint rate metrics indicate the percentage of recipients who market they email as a spun or unwanted. A high complaint rate can negatively impact sender reputation, so you need to. After that we have the rendering ferry, the hindering ferry. It's like you have a template mail and you forgot to send a parameter to the template so it will give you a handling failure. Basically, overall sales metrics empower email senders to monitor the effectiveness of their email campaigns and identify areas of improvement and optimize strategies to enhance deliverability and engagement with recipients. Let me show an example of metrics here. Here we have some SES metrics like bounce, click, compliance, delivery. Here welbe core having great peaks of sending email that was sent successfully. We don't have a lot of opens here, so this can give us an idea that welbe core not having a good couch to action emails. So this kind of thing could help you and help your product managers to understand your audience. So let's hands on because yeah, this talk we're going to get our hands dirty. Here we have the code. Let me give some zoom here. I think it's better to read now. Here we have basically an echoic structure. I'm going to share with you GitHub this structure about CDK and how you can configure that. Here we have the class called email developability that extends the stack. Stack is a part of the construct. In there you can create stacks of many kind of resources and put everything together. To start here we need to create a class and the context is email availability to be easier to achieve the names and IDs for the resources. Here we have the register event, but before the register event we need to create our configuration set. So here we create our config set, passing the sending enabled that we are going to know the configuration set name. Basically it's the context name. We are setting the habitration metrics because we are trying to know how many emails was sent and this kind of thing. So it's our objective here, trying to understand the reputation metrics. So we need to set this as true. And it's a pretty easy way to configure this. Here we are configuring the event destination like SNS, because here we have SNS topic. In this SNS topic we receive all our heputation metrics, like the sendings, the rejects, the bounces. So if you want to plug in a lambda to process all the information in a different way like we have, this could be your upstream resources upstream event, and then you can give this to your downstream system to process it as you want. So you can plug in metrics, another kind of thing to log this, like for instance data dog or any kind of thing you want. If you want to send everything to the clogue watts logs, you can basically do it using this. And then we have here some clothes watt dimension. Clogged watt dimension is where you can create the dimensions to classify your metrics like I showed before. And you can open up the metrics and see everything there. So you need to create some cloud watch dimensions to metrify your sending rate, your bounce rate, for instance. So here we are going to add another event destination, and this event destination needs a cloud watch dimensions. So because of that we are creating these cloud water dimensions here and using these events, passing all events we are trying to track. So the enable needs to be true because yeah, we are trying to track it. After that we have the creation of alarms. So here I'm passing the top because you have for instance, top and it's like you want to receive some notifications when everything crashes. So because of that we need that topic. It's a different topic from the another topic because the first topic we are trying to give information for downstream systems. And here welbe care, trying to notify our workforce, our employees, like our DevOps guy, or, I don't know, some person that can act when an alarm will be triggered. So here we are creating alerts. So I'm passing the top and events to alarm with threshold. The threshold is basically when you want to alarm it. Like when I have a bounce rate, I want to alarm it, for instance. So it's basically metrid by thresholds. So here we are passing that. So it's a record string here. So then we pass a list, I'm going to pass a list and then create an alarm for each event, like here. So we are creating a new alarm, passing the metric, in fact, namespace of the metric, the metric name the type of statistic in fact we can use Sam, you can use average, minimum, maximum P 99 for instance. And we have the evaluation period here, the comparison operator if you want this should be greater than only or greater than or equal to the threshold that you are passing here. We want to enable that actions and here description and the creating missing data, the treating disclosing data is when for instance when you don't have any kind of data here, you don't want to alert your workforce. So yeah of that we need you to pass away how you can want to treat missing data here. Okay. And then you are going to add alarm action you can use like I told you for this example we are going to choose topic to notify our worker core. But here you can basically trigger a lambda for instance or you can use another of action here like we have a couple action fix here. You can pass the iron of the action here as is the console. We are going to register event because first of all we provide the create alerts function and the configuration set function and then we have the register event to register everything we are trying to achieve. For instance here we have our topic. I don't know if you remember yet but before I told you, you can use l one, l two and l three constructs. Here it's l three constructs. Basically here we are creating a specific topic to handle all the configuration lets configuration set event destinations and here we have this topic, this lack topic. I'm importing this laptop. So because of that I have this import valley. So let's picture this. You have an infrastructure project and there you create all your core resources like topic. And after that we are going to call our configuration lets that we created before passing the mail delivery top. And here welbe core creating our alarms, passing the slack top. It's your notification top and with the object of event, the event you want to tracking to create alerts and it will show that you want to be notified if this could be greater than and as I explained in the preach alarm. For instance like I'm passing here, if I have one reject I'm going to alarm my work. So basically is this here. It's a quite simple way to achieve it. But yeah we have a lack of configuration and a lack of observability because SAS doesn't provide us a deep observability into the system. Because of this I'm trying to explain this is a discovered it is an unsync. Whenever you are working with SES you can have a lot of trouble trying to figure out who received it and who clicked your emails. Yeah, and I will tell you about a case we had at OLB. We were trying to find out how many people had received and made about safety regulation and we didn't have that visibility and so we had to develop a way to understanding of understanding our audience. And I think this is a crucial thing that you want. That we want because we need observability. We need to know the whys of our system. I think this is a brief way to understand SAS and everything you can take a look into the code. I'm going to share you. I hope you enjoyed and learned a little bit of SAS. If you have any questions please lets me know. Send me an email or you can find me at my name is Marcos Henrique. If you have some opinions and any feedback to share, please read this care code. I will enjoy your opinion because it was my debut. Talk them will enjoy your opinion so thank you.