Good afternoon. Good evening. Welcome to Track 2. My name is Michael Shearer, the Prez 98. And I have to tell you that when the schedule came out and I found out that my talk was 5 o'clock on Sunday, it was a little worried. And I'm not worried at all. Thank you so much for more or less packing the room here. And I hope that your commitment of the next 45 to 50 minutes with me will be worth it. So thank you. I'm going to talk today about a tool, a search engine called Shodan and some applications that it has for penetration testing. This is what we're going to talk today. I'm going to talk about what is Shodan. It's a search engine, but it's a little bit different than other search engines. So I want to explain how it's different. Talk about some basic operations, a little bit about the applications of the search engine to penetration testing. And then I work through a number of case studies and I want to present them to you. That's kind of the bulk of the presentation and how that really applies to what you can do as a penetration tester. So when I use penetration testing in the title, I could use all these things in the title. And I'm not suggesting that all these things mean the same thing because they're all different. However, if you do any of these things, then what I'm going to talk to you today applies to you. So I could say I could put all of these things in the title, but then the title would be just unwieldy. So when I say penetration testing, this is what I mean, all of this stuff. How many of you do one of these things? Probably most of you. Okay, good. So what is Shodan? Shodan is a search engine. It's a computer search engine. It's designed by a web developer named John Matherly, who's with us here today. I actually will talk to him a little bit later. But it's not a search engine. It's not the same as a search engine like Google or Bing or Yahoo. Those search engines crawl web pages for data and then index that data and make it searchable for you. Shodan, on the other hand, interrogates ports. So interrogates port 80 of a particular server. And it grabs the banner. So we're not talking about the data on the web page. We're not talking about the banner. So whatever HTTP status code you get, and then the banner. So IAS 5.0 or 6.0, whatever software is running, version number, et cetera. And then indexes the banners rather than the web content for searching. So we have a search engine of banners and not of content. So instead of looking for specific content on a page, we're looking for specific information about the page. Is it a desktop? Is it a server, a router, a switch, or a printer, or some other sort of device? We can find that out by looking at the content in the banner. Typically these are on port 80, but they could be banners on port 21 or 22 or 23 or some others that we'll talk about. Optimizing search results for Shodan requires us, or at least is helpful for us, to have some knowledge of what a banner looks like. So we'll talk a little bit about that as well. Basic operations of Shodan. This is just a nice little screenshot of Shodan. The URL, by the way, is www.shodanhq.com. And you'll come to this nice page here, and it's got a search box on the top just like every other search engine. And again, like I talked about, it's going to be a little bit different in terms of what you're searching for. There are also two Firefox add-ons that I'll just briefly mention. One is a search provider add-on, which adds, if you're using Firefox, adds Shodan to the little box in the top right corner of the browser. And then there's a Shodan helper add-on that is a sidebar extension for you. I'm not going to talk about these other than to just mention them that they're available. So basic operations. What's the difference between searching Google or searching Yahoo or searching Shodan? Well, the syntax is kind of the same. We can use Boolean operations plus, minus, that sort of thing. We can use quotation marks to narrow down a search, and you just enter them into the box. So the syntax, of course, of what you put into Shodan is the same as any other search engine. However, the actual content of your search term is going to be a little bit different. And we'll talk a little bit about searching later. Login. There's a couple of options. You can use Shodan without logging in at all, although there are some limitations to the results that you can get and some of the filters that you can use. You can also create a Shodan account, kind of an account specifically for that page. Or if you have any other one of these accounts, Google, Twitter, Yahoo, AOL, Facebook, OpenID, if you have those accounts, you can actually log in with those accounts as well. And again, like I said, login is not required to use Shodan, but there's a couple of filters, for example, a country and a net filter, which I'll talk about a little bit later. And those will not work for you if you don't log in. There's also an export feature that allows you to export results into an XML format, and that will not work unless you log in. So just log in page. You can just create a Shodan account, or you can just log in one of those other accounts. Most people have something of one of those accounts, if that's what you want to do. So let me talk a little bit about the filters. Filters are ways that you can take the amount of data that you get from Shodan and kind of narrow it down to a manageable level. As we look at later, if you type in the word Cisco into Shodan, there's 350,000 or something like that devices in Shodan that have Cisco in their banner. Well, that's not really useful for us if we're looking for a specific device. So the filters will help narrow us down. The first is an after. So in the case of the slide here, the filter is actually the word in bold. So followed by a colon, and then followed by whatever the syntax is. So for example, if we put after colon and then a date in the format of day, month, year, we can limit our results to information that's been added to the search engine since that date. So we can look for frequency of data. Or look for data, we can exclude older data if we want. Or before, we can do that as well. The country filter filters by two letter country code. So if you know the two letter country code, whatever the IP address country that's registered to, so for example, obviously country colon US will limit it to US registered IP addresses. Host name filters by text in the host name or domain. So if we want to limit our results to the .edu domain, or if we want to limit our results to Google.com, or whatever words you want to use in a domain or a host name, you can limit your results to that. Net filter, specific IP range or subnet, obviously if you're looking for a specific target, say your company owns a class B or something like that, and you just want to filter on that, obviously you can do that. The OS filter will search by specific operating systems, so Linux, Windows, whatever you want to put in there. Port will narrow by specific services. I'll talk a little bit about the services that are in Shodan now. And then there's also a number of SSL filters that are available with an SSL add on to Shodan. This slide just kind of shows you where you can enter the data. All the data you can enter directly into the search box if you want, the filters. The other ways that you can filter is if you look at the, there's a drop-down map, and as you can see on the map, the color of the country is kind of color-coded based on how many IP addresses in that country have been searched, so you can see obviously that US has the most on here, as well as China, Japan, and Germany, et cetera. And then you can filter by port by clicking on the box there, but it's easy enough just to put it in the search box if you want. On the country filter, if you mouse over a country, the country will turn yellow and it'll tell you how many hosts have been scanned in that country. So, for example, here on the United States, some ridiculously large number. So a couple search examples using the filters. I know you probably can't see it from here, but I'll read it to you. The search here is Apache country colon CH, CH being the country code for Switzerland. So what this will do is it will find all the results in Shodan that are registered to a Swiss IP address that have the word Apache in the banner. And the results that you'll see here, over here on the left, you'll have a IP address with a hyperlink to the actual result. Below that, you'll have an operating system if it's been identified. Below that, there's a date that that result was added to the search engine, and then there's a nice little country flag here as well. This here is the actual banner that you get back from that result, and any search terms that you enter will be highlighted in red. So you can see here that this was a Apache 2.2.13 running on free BSD, et cetera. So this is where I talk about knowing what the banner shows you is helpful for searching for certain sorts of results. Here the search term is Apache 2.2.3. So this will find any servers that have Apache 2.2.3 in the banner. Here we didn't use the country code and Shodan is helpful for us and actually will display the top four countries by results. So United States, Germany, France, Canada. If we're logged in so that we can use the country filter, we can just click on that and that will filter that down further for us. Basic operations, a host name filter. Okay, so we want to filter by host name. So the search here is Apache hostname colon dot nist dot gov. So now we can limit our searches to devices in the dot nist dot gov domain that have Apache in the filter, or that have Apache in the web banner. Or IAS 5.0 host name EDU. So now we're looking at just IAS 5.0 or Microsoft 2000 servers that are in the EDU domain. And obviously if you wanted to put a specific university or something like that, you could certainly do that as well. And then I talked about the net and the net filter. So if you want to filter by an IP or sider notation, you can certainly do that as well. Definitely useful if you really want to limit down to one specific area that you're looking for, and then the OS filter, if you want to just for looking for specific operating system. Finally, you can filter by port. Current collection is FTP on 21, SSH on 22, Telnet on 23, HTTP on 80, SNMP on 161. And recently added is HTTPS data on 443. I should note, and I'll talk a little bit later, that this data is only available through an add-on, which requires some credits. So the SSL filters, these are the SSL filters that are available with the SSL add-on. So you can search for all, I won't go through them specifically, but they're self-explanatory as to what you can search for if you're looking for specific information in the certificate or the cipher that's being used. So the version of SSL or whatever certificate information you're looking for. Search history for Shodan. If you create an account, just using Shodan, the search history in essence is disabled. In other words, your searches aren't being saved for you. If you do create an account and you can enable search history and then you can save your own searches so that if you find searches that are useful to you or searches that are finding useful data to you, you can kind of save them in a way. And again, if you go ahead and disable that once you've already enabled it, then your searches won't be indexed by the search engine. Shodan allows you to export data and this goes into XML format. So there's a sample data file there that you can download if you want to look at the format that it comes out in. And this is one of those add-on features that's available for Shodan. And the second add-on or the second other add-ons are the HTTPS data and the extended search. So typically, even if you're logged into Shodan, you're going to be limited in the number of results you can see. With the extended search add-on, you can view up to 10,000 results. So one of the first questions that I, when I talked to John about this, is like, well, what kind of feedback have you gotten about, you know, charging for add-ons or extra results and something like that? And he said, and he could probably talk about this later if he wants, but he hasn't, I mean, it's, he's done a lot of work.  So if you want extra results beyond what the initial search end is giving you then, you know, it feels like it's reasonable to ask for, you know, something for that. And we could talk about that later if you want. I will say that all the stuff that I've done, it was on the, not having, you know, using none of the add-ons. Shodan also has a newly added section called Network Radar. And this is just a nice little picture of the world and it will show you recently added data to Shodan. So what it'll do is it'll show you a nice little symbol over an area or city or, and then it'll show you the banner. So this is kind of a nice kind of view of things that have been recently added. Let's talk about applications of Shodan for penetration testing. So John originally developed this as a, as a marketing and research tool and it was not really specifically geared towards penetration testers or the hacking community. But you can see, I'm sure that most of you can see that there's certainly opportunities here to look through the data that's been collected in Shodan for opportunities for penetration testing. So that's what I want to talk about. Before I go there, I want to talk a little bit about ethics and, yeah, ethics. And just kind of go through a couple, you know, hypothetical scenarios and kind of just go through some questions that may come to mind. And I will say that when I did this test, all the things that I've done for the examples here were just done on my own. It was not authorized to do anything. So these are kind of rhetorical questions for you. Is it acceptable under any circumstances to view the configuration of a device that requires no authentication to view? So if we click on one of these links and it takes us to some sort of device and it logs us right in because there's no, there's no authentication, is that okay to view that? What about viewing the configuration of the device if we used a default username and password to get into it? Or what about viewing the device if we used a unique username or password? What about changing the configuration of a device that we don't own or that we don't have authorization to use? So this is kind of a black-to-white spectrum and this is where I put these questions on there. You may disagree with it, but I think most of you would generally agree with the general placement. So viewing the configuration of a device that requires no authentication, I think that's pretty clear. I think you could view that. You're not changing anything, you're just looking. There was no authentication required. You just clicked on a result and went right in there. Using a default username and password, well, I think you're getting into a darker shade of gray here because despite the fact that they're using it a default username and password, there's still some authentication mechanism that's trying to keep you out. That's just as far as I went, by the way. I'll show you an example of that one later. Using a unique username and password somehow that you've captured, I think that's fairly black. And then also changing configuration of the device that you don't have permission to do, it's fairly black as well. Like I said, I went to about the middle, so I wouldn't go any further than that. But that's up to you. I think that using Shodan for penetration testing requires some basic knowledge of banners, like I talked about. And also it's very useful to you to know HTTP status codes, and you all know these, so we're going to review them because we can use them to actually filter out results. We know that banners typically talk about the services that they're running and the versions that they're running.  Some people do, but most people don't. So we're assuming here that the banners aren't being spoofed. Just a quick overview of some HTTP status codes that we will see and how they can be useful to us. 200 OK, request succeeded. This is typically our best result because this means we're going to be able to view the page without any authentication at all. 301 and 302 are moved or found, and we'll see that those are not terribly useful to us. 401 unauthorized requires authentication, and then 403 is a forbidden. In other words, we can't go there. So how does that apply to us? OK is really what we're looking for, because that's going to allow us to view a page without seeing anything else. It's not going to ask us for a password, at least not to view that page. 301 and 302, typically first, in the case of Shodan, it doesn't really provide us with a lot of data. Yes, could you follow the result where it's moved to, but typically it's kind of just running into the dark without really knowing where you're going. So we can use the filters, the Boolean logic to filter these out. 401 unauthorized is typically saying, no, you don't have permission to view this page. However, it doesn't necessarily mean that we can't get there. And a 401 unauthorized on a web banner will typically have a www authenticate line, and that will typically indicate to us the presence of a pop-up box. So if we go to one of these, we're going to pop up boss asking for a username and password. 403 forbidden, typically there's some reason that we can't view the page. And it's also important to note that some banners advertise defaults. We'll see banners that say the password is 1234. It doesn't mean that they're using that, but they're at least telling us what it is, so that's useful data for us. So the first of my 4K studies is the Cisco devices. And this is the first Cisco banner I found, and I just wanted to show it as an example. The two boxes squared in red, the first one is the status code, so it's HTTP 401 unauthorized. And then we see a www authenticate basic realm level 15 or view access. I can tell you that when you see this, when you click on the result for this, you're going to get a pop-up box, and it's going to ask you for a username and password. And if we don't have it, obviously we can't get to that page. Here's an example of a Cisco banner that is a 200 okay. Notice that it does not have a www authenticate box, and it also has the last modified box. When we put these side by side, we find that the two lines, www authenticate and last modified are almost 99.9% mutually exclusive. So what does that mean for us? Well, let's look at the results here. So this is as of last night. If I search show Dan for Cisco, I get 306,000 some devices. The www authenticate, 253,000, last modified, 5800, and then only 31 that have both of those lines. So what that means is if we can get a 200 okay with a Cisco, chances are that device is not going to require any authentication at all. In fact, we really have about 5900 devices as of last night. Cisco devices on the internet publicly facing that require no authentication at all to view, change configurations, do whatever you want. You've already owned them. So let's take a look at one. Many of you will recognize this is the Cisco switch and this is the HTML interface. And if we wanted to administer this interface or administer this device at a certain level, we could click on one of these numbers right here. And whatever number of the level we want is what it will take us to. So surely if we click on level 15, which is like administrator access, it's going to then ask us for a pop-up, right? And it's going to, that's when we're going to be stopped right there. No, it doesn't. So I don't have my CCNA. I don't know what the command is. Well, they're all right there for you. And they're hyperlinked for you. So if you want to do anything to this device and you don't even know the Cisco commands, you can just click on them. And there's a whole page here. You can see that the scroll bar is pretty small. So I mean, you could pretty much run anything. And I ran a few commands, but I just did some show commands because I didn't want to actually, I told you it was not going to change the configuration of a device. So this is the configure commands menu. We were able to get in there with no authentication at all. Here's the execute command menu. We can get in there without any configuration at all. I ran show running config and I got the running config. I ran show CDP neighbors. Let's see what else is around it. And I got some other devices. I won't go into too many specific details, but people will generally say, well, I know this guy. He's doing a CCNA and he set up a router. So it's probably just one of those things, right? Well, some of them might be, and some of these are infrastructure devices belonging to ISPs. And we'll talk about that a little bit later. So what else is out there, Cisco devices? Well, this is a Cisco AirNet access point. This is just the home page though. If we went to one of the setup pages or the security page, it probably would ask us for a username and password. Or it doesn't. So what do you want to do? Change it? Turn it off? Change the IP address? Yeah. Security page? No, nothing there either. They really should enable re-encryption or maybe we should enable it for them. Network interfaces, security services. You want to turn on some services? Turn off some services? Okay, let's keep going. This is a Catalyst 2960 switch. This is the dashboard view. If we went to the configuration view, it's going to ask us for a password, right? No, it's not going to. Some people are really good about labeling their ports. They'll tell you everything you want to know. Where they go to... I actually had one example that's not on here. That was a... It was a real estate company in New York. And they owned several buildings. And they had a switch that administered internet access to various businesses. And each one of their ports was like two XYZ company or two this company or two. So I mean... What about turning them off or just let's go have duplex for a day and see how their internet... And again, let me be clear. I didn't change anything on these devices, but you could if you wanted to. You could. I mean, it's right there. Setup page...  Cisco Security Device Manager Express. Configuration. Change the password. Change the IP address. Change the routing. Security. It's pretty much whatever you want. Like I said, there are probably five, six thousand of these devices out there on the internet. And that's just what Shodan has indexed. Shodan has not indexed the entire internet. Large portions, but not the entire internet. So that's just what's already been indexed. It's kind of scary. So second case study on default passwords. And this was the easiest search I did and I just searched for the words default password because I wanted to see what banners have the word default password in them. And again, let me caveat. This doesn't mean that that device is using that default password, but at least they're telling us what it is. And how many people change them? Some people don't change them. So chances are some of these devices will be using them. So I'm not going to be looking for an attack, but of course, you know, let's try it. So this is the absolute first one I found. It's a 401. It has a www authenticate basic realm default password 1234 printer web port. It's a web interface for a printer. So we're probably going to get a pop up box, right? So yes, it's not using it. It doesn't mean it's using default password. It's a possibility. The default password is 1234. What about the username? Well, there's none listed. So what are our options? Well, a null username, right? Or admin or root probably. So what do we get? Pop up box. So what do I try first? I'm going to try a null username because they didn't list anything, and I'm going to try 1234. But the chances that it's working the first time, or it does. This device is, I mean, this is nothing big. It's the setup for a printer. But, you know, what do you want to do? By the way, all these menus, everything here is accessible now because even though it's the default password, we've effectively logged in. So we authenticate it. Occasionally, if your browser or your computer is not set up to display foreign language stuff, sometimes you get these codes and things, I've found that if you don't know the language, and even if they do display the language, like it's Chinese or Japanese or whatever, typically the underlying HTML is still in English. So if you mouse over the links that you don't understand and look at the status bar, it will typically tell you what those things are. I mean, some of them are pretty obvious there. Well, I went after Cisco, so let's go after Huawei. I mean, they're, you know, I searched for Cisco before, but I want to search for Huawei. And this is where I use those exclusions of I don't want 400 codes, I don't want 300 codes. So I just did minus, I mined all those. And the result is that I get all 200 OKs, which is exactly what I want. And it turns out that there's 283 or so Huawei results on the internet, and almost all of them, or at least a good portion of them, all within the same subnet. And I was like, that's kind of interesting. And if you look at, I know you probably can't tell, but it's 150.186, whatever, and the flag is the Venezuela flag. So I thought this was kind of interesting. And the result is it's Huawei ET523. Well, I want to figure out what that is. Well, it's the Echo Life IP phone. OK. And it adds a whole bunch of these phones public-facing to the internet. So let's check out what they have. Oh! See, this is a good example where we had a 200 OK, so it says, yes, you can view the page, but it's asking for a password. And I couldn't, so I, you know, what's the default password for a Huawei ET523? I don't know, but I found that the default for most Huawei devices is, I don't know, password or something. Again, these things never work on the first time, or they do. I'll scroll through these just to show you the whole screen, but yeah, this is the entire configuration for the phone. A couple of interesting things here. One would be the URL for the firmware upgrades. So if you want to change that and upload some rogue firmware to them, you can certainly do that if you wanted to.  It turns out that this is some technology corporation in Venezuela and if you go to their homepage, there's smiling Hugo Chavez all over the page. So if you want to mess with them, you know, go for it. And one notice, I didn't block out any of the IP addresses. I mean, they're right there for you. I'm not encouraging you to break the law. I'm just showing you something. OK, this is my favorite one and so I saved it for last. But the title was kind of boring. Infrastructure exploitation. That sounds kind of boring. So I changed the title. Some of you may, I did a talk up in the sky boxes on Friday and the talk was just about this section. So and I think those people would agree that I didn't really oversell the title for this section because you'll see what happens. So I was running across a number of Cisco devices and I was doing a random search. And I found one of these, again, it's another Cisco web interface. And so, well, let's just go right for level 15. Yeah. And I did white out some of the things on here because this was a, at the time, this was a open problem with this, you know, company. Show IP route. And there's a long page of this and I ran a show some other commands. The running config. And so I'm running through these commands and when I get to show CDP neighbors and I know I blanked out the device IDs but the URL was very interesting and because it said it was a telephone, it was an ISP. And so you can see here that there's a number of 3750 switches and then there's a Cisco 6.06 which is the core router for the ISP. And they were all open. Yeah. So I looked up the IP address and it turns out that this was an ISP in Florida. I'll say that. So all these devices were wide open. Contained in the configurations were VLAN IDs for their internal ISP network, hotels, condominiums, departments, convention center, public backbone, all this stuff. So I'll talk very briefly about disclosure because I don't do disclosure. I don't search for bugs and vulnerabilities and things like that. But I thought when I came across this one I thought this is kind of important. So I wrote a one line I looked up the security contact for the ISP and I wrote more or less a one line email to the security contact and it was something like how do you tell them what you did without implicating yourself? So I said something like the following IP addresses appear to allow unauthenticated access to devices on your network.  I didn't ask for money.  I didn't say that. They offered me money and I thought that was kind of cool. So he said can we call you? And again this is where your admiral act bar alarm is going off. Right? It's a trap. Right? I don't do disclosure so I'm just kind of like I don't really know what I'm doing so I call them. And very nice. He was a younger guy. This is not a big ISP. This is a small regional ISP. And they were very gracious about what had happened. He just kind of know how I found these devices. And I didn't go into show Dan but I did say that I do research on web banners which I do and I was just doing research on specific information on web banners which is what I was doing and I just came across their devices. They were specifically looking for their ISP. And I don't think he really understood what I was telling him but and he explained that they recently added these devices to their network and that the guys who installed them obviously didn't disable the web interface or something like that. Excuse me. And asked for my address. So again the alarm is going off. So I talked to him on the phone and now he wants my address because he wants to send me the check. So I gave him my address. I will say that I haven't gotten anything in the mail. Not only not the check but I haven't gotten like anything you know legal or whatever. And they did close off the problem.  But what I will tell you is that with the information I had and with the access that I had could I have routed any or all of their traffic to a third party destination and then right back to them and then just sniffed all their traffic and totally owned all their customers. Absolutely. I could have. So I don't think it's unfair to say that. I mean really could have owned this ISP. So there. I mean yeah. A few other small examples and just and then we'll general observations. So I did some searches on show day and this is just for interesting data. I search for IS 5.0. We know that it's Windows 2000. There's a lot of them out there. So you know, this is a couple months old but 362,000 IS 4.5. Now we're getting older. Now we're going back into the 90s. Still almost 10,000. 3.0. You see where this is going right? No. 42. Does anybody know does anybody know what IS 1.0 maps to? It's like Windows NT 3.51 maybe or something like that. It's like 1995, 94ish. Wow! If you go to these web pages I mean they look like they were made in 95 and never touched since. So I mean they may not be used. What's that? Thanks. Thank you. Let me show you one more example before I go into the conclusions. This is another fun example. You've all seen the Google Hacking viewing webcams and stuff like that. Every six months the news media rediscovers the story and plays it on your local news and thinks it's something new. And it isn't... This is just one small side note. Pan and tilt features work on this one. These ladies were diligently working at their computers and I was trying to get their attention and they wouldn't bite. They wouldn't bite. So here's a good example of what I mentioned. If you don't understand the characters I think this is Japanese. If you don't know what this means you can typically the taskbar will tell you what it is in English. In this case it does. So this comes out to snapshot so if you wanted to take a snapshot of the whatever screen is on there right now and then a client which isn't terribly useful to you. The second point about this slide is that I'm viewing this web page in Firefox and while many people still use Internet Explorer I don't know why you would but you might want to. I do use something called IE View Internet Explorer in Firefox. So let's take a look at this and see that there's actually something different here. We actually have a third option. So we actually have snapshot, client and setup config which was not actually viewable in Firefox. Very interesting. So what happens if we go to setup config? Well we can pretty much do anything we want. So again another example if you don't understand the language mouse over and it will tell you these are all the things you can do. Security, system, network, wireless, I mean whatever, wide open. Okay just some general conclusions about Shodan. We've got about 10 minutes left. Shodan aggregates a significant amount of information that's not already widely available. Could you go home and do something like this? Absolutely, you could do it. But it's going to take a lot of time and we've done it for you. It does allow for some passive vulnerability analysis. If we're looking for a certain version of software we can say hey, we can search for that and actually no with some degree of confidence that that IP address is running that software without ever even touching it. Is this going to totally take over the world? No, it's not going to. But this is something new for penetration testers. It's something that you can do to add to explore, to see what other data is out there. And I think it's going to help shape the path for future vulnerability assessments. John Madoli is the creator of Shodan and I'll have him come up here if he's willing to answer a few questions. If you have them for him, these are the guys who wrote the add-ons. People always ask about slides, so here you go. They're not there yet, but they will be really soon. There's a site called Scribe.com. I put all my slides from all my presentations on there. I'm going to flash the press 98. There's some earlier versions of it, but this particular slide deck will be on there probably by tomorrow. So if you want the slides, there you go. We will save the last 10 minutes for questions. I will try to repeat them so that everybody can hear them. And thank you.


