Watch videos with subtitles in your language, upload your videos, create your own subtitles! Click here to learn more on "how to Dotsub"


0 (0 Likes / 0 Dislikes)
[THIS IS MY ARCHITECTURE] [BRLINK: BOT FOR OUTGOING CALLS WITH SERVERLESS ARCHITECTURE AND QUEUES (SQS)] ARI DIAS: Welcome to <i>This is my Architecture</i>. I am Ari Dias, AWS Solution Architect and with us today, Renato, of BRLink, a very dear partner. Renato, thank you very much for coming. Renato, to begin with, can you tell us a bit about BRLink? RENATO: Of course. BRLink is a cloud consultancy, managed services and artificial intelligence solutions company. ARI DAYS: Cool. And what you brought here is a product of BRLink. RENATO: Yes. >> ARI DIAS: What's its name? RENATO: It's the BRBot Platform, it's a platform for automating calls in call centers, to reduce call center costs. So you can either reduce your call-center, or depending on the situation you can even mitigate and change everything for this. You have an API where you make a call, I want to call that client of mine, with such a schedule and with a certain questionnaire. And then all the flow happens, a robot behind it will interact with the customer, collect answers, reap the volumetry to set up a machine learning on top of that and deliver everything back to our client. ARI DAYS: Nice. Looks like there's a lot of things in there. Let's explore these items here in the architecture, right? RENATO: Okay. ARI: Very well. I believe it starts with the API Gateway. RENATO: Exactly. >> ARI DAYS: Go on. What happens? RENATO: Our client makes a call here on the Gateway API, where he says: "Oh, I want to call that customer, using that questionnaire at such a time. " When it makes that call, this Lambda comes into play. Its job is to pick up the customer's call, deal with business rules, and record it into a Dynamo table. Why does it exist? Because although we need a very short SLA between the time of the connection and the time the connection actually takes place, we need to give the customer the freedom to ask to call tomorrow, now or in 15 days. It is recorded in this table. There's this other Lambda, which always listens to this Dynamo. When, from minute to minute, it listens to what I have now or before, picks up those links and does the job to put in our priority queue or put in our default queue. In addition to putting in the queue, as we may have a limitation at the end, where it picks up and transports it to the service it will consume, being that a telephony or a text, we may have a limitation on the size of the content. So what we do, we record only the metadata's link in these queues and every important frame is recorded on S3. Recorded on S3, this guy here is always consuming, listening every minute. When it notices new connections here, it picks up the queue information to consume the S3 as well and effectively work a connection file and make the connection. ARI DAYS: Got it. So you make the call in the API Lambda receives and persists in Dynamo. Another Lambda is reading the Dynamo, and populating the queues. >> RENATO: Exactly. ARI DIAS: One thing I found interesting here is the business model reflected in the priority queue architecture, one of low priority. Very nice. RENATO: The function of this priority queue is that, where it will have the consumption to be able to request communication with any client, it may have a limitation. For example, if it will use an API, it may have a quota. If it will use a connection, it may have a channel limit. If suddenly it sends many calls here and he has a guy who needs to call more urgently. It puts as a priority, this queue is always heard first, then the default queue is heard, so once you have a free channel, the connection is made. ARI DAYS: Got it. What about this little phone here? RENATO: When you consume the queue, it assembles the whole object with the information, and everything else, then you make the call, either by a trunk, or by a API of connections, where the connection happens, it goes to a client, then the client begins to interact with the robot. Answering or speaking, records the information and the robot puts all this in the end so our client can consume it. ARI DAYS: Got it. Well, if it's a queue, I see we also have a dead-letter. RENATO: Exactly. >> ARI DIAS: How this works? RENATO: It may happen that we have a redrive policy always aligned with the customer, with the customer's need. What happens? Here, when you consume the queue, you may have some connection failure. So what happens, we consume the queue and if it doesn't work, we go back. And it has some attempts, it is always the client who defines all these rules in the panel, he decides how many times he wants to try. From the moment it did not work anymore, we put it in this queue and we have this other Lambda who is always listening to it so we can get the information about the connections that failed, because if it went to this queue, it's because it failed, to put it into our Dynamo, put in our metrics so that we can align, put in our monitoring, to be able to study the logs and see what happened there. ARI DIAS: What is the evolution of this architecture? RENATO: Today we are working according to the architecture with active connections, the receptive ones, and also in text. This is the focus for 2018. ARI DIAS: Renato, thank you very much. Everyone, great explanation. <i>This is my architecture.</i> [THANK YOU FOR WATCHING] [FOR MORE INFORMATION, VISIT AWS.AMAZON.COM/THIS-IS-MY-ARCHITECTURE]

Video Details

Duration: 5 minutes and 24 seconds
Country: Brazil
License: Dotsub - Standard License
Genre: None
Views: 28
Posted by: ashthmp on May 22, 2018


Caption and Translate

    Sign In/Register for Dotsub to translate this video.