Hey everyone, what's going on? I am Greg Sussman. Welcome to the week six waiver wire show. Frankie, what's happening? Not much, Greg, excited to be here. It's Buffalo Bills Week. How are you doing? Always happy to be here for Buffalo Bills Week, so I'm doing tremendously. Let's begin at the quarterback position and we'll start with the Buffalo Bills. Josh Allen coming off the by doesn't get any better. Facing off against the Miami Dolphins, the first of several bills we're going to talk about on today's program. Why do you like Josh Allen, other than the fact that he's facing the Dolphins? So Josh Allen still has some issues, obviously, with turnovers, but he is progressing. We see the completion percentage up this year to 62.6%. And that was a huge knock on him coming out of college. That's up from last year's 52.8%. So he is progressing in some parts of his game. And from a fantasy perspective, he's a lot like Lamar Jackson. I'm not saying that this guy is going to go out and run for 150 yards like Lamar Jackson just did in week six. But Josh Allen has 41 rushing attempts on the season. That is second to only Lamar Jackson can end. Josh Allen did not play in week six because of the buy. So we know that he can make some plays with his legs that helps him overcome some of his deficiencies in the past game when it comes to interceptions and fumbling the football as well. So we know he's going to run a little bit. He has a cannon. He can make plays down the field, improving the completion percentage as well. And he's going up against the Miami Dolphins, right? It's just a great matchup in week seven. They're allowing the most fantasy points to opposing quarterbacks this season. 14 passing touchdowns and just one interception. And you know what, Greg? It's not just week seven against the Miami Dolphins. If Josh Allen was dropped in your league because he was on a buy, if you play in a one quarterback league, how about these next five matchups? Miami, the Philadelphia Eagles, Washington at the Cleveland Browns and at Miami Dolphins again. So the next five matchups look phenomenal. We're all in on the Buffalo Bills. Absolutely. The Bills schedule, it is right for Josh Allen. So this isn't a one week buy replacement quarterback. This is somebody that over the next few weeks you may want to use.  I know you don't have the schedule in front of you and I didn't prepare you for this, but Josh Allen or Jared Goff right now? Yeah, I'm going to leave with Josh Allen. Look, we've seen quarterbacks like Josh Allen take advantage of these matchups in the past.  He had that stretch of seven or eight games where it was a really, really, it was really tasty schedule and he was able to make the most out of that. Josh, Jared Goff just does not look like himself right now. This Rams offense is broken. I don't know if it has to do with Todd Gurley, the offensive line, not being where it has been in years past. I know that you could still use Jared Goff as a streamer in some home matchups, but he was home on week six, didn't look good against San Francisco. Give me Josh Allen. Josh Allen, a quarterback, not just for now, but for the future as well. Josh Allen isn't available. There are other directions that you can go in this week, Frank. What is one of those directions? Yeah, we'll go with Jacoby Berset going up against the Houston Texans in week seven, coming off the buy. So, you know, T.Y. Hilton should be good to go in that matchup and T.Y. Hilton has typically torched the Houston Texans in his career. Houston Texans, not known for their secondary and aging secondary, one that does give up a lot of fantasy points as well. Jacoby Berset has played well this season. He is a top 12 fantasy quarterback in terms of points per game. Frank Reich, like we said, coming into the season, has put Jacoby Berset in a really good position to succeed here. Frank Reich, one of the smartest minds in the game right now, one of the smartest offensive minds. He knows how to scheme players open, and again, he knows how to get the most out of his players. He's doing that with Jacoby Berset right now, who is completing nearly 65% of his passes on the season. He has 10 passing touchdowns, so just three interceptions could make some plays with his legs as well. Maybe rushes for 15, 20 yards, which helps add to his floor. And I mentioned going up against the Houston Texans. That total right now is at 48 points, so we're expected to get some points in that game. And they've allowed six passing touchdowns over their past two games as well. So as I mentioned, this secondary is not a great one. If Josh Allen is not available in your league, I'm looking at Jacoby Berset as someone that you can stream in week seven against the Houston Texans. I don't even think it's just streaming him against Texans, Frank. You mentioned Jacoby Berset right now, a top 12 quarterback and we need to treat him as such. Maybe the name isn't sexy nor the team, but an offensive line as good as any in the NFL. Berset, a top 12 scorer on a weekly basis. So let's just believe in what it is. Read the facts, look at the numbers. Jacoby Berset deserves to be in your starting lineup.  Gore starting, we'll see if Devin Singletary is active this week. We know Frank Gore is going to get the majority of the workload, which puts him in a good spot, especially after you saw what Adrian Peterson did this past weekend. Yeah, to quote my buddy, WWE superstar Eric Young, we will now be referring to Frank Gore as Infinity Stone, specifically the Time Stone. This guy continues to turn back time, the way that he's playing, averaging 4.4 yards per carry so far this season. A couple of weeks ago, back in week four, Frank Gore ran for 109 yards against the New England Patriots. They haven't allowed a single other running back to run for more than 38 yards on the season. This Buffalo Bills offensive line is playing extremely well. They're second in the NFL in adjusted line yards. That comes according to football outsiders.com. So the offensive line is playing well. They're run blocking extremely well and Frank Gore is playing extremely well also. I do think that Devin Singletary is going to be back from the hamstring issue. See if he's available as well. I would want to own both of these guys but the next five matchups again for the Buffalo Bills are phenomenal. They face the Dolphins twice in that span and even if Devin Singletary is back, I would expect Frank Gore to see 12 to 16 touches per game in that range. This Dolphins defense are allowing the most fantasy points to opposing running backs on the season. They're allowing 4.8 yards per carry to the position and we just saw another senior citizen in Adrian Peterson run for 118 yards. I think Frank Gore is going to be in play as a low end RB2 high end flex in week seven against the Miami Dolphins. Frank Gore, the Ageless Wonder is going to be back in the saddle this week after the bye week for Buffalo and you know that Buffalo wants to run the football. Whether it's Josh Allen or Frank Gore, they're going to be successful doing it because it's against Miami. Frank Gore, a no brainer waiver wire pickup if he's out there. But if he's not, you should also make sure Alexander Madison isn't out there either. He's the Hank of the Daven Cook but this past week he outrushed Daven Cook and also just had two less carries. That was a pretty even split. Not saying Daven Cook's losing his job, Frank, but that was kind of high opening. Yeah, I'm starting to think that Alexander Madison is not just a handcuff. He has standalone value as well. Coming off career highs, 14 carries, 63 rushing yards against a really, really stout Philadelphia Eagles run defense as well. He had 22 more rushing yards than Daven Cook in this matchup on two less carries, as you mentioned. He's not going to steal Daven Cook's job. We understand that. But we also understand that the Minnesota Vikings want to run the football. When they are in neutral game scripts, which means when the game is within seven points either way, they're one of the league leaders in running the football. Even when they're not, they are second in the NFL in rush percentage so far. So we know deep down they want to run the football. I know that they just got Stefan Diggs involved and they got Adam Thielen involved, but I think still at their core, the Minnesota Vikings want to run the football and Alexander Madison is really talented. I think we're starting to open our eyes to how good he really is. He's a rookie obviously just drafted in this year's NFL draft. He has 252 rushing yards. Here's a fun fact for you. That's the same amount as Joe Mixon. That's more rushing yards than Austin Eckler and James Connor on the season. So going up against the Detroit Lions in week seven, a team that is allowing the fourth most fantasy points to opposing running backs. I think that Alexander Madison can actually sneak in as a low end flex play. I'm not saying that it's a great play, but if something were to happen to Daven Cook, Alexander Madison instantly gets vaulted up to a high end RB2, maybe even low end RB1. That's how much I think of this kid. So make sure that he's owned. I think he's up there as one of the best handcuffs with the Chase Edmonds of the world as well.  Maybe not just the handcuff anymore. President Alexander Madison in a good spot to help fantasy owners, especially those desperate with the by weeks here. Moving on to the wide receivers. We go to Dallas where they lost Amore Cooper to what looks like deep bone bruise. That's okay. And hopefully we won't keep them out for a significant period of time. With Cooper out and Randall Cobb out this past weekend, Dallas turned to speaking of Eric Young, an old favorite, Tavon Austin. I didn't think we'd be talking about Tavon Austin in 2019, much like I didn't think we'd talk about Adrian Peterson and Frank Gore in 2019. Yeah, Frank, here we are. This is why we play the games in fantasy football, Greg, because you never know what's going to pop up and here we got Tavon Austin falls into our lap, heading into week seven. Honestly, the Dallas Cowboys offense and specifically their wide receivers are just really banged up right now, Greg. I know you mentioned that Amore Cooper is dealing with this quad issue. Randall Cobb also dealing with a back issue. That's why Tavon Austin was able to play as much as he did in week six against the New York Jets. He played 76 snaps in week six against the Jets, 48 of those coming in the slot. And we know that in today's NFL, the slot receiver is so, so valuable, especially for fantasy football. So this does come with a bit of a caveat. You have to pay attention to whether or not Amore Cooper is going to play, whether or not Randall Cobb is going to play. Cobb has dealt with so many injuries in his career, specifically over the past couple of seasons. That's why the Green Bay Packers were all right letting him go and signed with another team. So just based on all these issues, these injuries, I do think Tavon Austin has an opportunity here and he's coming off a game where he led the Dallas Cowboys in receiving. He had, you know, seven targets as well. And he's going up against the Philadelphia Eagles that are just getting shredded. We saw what they just allowed against Stefan Diggs. They allowed three touchdowns to Diggs. They allowed an additional touchdown to Adam Thielen out of the slot as well. And the Eagles are really good against the run. I don't think that's going to stop the Cowboys. The Cowboys are still going to try and force feed Ezekiel Elliott in this matchup. But the way to beat the Philadelphia Eagles is through the air. I think Tavon Austin can have some success. I'm not saying that he's going to have a dozen or two touches, but I still think that he can get, you know, six to eight, six to 10 targets in this matchup if everyone is hurt. So just pay attention. Tavon Austin in a really good spot against this Eagles defense. The first time in seemingly years, I actually trust the Dallas offense to be creative because Kellan Moore has proven as an offensive coordinator and a play caller. He can surprise you. And I think Tavon Austin's re-emergence is part of that. We'll see if Randall Cowboys, we'll see if Murray Cooper does as well. But if Tavon Austin out there, he's not going to cost you very much. He's out there, but he's not going to cost you anything. Maybe take a shot in a good spot here against Philadelphia. From one Dallas slot receiver to an ex-Dallas slot reliever. We go back to Buffalo, where Cole Beasley is always worth talking about. Frank, year after year, I don't care what team Cole Beasley plays for. But when the buys come, you need someone that's almost guaranteed to give you a five for 50 because of the PBR. That's 10 points. That's basically Cole Beasley every single week. You gotta love him. You gotta love Cole Beasley. You gotta love all the Buffalo Bills. As I mentioned, it's Buffalo Bills week going up against the Miami Dolphins this week. And also five weeks from now, their entire schedule for the next five weeks, looking pretty good for the Buffalo Bills. I have interest in both Cole Beasley and Duke Williams, but honestly, Greg wouldn't let me talk about Duke Williams. So we're talking about Cole Beasley. And Cole Beasley is coming off his worst game of the season, only three for 21 on three targets. But he does have at least nine targets in three of five games. He's tied for the team lead with John Brown, with 22% of their target share. Seems like he has a nice rapport with Josh Allen so far this season. Josh Allen, someone we thought coming into this season, really likes to target down the field, which he has done with John Brown, but he's also learned to check it down a little bit. That's why we're seeing that completion percentage go up for Josh Allen. A lot of that is because he does have a nice rapport with Cole Beasley. And throughout the buy, they traded away Zay Jones. So he's now gone on the team. He was getting, you know, not a massive target share, but he was getting a few targets. Some of those probably go Duke Williams' way. Some of those probably go Cole Beasley's way. And of course, the Dolphins are allowing the ninth most fantasy points to opposing wide receivers this season. Terry McLaurin just went off her two touchdowns against them. It's a safe play and a really good matchup. It's Buffalo Bills Week. You know how I'm feeling? Frank is going to go off about Duke Williams, just knowing because I didn't want to talk about him. Because you know what? Not very good. Cole Beasley, very good. That's the Buffalo wide receiver you want to own, but Frank's right. Can't have too many bills this weekend facing Miami. Moving on to the tight end position, I will admit Frank wanted to put Dawson Knox here again. We did it. Instead, we're going to another Frank guy. And that's Darren Fells. I believe he wanted Fells last week on the show. I didn't let it happen. But Fells led the Texas in receiving yesterday with Deandre Hopkins and Will Fuller actually taking it back seating. Jordan Acons, he was out there a lot and it's clear when Kenny Stills doesn't play, they give you a lot of too tight end personnel, which leads to Darren Fells being on the field a lot. And being successful. This week, Fells and the Texans face off against Indianapolis Colts. And if you lost, Will Disley may want to pick up Fells. If I would have told you that there would have been a week this year where Darren Fells was going to lead the Texans in receiving with Deandre Hopkins, Will Fuller, and Duke Johnson all healthy. You would have looked at me like I had three heads. But ultimately, he's getting the job done. He's been a top 10 tight end each of the past two weeks. The targets have been there. Season high, seven targets. Six receptions in week six. 69 receiving yards as well. They run a lot of two tight end sets. Jordan Acons is on the field also. But Darren Fells is the one that's been a little bit more consistent. He's seeing more work. He's seeing more targets. And it's a good matchup going up against the Colts who are allowing the third most fantasy points to opposing tight ends. This game as of now has a 48 point total. So we could see a little bit of back and forth. There's more of a desperation play but with Will Disley going down and four teams on a buy, I think a lot of teams are going to be desperate for tight ends. That's where Darren Fells comes in the mix. Desperate for a tight end. Darren Fells makes sense. Who would have thought, as Frank said, with Houston having Dodger Hopkins and Will Fuller and do Johnson and QQT. It'll be Darren Fells leading the way. He's a fine waiver wire pickup near the tight end position this week. Whether you don't want Darren Fells in your spectacle, your skeptical is what we're going to go for. Kind of like I was last week. What's another direction that you can go in, Frank? We're going to go with your boy here, Greg. It's Rhett Ellison of the New York Giants. Now, I realize this one comes with a caveat, much like Tavon Austin, who we spoke about earlier. It all is dependent on how healthy Evan Engram is. Evan Engram dealing with an MCL sprain is something that he's actually dealt with in the past as well. So I know that they've had a lot of time off. They're going to have 10 days off. They played on the Thursday night football game in week six against the New England Patriots. But I don't know that Evan Engram is going to be back in week seven and this is a prime time matchup going up against the Arizona Cardinals. We love, love, love targeting tight ends against the Cardinals. We just saw Austin Hooper go for eight catches, 117 yards and a touchdown against this Cardinals defense. They're allowing the most fantasy points to opposing tight ends. They've allowed a touchdown to a tight end in every single game. But one, thank you, Tyler Eiffert. I've never heard of handcuffing tight ends, but I'm going to make it a thing. I'm actually going to bring that up right now. If you own Evan Engram, I would go out and pick up Rhett Ellison just to cover myself because I want to have the tight end that's going up against the Arizona Cardinals. And even if you don't own Evan Engram, if you're worried that he might miss this week and you are desperate once again for a tight end, you don't get a better matchup than going up against this Cardinals defense. And Rhett Ellison coming off a game where he just had a ton of targets. He saw 25% of the target share in that game against the New England Patriots. So these are desperate times. They call for desperate measures, but going up against the Arizona Cardinals, pay attention to Evan Engram's health. Coming out of the mini-buy week, last week playing on Thursday Night Football, Evan Engram did practice on Monday. He thinks he has a good shot to play. If he doesn't, you always want the tight end against the Arizona Cardinals. It held true this past weekend. So make sure you get Rhett Ellison in there if Evan Engram is inactive on Sunday. One last pick up to get to, Frank, and that brings us to your defensive pick up of the week. If you're streaming defense, there are a couple out there, a lot are owned by 60% of leagues, but why don't you give us one that's not? Yeah, first and foremost, I'll just throw a few of those defenses out there that are owned in a few more leagues. But if they're available in yours, make sure that they are added. It's the bills going up against the Miami Dolphins defense, and the 49ers who just shut down the Los Angeles Rams, they are going up against Washington. But if both of those defenses are owned, I'm looking at the Kansas City Chiefs, and I understand that this is a weird one. The Chiefs are normally viewed as a team that doesn't have a great defense. They're allowing the fifth most yards per game so far on the season, but they are going up against the Denver Broncos on Thursday Night Football in a short week, and the Denver Broncos are allowing 9.3 pressures per game. That's 10th most in the NFL, and Joe Flacco has an interception in every game, but one, I do think that the Kansas City Chiefs are going to be playing with a lead in this game against the Denver Broncos, which means we're gonna get a lot of dropbacks for Joe Flacco, which means we have opportunity for sacks, we have opportunity for turnovers. He's throwing a lot of interceptions so far this season as well. I understand the Chiefs, if it's not normally a good one, but I think that they're in a fine spot coming up against the Denver Broncos, Greg. Fine spot against the Denver Broncos, not a fine defense, but against Denver who can't really score, Thursday Night a short week. If you ever take a shot on Kansas City's defense, hey, why not now? That's gonna do it for us here on the Fandal Harriott. Frank, good luck in your waiver wire this week, like the third week in a row. I don't want any of these guys. Well, thanks, Greg. I can only work with what I'm given. Nobody circles the wagons like the Buffalo Bills. Good luck, everybody. Tomorrow, JJ Zachariasin joins me and we go to the players that he's buying and the players that he's selling get those waiver wire bids in. We'll see you back here on The Hurry Up tomorrow.


Thank you. I'm Vinicius Pacheco. I'm from Brazil. I have a funny accent. I'm based on Argentina. And I'm a senior software engineer at Eventbrite. And it's a very cool company. And without the support from this company, it's impossible to be here. I'm coming from Mendoza. It was 20 hours in flight. So Mendoza is in China. And please, a applause for this company. They are amazing. Thank you. If you don't know me, every time I gave normally, Star Wars talk. And today, it's not different. So after this moment, I can't hear you. Okay. Now, it's better. I released a book earlier this year in January. And the content of this talk, the subject of this talk, make part of my book. There's the link on my Twitter, too, if you want to buy. The ebook is very cheap. I think it's just 9 pounds, something like this. And let's start. Our agenda. What is CQRS? When can we apply this? Understanding CQRS, applying, there is a live code. And the common mistakes. When you see a new order on the screen, there is a live code. Okay. It's the rule. So what is CQRS? Someone here has been working with CQRS. Just to know. A couple of people. Someone know what is a QRS or listen to something about this pattern. Okay, great. So there's no doubt. Cuman, query, responsibility, segregation. It's what means CQRS. It was a pattern documented by Greg Young. And he told this about the pattern in 2010. Basically, where do you have just one object responsible to change things in the server and to retrieve data in the server, you will split this in two different segments that one will be responsible to write and another one responsible to read. So when can we use CQRS? There is a Chewbacca. I love Chewbacca. He's fine. So the normal architecture, thinking the normal application architecture. No, no, no. It's not this architecture. This one. There is a UI or API, a domain, a repository, a model that's responsible to connect with the DB and to write and to read stuff and could have a controller or something like this. It is our bootstrap application. So it's an instance of my bootstrap application and it's connected with my storage. And when I deliver a business to the internet, there is a word that's very dangerous to my business. This word is success. And why? With success, there are more customers, more clients, more people connected with me and now I have a problem. And why? My application has a limit and I will rent a new machine. Okay. It's great. And this process is repeated over and over and over again and I have a new instance and another instance and now I could figure out that my scalability is not more linear. My second instance could have a linear scalability like, okay, I have, I don't know, 10,000 requests per second and now I have 20,000 requests per second. But there is a moment that my scalability is not the same. I cannot scale 50% or it's just 10% for each new instance. And why? Because maybe your issue is not in your application but in the storage. And there is another instance that doesn't scale very well and now it's over. My storage starts to create too much latency or there are very, he's very responsible to do things that is not prepared to do. And my business is out. It's a sad day. So there is a first option to try to scale to solve my problem. And do you know what is this option? Someone knows? Someone? No? No? And master's slave. It is my first option. There's a slave, you know, like a slave from Java, the rut. And yeah, she's a slave. Yeah, okay. Master's slave. And there is my application. Now I have the master's slave and I'm just replicating the data from my master and my master is going to receive all the writing process and I'm going to replicate this to my slave that will be responsible to retrieve the data. But in fact, I'm not optimizing the data. I'm not optimizing the queries. I'm just replicating the data. And it's very hard to measure how many slaves I have. And when my problem is in the writing process, my problem is to write, it's very difficult to figure out how I could improve stuff on master. And it's not the solution for this specifically kind of issue. Okay. It's a good approach, but not the solution. And there is another stuff, event or consistency. If you don't have the good conscience that, okay, there's in my mind, I would like to use event or consistency. Okay, it's okay. Event or consistency is good sometimes. But if you don't have this in your mind that accidentally you are using event or consistency, it's an issue for you. Okay. And there is a second option. Do you know what is this option? Someone knows? Someone knows. Mind, remember like control. No. It's closed, but it's not command. Someone? Someone? No? Okay. It's cache. Because it's memory, you know, like my trick. So, yeah, bro, erase your mind. Like saying, yeah. It's great. So it's a good strategy. Now, I'm put a cache and it's real. Remove some have processes over my database. And it's okay. But I'm not optimizing the queries yet. And I'm optimizing that segment that normally is not so expensive than the right process. So read normally, usually, is easy than write things on DDB. And I'm trying to optimize my issue that's write and read, just optimizing the read process. Okay. And there is another stuff that's very hard. If you are old in IT, you know that there are two things that's very difficult. The first one is name it classes. And the second one is invalid cache. So, and now I have data synchronization. The first one is valid cache. Okay. So, it's a pleasure, but I can't hear you. Sorry. It's the year. When secure s is utile, when my start is a bottleneck, definitely you could use this pattern as a solution. When I have complex queries to my ORM and they could optimize these queries. And when they have a big number of users updating a small dataset and the data could be outdated. In fact, if you think on the Facebook feed or in the Instagram, every time you are consuming data, that is outdated. And why? Because when you are looking, someone updates the feed. So, it's a ventral consistency every time. It's not, okay, I have my consistency, it's very well, it's totally right. No, no, no, no, no. It's not true. It's not true.  And for this, secure s is a good pattern. So, understanding secure s. Teach me, sad ray. I don't like the last two movies, but yeah, I prefer, Star Wars has just six movies. And the cartoons, I like the cartoons. Come back. Yeah. Oh, look, look, look, we will appear here. Yeah, you will see, you will see, you will see. Not boo yet. There is a good motivation. Crerostack in the common stack. Basically, the secure s is divided in two big pieces. The crerostack that's responsible to retrieve data and the command stack that's responsible to, to administrate my writing processes. Okay. The crerostack is simpler than the command stack. It's synchronized normally. And it presumes flat queries. Do you know what's a flat query? Someone don't know what's a flat query? Okay. A query could have joins. It's a simple explanation about flat queries. It's a poor explanation about flat queries. A flat query is every query that I'm going to optimize the data to reduce the number of joins that I'm going to do in my database. So, if I know which kind of data I'm going to retrieve, I will prepare this data to return with just one index or two index, but not doing joins and going to the deep level on my data. So, it's basically this. And the command stack is potentially a synchronous. Has a behavior centric. So, each command looks like a use case. And has an imperative fashion. So, it's not more just a post for my endpoint user. No, the endpoint is an imperative command like create user or update the user name or something like this. It's a command. And the command handlers just return success or failure. Like I accept your request, but I don't know what happened. I don't know what will be the result. And the command updates the own entity that make parts of the command stack. And going to dispatch events that there is an event component that will be responsible to update or to normalize the order DB or the order storage that responsible, that the responsible is the query stack. Synchronization. There are four ways to synchronize data using CQRS that's like by the book. So, the first one is the automatic update. The automatic update is like I receive a data from my put process, my pulse or put, my command. And now I go into send an event that is totally synchronous using RPC or binary communication or REST. It doesn't matter. But the component responsible to normalize the DBs will do this stuff instantaneously. So, there is the update possible. Update possible is the most common synchronization in CQRS. So, the command going to dispatch an event and the storage is information on a bus or on a broker or on a queue. And the component will be responsible to consume this event and normalize the DB on the query stack. But there is all the time of the word to do this. The third option is the control update. So, I go into update to normalize my DBs every two minutes is an example. There is a ground responsible to normalize the data. And the other option is the update on demand. So, when I receive a get to my query stack, the query stack is going to check, hey, I'm outdated. If I'm outdated, I'm going to say, hey, please, come on, give me the data. And they're going to be created a new event that the query stack is going to consume and write on the DB. So, queuing. It's a diagram that there are many, many diagrams about CQRS. And I like specifically this one. And why? Because it's like, if you follow this diagram, you could use all these synchronization styles, okay? And it's very flexible diagram. So, there is a client, you weigh API internet that's going to talk with my public-facing if we are thinking services. And my public-facing going to deliver a command. The command will encue the information and my domain layer gets the information and the domain knows what is necessary to do. And the command will update my normal ICB. That's my source of through. Normally, this one here is a C called DB. And going to dispatch an event, this event will be encue it. And a component, an event component will start to consume the skill and write this stuff in the normal ICB with time. Or I'm going to write this here directly, but normally with time, usually with time. And this normalize DB is very common to see no C calls here. Or document DBs. It's common. It's not mandatory, okay? But the main point is this command will create the flat query. So optimize the stuff here to be fine easily by this request. So, let's figure out something here. Applying CQRS, if there is a Yorda, there is a life code. So, all the code is on this link. Okay. There is a small project, a project using CQRS. It's just for the Python. You could download this and do some experiments. I'm using the framework in this example. Docker, Mongo, Postgrease, and ReptamiQL. So, it's the same diagram. But now I changed the names of the components to be clear what's going to happen in our service. It is a user service. Okay. So let's see how long time I have. I have time. So, my create user, it's the imperative command. And there is a convention that every event, we will name it in the past. So, user created. If I dispatch another event, you'll be in the past too. So, let's see. No. Let's come back. Now, the code. Let's figure out what we have here. There is my Docker compose. The code stack, the DB is a Mongo. A Mongo DB here. It's a Mongo DB. The command stack is a Postgrease. There is my command stack here. Okay. My Postgrease. And I'm using SQL to write a ReptamiQL. Okay. And my user service. The user services entities are the user model. Okay. And my permissions model. I could have two permissions. Admin or user. So, I'm going to do a post and I will write a new user and the permission that the users, this user have and is it. There is the order entities or structures that they're going to use in my Mongo DB. Okay. The service. I could write this in different models. Modules like domain module, repository module, this kind of things. But I wrote all the code in the same file to be easy to navigate. Okay. There is the framework and some configurations. But it's my API. Okay. My API. There is a reference to my query stack. And it is my post. My post is the first layer on my command stack. This post going to receive the data from my request. Validated for the payload. It's a valid payload. And prepared a cluster of RPC communication to do a sync RPC and to put this on my, on my queue. And my queue. And I create a location. And I go into this patch and 202 event with the location where will be the data. When the data obviously going to be consumed by my query stack. Okay. And my API that are an API to get all users paginated. And the user by ID. And the user by permission. So, I going to get, I want to get all the users that has the same permission. It could be a join on my DB because I have two different entities. But won't be. You'll be a flat query. So, there is my command stack. And inside my command stack, I put my user domain. It could be another module. Domain. But now it's there. So, my command stack, I have a, it's just to use the framework. It's a dispatcher. An instance of event dispatcher. And an instant of the DB. Now, I create my entity. I commit this. And a dispatcher event. That's user created. With the data. And I will dispatch another event to create the relationship between permissions and users. That is my permission user related. Okay. Could be a broker. So, I could have two different event components. List them the same event using a broker. But I'm dispatching two events. Just to be easy to look what happened. And there is my event component. So, look at this. The user queue, the domain, your dispatch user created. And now I go into show the component. The component going to list them the user created event. And the get this stuff, create the data and normalize the data on my MongoDB. The other stuff is I going to get my permissions user related. And create a new structure. Look if my permission was created or not. If not, I go into create one. If it was created, I will just append this user structure on the permission that's existing on my DB. So, in this event, on this event, I'm optimizing the data. And why? Because I removed the possibility to use joins. Because all my data was prepared to be retrieved with just one ID. That is the admin ID. Or the user, the permission ID, sorry. And now the query stack. The query stack, there are just end points using RPC to communicate with my API. The first end point gets the information from the MongoDB. The second end point gets paginated information about users. And my get user permissions by permissions is exactly that going to find on the flat query. And if you take a look, is the same query, the same style of query that I'm using to get a user by ID. So it's very easy. It's not expensive this search through my database. So let's see if my containers are not running. Oh, it's fine. And let's start to consume to send the data. So first, I go into get the info. There's nothing. No users. And now, I go into insert the first user. That's me. It's just a simple test. And this user is another main. Okay. Sent it. There is, he was accepted. Okay. I don't know what happened. And there is a location with my data. Okay. And now, if I find here, there is my user. Okay. I go into create another two users. The other one is Vinicius. That's me again. And it's another main. Was accepted. And now, I go into create the Vinicius. But now, as a user, I don't remember if Vinicius was accepted. Let's see this was too fast to me. No, it's was not the last. Now, so if I find here, there are three users. Admin, admin and user. But I have the user description, but not the description user. So now, I go into find just my users that the permission is admin. And there is my query using CQRS. So my data was moved to my query stack. And now, there is the admin permission with the description. And all the users that are an admin. And then the query, there is no joins. It's a flat query. So now, I go into find my user. And there is the other user. That's just a user. The usability is the same as the normal application. So to my user, it's not so different. And if you look at this, okay, it's the same that I have been using in my life. But the main point is now, let's come back to this. If my normalize the B, fall on down, it's broken for some motivation or lock it, it's broken for some reason. I don't stop at my query stack. And my users will consume the data. And if my query stack is over, I could write in stuff. Obviously, the issue is it's just a user service. It's not so critical. But thinking due payment. You could receive a payment, but not retrieving the report about the payment. But you are selling stuff yet. It's important, I think so. And once in another job that I have, the disk of the normalize the B broke. And we maintained the application running. It was like a monkey test. We maintained the application running because all the writing process kept stopped on the queue. And it was a storage in the queue. When we restarted the B using the slave, we could reproduce all the stuff on the the B. And we don't lost the data. And we don't lose the data. We don't lose the data. But it was just a moment that the normalize the B doesn't receive the data. And it is amazing. It's very scalable and maintainable and obviously make your application stable. So, and it's simple. Simple. It's not so hard. So, common mistakes. And for common mistakes, there is a Jar Jar Binks. It's a common mistake. Jar Jar Binks is a common mistake. Okay. Yeah, Jar Jar Binks, thank you. So, but it's not the guy in the new movie. I don't know why Benicio del Toro did the last Star Wars was terrible. Rose character. Rose and Jar Jar Binks. I don't know. I don't know why Benicio del Toro did the last Star Wars was terrible. Rose character. Rose and Jar Jar Binks. I don't know. Jar Binks eat some insects. I don't know. Some bugs. So, CQRS and event sourcing must be applied together. It's not true. It's a common mistake. There is an example that I'm just using CQRS. They have different proposals and they work very well together like Han Solo and Chewbacca. But they have different proposals. One is to improve performance and scalability and stability. And another one is to create a streaming history about your data. So, if you're using event sourcing, you could reproduce the data in a moment of the time and to know what happened. So, CQRS going to improve your stability and performance and make a better application for you. So, CQRS requires eventual consistency. Eventual consistency is the most common usage. It's the most common scenario in CQRS. But if you try to use the first option of synchronization that I shown, it's not eventual consistency. It's not totally eventual consistency. Try to be fast. But it's not mandatory. Eventual consistency in CQRS. CQRS depends on queues and message brokers. It's a good practice, but not mandatory. So, you could use CQRS trying to trigger at some events or using logs from your data like MySQL logs or something like this. There are many stages that you could use. I like to use queues and message brokers because I think that's easy to create an intervention or to monitor it. CQRS is easy. It's not easy. And why? There are more things to monitor. There are 2DBS to take care. There are many stuff in your stack that isn't in a normal application, in the normal architecture that we look at early. So, CQRS is not easy to implement, but not so complex as we think. You know, if go the tools, you could have a good implementation. CQRS is architecture. No, it's not architecture. It's a pattern inside your architecture. So, it's a good pattern that is cross platform. It's not for Java or Python or for Go or doesn't matter. It's for everyone could apply CQRS as a pattern. It's not an architecture. And my English teacher told me she's from Dublin and told me that it's very funny. I don't know. CQRS is the best thing since the slice of bread. And she told me, oh, it's so funny. This is slice of bread. So, Sarah, thank you by the English class. I'm bad. And again, there's my book. If you would like to learn something more than CQRS or other patterns, there is an interesting pattern that I documented that the caching first is interesting and another pattern is internal for service and communication patterns. It's very steeper than lunch here and the dinner. So, they book, obviously. And there's a link. Please give milk for my kids. I don't have kids, but yeah, my cats. And may the CQRS be with you. And, okay. Thank you. So, any questions? Please come up here. So, I have a question. Okay. Yeah. So, I have a question. I came in slightly late, so I probably missed it, which is my bad. I'm sorry. And maybe missed the very introduction. And also it's quite new to me. So, I'd like to clarify my understanding. So, what I glean from is that you use two databases. You have your normal normalised database, which is your canonicalised data store and you have an unnormalised database, which is specifically optimised for the queries that you need. So, the straight queries can go to the denormalised database and that provides the primary advantage of the pattern you are advocating. Did I get that right? If I understand your question, yes. My idea is create the CQRS stack responsible just to retrieve the data. So, should be the most optimised as possible. And you could apply cache and all the stuff over this stack. I don't apply to make the example because I would like to make it simple to see. But you could take care of this CQRS stack, this CQRS DB, like all the orders DB, but all the source of through the DB. But the main idea is optimise this segment of your stack as possible. And does this mean the way you have schema changes, you have to apply migrations to, or you have to apply migrations to both databases, where you have new queries, you have to generate a whole new set of data into your second database. Sure. My entities are different on both the Bs. So, my entities, my migrations, it's another stuff, okay? I'm doing this. Some people just try to reflect the same entities. But it's like presuming flat queries is not mandatory to use flat queries. If you try to use flat queries, it's, I see that you should, maybe you should create a new entities, specifically for the CQRS stack. It was a really interesting talk and I enjoyed it and learned from it. Thank you. Okay. I basically went for the same. So, when you are going into the right part that you need to scale and you say it in the start of the talk, how are you actually going to scale? So, you are going to have different great instances with different great databases with different schemas or how is the approach for that? For the command part. To the command part, the main idea is command normally is thinking, I will use a practical example. MongoDB in the version two. To put something in MongoDB in the version two, block the read. Okay. In the version two. Not more in the version three. But maybe for your business, it's interesting to use the Mongo engine. So, using CQRS, you could totally divide this. The simple separation of stacks improves performance because now the writing process want to lock the credit process. The scalability using master's lives and different instances and this kind of things is practically the same. The main goal of the pattern is segregated responsibilities to make this more resilient and improve performance to don't make that one operation lock the other. It's the main idea. But the instance control of the bees and this kind of stuff is the same approach. So, the right improvement. So, how are you actually going to scale the right part? That's what I mean. So, you are going to queue and you want to deal with the queue that if it's delayed, the queue will be taking or? You could apply charging as an example that will be very optimized and it's not so optimized in some engines for CQRS stack. Because what happened with some engines using charging for DB? You have an instance that's responsible to administrate all the other DBs that comes, is going to write because that's more idle will get the request and write on DB. But to find maybe it's not so interesting because you're going to receive the request by the same charging and that should find in various the data why all this data was not propagated for all the charging. And in using CQRS, it's not an issue. And why? Because you are not interesting to use this collected data from the charging because the charging is just a source of true. It's improved performance on the writing segment. And your data is streamed on the Kafka or Web to MQ or Active MQ, and it was right in the CQRS stack that's responsible to retrieve the data. So that could have another approach to scaleability different than charging. And it's just an example about, oh, you could use charging, you could use master slave decide, you could use all the stuff that is fast to read but it's slowly to get data. And this kind of approach is not more an issue for your business requires to retrieve too much search. Okay. Thank you. Hi. When you were talking about the different strategies to synchronize the two stacks, you talked about the synchronize, the event basis, that it's the one that you explained and then you talk about the, if I understand good, the query stack ask for an update when he knows that it's outdated, it's how he knows that it's outdated. There are some approach to use this. It's the more harder to apply. It's the hard way to apply. And it's very, usually the people create like a semaphore in the streaming too, like on the streaming, you put the semaphore in the Kafka and okay, I'm very outdated from this because the data stream it's there or it's full and I'm going to get the information from the common stack. And there are the logs of the DB that you could consume in this and the check. Okay. My DB logs are very full. I don't, I move in DB logs from different segments of your server and okay, there is, it's full of logs and I should consume these logs to create my query, to improve my query stack. There are two different approach. One is that's more common. Okay. Once it's looking the bus and to see if there is a sign out to consume the data. And another one is looking the DB logs that it was, you reserve the specific part. And a very common approach is using like a JVM separation that's the Eden and the old part of DB logs. And when you consume the data, you move the Eden to the old part of the logs. And if the Eden is full, it's time to get the data again. And the logs is optimized to use to element, to bring the sufficient information to register on the query stack. Was clear or was, yeah, we could talk, it's hard, we could talk and more common. You'll be interesting. More questions? Okay. Thanks for the talk. I really enjoyed it. It seems to me that when writing to say the local flat database or the MongoDB, whatever it is, your data predominantly comes from the events, at least in this example. However, when you start a new application running, a new service, presumably in other scenarios, you need to be able to read the data from the relational database that stores the chronicle representation. And it seems to me that there's some complexity there in the sense that you need to be able to write to the local database using two different sources of information. You need to be able to have the logic to do the right space on events or do the right space on the relational database. I was wondering if you find that's a problem for you or how you manage that complexity or those two different kind of pieces of logic in your implementations? Yes. It's one of the drawbacks using CQRS. Mainly, if you want to create specialized queries, if you just want to replicate and segregate the search and the find and the right process, it's okay. It's not a consequence. But if you want to create flat queries, it will be a consequence. You will have the two different... I'm going to show you something here. If you look, my model, specifically for this business, I'm using an user and there is the... it's my postgres, okay, two tables. And there is a document for the user that's going to get the user information, just user. And I create a struct to create a meta document here. So I have different entities and I have different logics and it will be a normal scenario inside CQRS if you try to create flat queries. The mistake that you should take care of is don't split the domain rules between the event component and the domain. So it's a normal mistake. Here on my domain, I prepare the data to be consumed by my event component, okay, all the data. I'm dispatching two events. That's not a good practice, but I'm dispatching just to show the stuff. But it's very common to see something like this. Oh, I would like to create a relationship between permissions and users. And I don't want to have both entities being consumed in the same domain. So it's like consumed two repositories in the same domain. And the people move the second part to here. And it's a real mistake because you start to split the domain. And it's a mistake. But two different entities, two different logics, one specialized to write and another one specialized to read is exactly what CQRS means. Okay. Thank you again. And so enjoy the lunch. Thank you. I'm able to answer you. Thank you.