Hey, good morning, everybody. Lee Lowell here, smartoptionseller.com. Hi, I'm down here in a little window down here. How's everyone doing today? Today's October 10, 2020, Saturday. Hey, listen, if you have an interest in selling covered call options, stick around because that's what we're gonna be talking about today, free options information. If you have at least 100 shares of stock in your account and you're not doing anything with them, then you may be leaving money on the table. I'm going to show you how you could be generating some current income just from the mere fact that you have shares of stock in your account. So stick around for that. So what are we doing today? Well, we have our Saturday synopsis where we look at the chart, see what happened over the last week's worth of trading and take a look forward to see what may happen in the week coming up. So let's dive right in. We take a look at the SPY exchange traded fund. Exchange traded fund for the S&P 500, extremely liquid. It's a good barometer of the overall market. So SPY had a huge breakout this week, had a nice up move this week. At the end of last week we were talking, it was just sitting on the 50 day moving average line right here. I always talk about the moving averages on my charts. I've got the blue 20 day, the red 50 day and this orange 200 day moving average. It could be green line, I'm not really sure. Anyway, so we always talk about how we want to see the patterns of the stock or the market itself. These are the one day is one day's worth of trading. These bars right here, each bar is one day's worth of trading. So we always like to see a bounce off the 50 day or the 20 day moving average if we're bullish. If you're bearish, of course, you want to see the market going down. We're talking about bullish because we are put option sellers here at the smart option seller. So we like bullish strategies. So the market had been sitting right on the 50 day moving average to end last week. And I had mentioned that if all things were going well with President Trump, because he was diagnosed with the coronavirus. So it turns out he was feeling pretty good this week. So the market was going to take off on that good information. And that's exactly what it did this week, bounced nicely off the 50 day moving average and had a great week ended on highs for the week, getting pretty close to moving back up to these all time highs. So path of lease resistance once again is higher at this point. The SAP 500 has made a nice comeback from this down move it had just powered back higher. So we had this sell off, which was getting the fraught taken out of the market, people taking some profits and the market just wants to keep going higher. There's really nothing from holding it back at this point. We know all the central banks around the world are willing to step in. The US government is trying to pass another stimulus package to help out individuals and businesses. So things are looking good. There's support now under the market. The 50 day moving average is going to act as support now. So looking strong, looking very good. Let's take a look at the NASDAQ. See how that did as well. Also, same thing, had a nice move up this week, bounced right off the 50 day moving average, looking strong ended on the highs of the day, on the highs of the day, this one day bar right here, a little dash on the right side of the bars where the market closed. Very important to see where the market closed. So we closed right on the highs, looking to take out the all-time highs. So that's going to be a little bit more effort, maybe over the next couple of weeks, I can see us taking out the all-time highs. Let's look at the Dow Jones industrial average. Same thing, had a great week, looking good. All the indexes had the same kind of pattern where it was bouncing right off the 50 day moving average, had gone down, moved back up above both 20 day and 50 day, and now we've got great support at the 50 day looking strong. I like how this market's looking for next week. The only way I can see this going down is some major catastrophe, which I don't see coming. So I'm looking at the market to remain strong, to keep going up, and the Dow can probably take out this high here. Still has a little ways to go before the all-time highs that we saw back here, but the market looks good. I'm really enthusiastic about being long here. So things look good for the market. Let's take a look at some individual stocks, making note this week. One that we always look at, of course, is Apple. Everybody's favorite Apple. I had mentioned last week that Apple, two weeks ago, had closed above the 50 day moving average, and that as long as it could stay above that, it could help pull the market up. So you can see the 50 day moving average line is right here. And Apple, all this past week was just hugging the 50 day moving average line. And then yesterday, Friday, October 9th, finished on the highs of the day above the 50 day moving average. This is a nice uptrending pattern here. The moving averages are uptrending. The 20 days starting, trying to curl back up again. See this little curl right here. I could only see Apple starting to move back up higher. Now we had this massive blast off higher with Apple. Here was the earnings they had, their last earnings, and they announced the stocks, but so there's all this enthusiasm, just pulled it up higher, and then all the air got let out of it. So we had the down move profit taking. Now it's getting its mojo back. You know, it's finding its support right here on the 50 day moving average. At this point, I think all the people that needed to sell have gotten out of the market and now the longs could come back in. So I could only see Apple starting to get back higher here.  Once it starts to break out, the momentum's gonna take it in the same, in that same direction where it breaks out. So, you know, I can actually even draw little, some lines here. So a little bit of a triangle pattern here. Market looking to get at bust out of it. Let me make this a little bit larger so everyone could see what I'm looking at. I wanna show you some of these patterns that I see on the charts so you can see exactly what I'm looking at and thinking. Okay, so we have this little triangle pattern here, okay? And once it starts to break out and it will most likely continue in the same direction. So at this point, I can only see Apple starting to move back to take out all-time highs, just under $140 a share. So this is a good consolidation pattern. Gave people a lot of time to realize, okay, do I wanna get long or do I wanna stay out? And I'm thinking, it's time to get long. That's what I see with Apple. What else do we have? So we wanna look at, I wanna show you some other price patterns that I've been seeing. Intel Corp. Now we know Intel Corp had their last earnings, dropped it down major from $60 a share all the way down to the high 40s. AMD, which we'll look at in a second has been stealing a lot of Intel's thunder over the last couple years. AMD has really come on strong as part of a, as the king in the semiconductor chip market, chips that they put in computers. AMD's really taken over some good market share from Intel. But as far as price patterns go, we see this W pattern that Intel has been making over the last two months or so. This could be a very powerful bullish pattern as long as Intel gets above the resistance line, which is really the middle of the W. And just Thursday and Friday this week, it popped out above the resistance line. Yesterday, Friday closed just above it, had made some new highs here on this bar, but closed back down near the lows. So I'm thinking if Intel can remain on an upward trajectory next week, this thing's gonna go and it's probably going to want to go back up to the $60 level where we had this big gap here. Gap is when the stock closes one day and then opens up the next day well away from it. So we have what's called this gap right here. And markets like to refill the gaps sometime in the future. So if Intel could find its footing, it's gonna go and it's gonna fill in this gap here by moving all the way back up to 60. So keep an eye on Intel. I think we've got a bullish break out there. What else do we have? Let's look at Oracle's another price pattern that I saw on the charts. It's making this bullish flag pattern. What happens here is that the ranges start to get tighter and tighter so it's storing up all this energy for a move higher or lower out of the triangle. And just this past week, here we go, Oracle, moving out bullishly out of the pattern so I can only see Oracle continuing to move higher over the foreseeable future. So keep an eye on Oracle. Couple others, Procter and Gamble. It's another stock that I like. It's also making a bullish move. We've got this, had some resistance here, has this uptrending movement. And as soon as it gets through the resistance, it's on its way. Well, yesterday, Friday, October 9th, blasted out of the pattern here. And as long as it could keep a couple of days worth of trading above this resistance line, then all I can see is more upward movement for Procter and Gamble. And you'll see the same pattern in Lowe's. This is the home department, the home goods store Lowe's. People go buy everything they need to fix up their homes, build homes, all that good stuff. Lowe's making the same patterns we just saw on Procter and Gamble having this nice uptrend. It's got the resistance line here, broke out nicely yesterday, Friday. Next couple of days, we'll be telling, as long as it can stay above the resistance line, Lowe's is gonna keep going. Nice bullish pattern for Lowe's. So what else do we see? Let's go back to some of the biggies. Let's take a look at Amazon because Amazon had been well below its 50 day moving average and it turned around recently. We had this downtrend channel off the highs and now we've got this uptrending channel convincingly moved above the 50 day moving average yesterday, October 9th, closed right on the highs. Amazon was up another $100 a share yesterday. So good things to back above all the moving averages, 200 days sloping up, 50 day sloping up, 20 day trying to curl. So this is, Amazon's looking strong here. We like that. What else we got? We can look at Microsoft, there's another big one. These are the ones that have been pulling the market up. Same thing, Microsoft had been below the 50 day moving average for a while and yesterday, October 9th, convincingly popped above it. I see strong things coming from Microsoft. As long as we don't have any major news events to derail the market, the momentum is going to keep things on the upside. Lastly, let's take a look at Tesla. We've been looking a lot at Tesla lately because it's been such a strong stock. Now let me draw this price pattern that I'm seeing. So you all can see what I'm seeing. It's another triangle pattern that it's storing up all this energy waiting to blast out. And I can see in the next couple days, Tesla's gonna figure out which way it wants to move. So let's draw the pattern here so we can all be on the same page, see what I'm seeing. Here we go, triangle pattern. Once again, bullish triangle pattern because it's coming from the downside. It's moving upwards. So we're just waiting to see which way it's gonna move out of the triangle up or down. My bet is on the upside because everyone loves Tesla bullish stock. So the momentum I'm thinking is going to carry it out of the triangle to the upside. I can see $500 in Tesla sites over the next couple weeks. If not sooner, Tesla could go $100 a share at a clip. So here we go, $500 next stopping point for Tesla in my opinion. So there you go, there is some assessment of what's happening in some stocks and the market in general. Let's go back to the S&P 500 one more time, get some thoughts for next week. Things are looking good. Like I said, powered above 50 day moving average, looking strong, 20 days starting to curl up. That means it's probably gonna wanna start moving higher again, we like moving averages trending upwards. We don't wanna see moving averages sloping downwards. That means a bearish type of market. We concentrate on bullish markets because we are put option sellers and put option credit spread sellers. That means we like bullish markets. S&P 500 looking strong. I can only see this thing going up, trying to challenge it's all time high again. As long as there isn't any major catastrophe news out there in the world that I think the market's momentum keeps going up. So I like the long side here. All right, so that's it for your Saturday synopsis of the market. And so today we're gonna be talking about how to generate some income from the stocks that may be sitting idle in your account. We're going to be talking about selling covered call options. Now you might be asking, what are covered calls? What is that? Lee, tell me about what is that? Covered call options are a way to, if you have at least 100 shares of stock in your account, you can sell what's called a covered call option. That means you're going to sell a call option against those shares that you own. And by doing so, whenever you sell an option, someone pays you money for it. They pay the premium. That's the entry fee for the option buyer. The call option buyer will pay you a fee to potentially take your shares away from you sometime in the future at a much higher price than where you once bought those shares. So if you're, let's just say you bought some stock shares at 100 and now they're at 120. Well, now you can sell a call option with say $130 strike price to somebody else that will give you money today in order for them to take away your shares from you at $130. So that's a price point where you can consider selling out your shares if you want to and someone will pay you money to do that. So let's take a look at our cheat sheet. So we can see what we're talking about. I always have a cheat sheet that's called out. Tips for selling covered call options. Now, once again, you have to have at least 100 shares of stock in your account. So for every 100 shares that you own, you can sell one call option contract. Now, you want to pick a strike price of that call option that meets your potential preferred selling point. So let's say you want to take a profit on your shares at some point and it's smart to always take a profit on your shares because you never know when the market could drop and you don't want to give away all the gains that you've built up. So pick a point where you'd be comfortable selling those shares of stock. Okay, and that's going to coincide with the strike price that you choose. Now, you can also have to look at the expiration dates because every expiration date will offer a different price for those options. The longer the expiration date, the more money you will get, okay? The more time equals more money. So you have to go through the option chains which we'll do in a second and you look to see what these options are trading for.  And you can also check the probabilities of the chance of the stock moving from point A to point B. So you'll know ahead of time what are the chances that you may have to sell your shares to somebody else. So it's always important to check the probabilities and we'll go over that as well. And one of the very most important things is this point right here, point number five, is that you want to make sure that you sell a call option strike that'll take you out at least above where you originally bought into the share. So you want to make sure you're selling above your cost basis, right? So let's just say you bought the shares at 100 and now they've come down to about $80 a share. So you're looking at a paper loss. Well, you don't want to sell the $90 call options because you'll end up selling your shares at 90 and your cost basis at 100. So they'll be locking in a guaranteed loss. You don't want to do that and I'll show you a way to make sure that you don't do that. And lastly, if the stock starts running up higher on you and you're like, oh my God, I don't want to sell my shares anymore, you could always unwind the trade. You can always buy the call option back. So let's take a look at Apple and use Apple as an example here. We've looked at Apple, it closed yesterday, right under $117 a share. So there's a couple of ways you can sell covered calls. So you can actually have shares of stock that you already had in your account for a long period of time that we've had forever, or you can actually go out and buy the shares today and then sell a covered call at the same time. That's called a buy right. You're buying the stock and then you're writing or selling the call option. That's all done at the same time and the same transaction. What I want to talk about today is how you can do it with stocks that you've had in your account for a long period of time that you bought those shares long ago, but you've never sold covered calls before. So I want to show you how you can do that. So let's take a look at our option chain from Interactive Brokers. Interactive Brokers is a broker that I use to trade and get some quotes. So this is an option chain for Apple. We've got call options on the left, put options on the right, and I'm gonna move myself over here a little bit so we can look at the call options. Now let's just say you've purchased shares of Apple at $100 a share recently and you've got a nice, well here at the last trade of the day is $118 a share. This must have been in the aftermarket. So Apple, you bought Apple at $100 a share. You got about $17 or $18 worth of profit locked in and you're thinking, you know what? At some point I think I might want to sell my shares of Apple, but I don't want to sell it at its current price. I want to sell it at a much higher price. So where can I sell some of these covered calls? So let's say you have 100 shares, which means you can sell one call option contract of Apple. And here we have expiration dates for Apple. So let's take a look at the December expiration date. Now this is gonna be entirely up to you which expiration date you choose. You're gonna look to see what the strike prices are paying and you can go through the expiration dates and see how much money you can get. Now let's take a look at December expiration date, 69 days from now. And you potentially want to sell your shares of Apple, let's say for $150 a share. So it's currently at $118. It's got another $32 of upside potential. So you go down to strike price, calm here, here's the $150s. Scroll over to the last bid ask for the day yesterday at October 9th. Went out at $1, three bid at $1, five. So you can probably sell those options for $1, four per contract. You can sell one contract that'll bring in $104 to your account today. Now what you do, if you do sell that, you get $104 immediately, current income, right off the bat. Now what you've done is you obligated yourself to potentially sell your 100 shares of Apple at $150 a share by December, 18, 2020. So what that means is that if Apple goes all the way up to $150 from its current price of $118, you're on the hook to sell your shares for $150. Would that be a bad thing? Well, you bought them at $100 a while ago. Now you get to sell them at $150. That's a $50 move of price appreciation. That's a $5,000 gain for you, not so bad. Plus you get to keep the $104. So you make $5,104. Now, if you want to see what the January options are paying for those contracts, you get another month, now it's 97 days out in time. Look at those same $150 call options. Now you can get roughly, somewhere between $185, $190 per contract. Let's just say you sell it somewhere in between $187, $187 contract, you'll get $187 this time. So now you're still on the hook to potentially sell your shares at $150 until January, but now someone's paid you $187 instead. Now let's just look at one more expiration, the March, 2021. Let's move up 150 strike right here. And all those things are paying a pretty penny, $367 you can get. So you can see the more time you give, the more money you will get. So you have to choose the expiration date. You choose the strike price of your potential sell point and you will be paid for that obligation. So if you bought Apple at 100, you're looking to sell it at 150, don't just sit there with your account waiting for Apple to go up. Sell yourself a call option and someone will pay you money. Now remember, this is not a real recommendation. This is just example only, no real investment advice here. So these are just examples. So you have to decide, okay, where am I willing to potentially sell my shares? And I say potentially because you never know if Apple's gonna move from point A to point B. If Apple never goes up to 150, the trade is over. You get to keep your $367 and guess what? Now you can sell another covered call for another expiration date and collect yourself another $300 or whatever you choose. So as the year goes on, you can continuously sell these covered call options, collecting this money and if the stock never goes from point A to point B, you just keep rolling those covered calls and you just keep collecting this cash over and over again.  Now, so two things, number one, let's go and check the probabilities here. Hang on for one second. Okay, I'm back here. So I wanted to bring up the probability calculator. So one of the things you can do to help you decide, well, what strike price should I choose? How do I know where Apple's gonna go? I don't know if it's gonna go up to 150, maybe it'll go up to 170 or maybe it'll stay at 110, who knows? So you can always check the probability calculator to see what the chances are of the stock moving from point A to point B. Now, here in the probability calculator, we put in the current price of 117 and we've used the January expiration date, which is 97 days in the future. Future volatility, 50%, this is a percentage number. You just type in the number. Apple's volatility, you can always check the numbers at ivolatility.com. So you go and put in 50% here and you wanna know what the chances are of Apple going from 117 all the way up to 150. This is our target boxes. You put the same number in both target boxes, 150. Click on go and here's what it's telling you. It's telling you there's an 83 and a quarter percent chance that Apple will stay below 150. Conversely, over here, there's 16.75% chance that Apple will move above 150 by January 97 days. So you have to decide, okay, so if I don't, am I comfortable selling Apple at 150? If so, well, there's only a 16.75% chance that Apple will move up that bar. So there's a pretty decent chance that you won't have to sell out your shares, okay? So use the probability calculator, take a look at the numbers, change the expiration dates here so you can see what the chances are of you having to potentially sell your shares out in the future. Now, we wanna talk about very important here. The one thing that I had mentioned before is that you wanna make sure you don't sell a strike price that'll take you out of the trade below where you got in because then you'll possibly be selling for a loss. Let's just say, let's go back to our option chain here and let's just say you bought Apple for $130 a share. Like recently, when Apple made a high, you got in, you bought it for $130 a share and now it's trading at 118. So you're currently underwater. You got about a $12 loss going on here. And let's just say you wanted to sell the $110 call option in December that's paying out $12.20 per contract. So someone's gonna give you $1200 in order to sell your shares at 100 and hang on, let's use a better example here. So you bought it at 130, it's 118, you're underwater. So let's just say you wanted to choose $120 call option. Okay, so now you're gonna put in an obligation to sell the shares at 120 and someone will give you $715 for that contract. Okay, you're thinking, wow, $715, that's great. I'm gonna get $715. Well, if Apple moves above $120 a share, you're gonna have to sell your shares at 120. You bought them at 130, now you're selling at 120, you're $10 in the hole, but someone gave you $700. So your effective sell price is you take the strike price and add it to the money you receive. That's $127.15 is your sell price. Well, if you bought it at 130 and you're now selling it at a net price of 127.15, you're gonna lose money.  So if you bought the shares at 130, it's at 118 now, yes, you're underwater. But you need to make sure you sell a strike price that will take you out of the trade above your cost basis. At a minimum, you can sell the 125 calls that are paying about $5.25 a contract. So you add 525 to the 125. So that'll take you out of the trade at $130.25. You bought it at 130, you sell this one, you'll get out at 130 and a quarter. So you make 25 cents overall. So you need to make sure, whatever your cost basis is in this example, 130, you need to make sure you sell one of these strike prices that'll, if you have to end up selling your shares, it'll take you out above your cost basis, very important there. Make sure you understand that. And lastly, if Apple starts in this example, if Apple starts running higher and you've sold that 150 call option and now Apple's all the way at 170, you're like, it's at 170. I don't wanna sell it for 150, what do I do? Well, you could always buy back the call option. You're not stuck in that trade forever. It's not a sentence where you have to stain it. You made your bed and you have to line it. Now, no, you could always get out of the trade. You can always buy that call option back. Now you may end up buying the call option back for a price higher than what you originally sold it for. So you may be locking in a loss on the call option itself, but you're making up that difference in the price appreciation you're getting from the movement in the stock. So if you bought Apple at 100 and now it's at 170, you've got $70 of price appreciation. If you sold the 150 call option at whatever price and now you have to buy it back. Yeah, you may take a loss on the call option, but it's being overtaken by the profit you make on the price appreciation of the shares of the stock. So there you go. Let's take a look here real quick. Let's take a look real quick. I wanna mention something to everybody. I will be giving a free online presentation at the VectorVest Financial Freedom Summit on October 21st, going a little bit more in depth in this covered call strategy. So if you're interested in signing up and listening to myself and many others who will be speaking about different trading strategies, sign up for free at the VectorVest Financial Freedom Summit from October 19th to the 21st, right here. You can register. What I'm gonna do is I'm gonna put a link in the description below this video. Read the description of the video. I'll have some links in there. One of them will be to sign up for the VectorVest Summit. So check the links down there. Also, in this YouTube video that you're watching, don't forget to subscribe. In the bottom right-hand corner of this video is the red subscribe button. Don't forget to subscribe so you won't miss any videos from me. Don't forget, please, give me a thumbs up if you like this video. Give me a comment below. Ask me a question in the comments. You can also email me with your questions. If you want, let's go to our website, smartopsandsell.com. The probability calculator. People always ask me where do you get the probability calculator from? Go on to our website. Go over to the More tab here. Click on Helpful Links, and the probability calculator is the first one right here. You can use that for free. Lastly, putselling basics. Make sure you download our free putselling basics guide. Talks all about putoptionselling. That's what we do here at the smartoptionseller. Free guide can learn about a great strategy. Lastly, services tab right here. We have two newsletters, smartoptionseller and vertical spread trader, both about putoptionselling. And lastly, our one-on-one coaching. We've gotten a lot of great students coming in. If you need a little help learning about options trading, consider our one-on-one coaching. People are finding it very helpful. Okay, so that's it for me today. I hope this has been helpful. I want to hope everyone has a great weekend and a great trading week next week. I will see everyone next weekend. So this is Lilo signing off.


I got some more folks filing in. So in the interest of time, let's, yes, let's start. We only have 30 minutes. This topic can go way beyond, it can be days. But let's start. So, hi, my name is Alia Borker. I'm a software engineer and I've been a developer for 20 years. And I'm currently a design authority for Feast platform in JPMorgan Chase. And in our asset wealth management line of business. And I worked during the course of the years. I've worked on many enterprise systems, monolithic apps, and also service-oriented architecture applications and industries such as telecommunications, media, and now financial industry for more than five years. So in the last three years, I've moved to microservices. And I've been creating microservices and deploying to a custom pivotal cloud foundry platform called Gaia. We always have to give cool names. It's some Greek goddess in JPMorgan Chase. And we're having a lot of fun with it. But just out of interest, I want to know how many of us here have worked with enterprise systems versus traditional web apps? OK, great. So it's more than 50%. That's great. So the reason I'm here is to talk about data integrity concerns in enterprise systems, which still tend to be a bit different and more complicated than web apps such as even Netflix. So that's why I'm here. So let me start. So I posed this question. Microservices architecture means that you have zero concerns for data consistency now, right? Is that true? Not. Not true. And that's what I'm going to be focused on. In the last three or four years, I've seen new adopters of microservices struggle to put enough time and focus and upfront design for managing the data integrity in distributed systems. And there's a rush to move to microservices infrastructure. And there are many very, very good reasons of moving to the cloud infrastructure. But we still have to put in due process and thought into how do we manage data integrity, right? All the concerns of distributed systems of yesterday are still present. And they still need a solution. So that's why I want to focus on bringing in a little bit more clarity and refocus on this need, which really hasn't gone away. So through in the slide to show what our monolithic and service-oriented architecture systems used to look like, so the shapes can represent some components. So you have, with a monolithic application, you would have all the components always being deployed as a unit as one application instance in different environments on a predefined infrastructure. And the predefined infrastructure didn't go away with service-oriented architecture, also known as distributed components architecture. Now you had service providers coming in and developing individual services called components. So we also like to give new names in the industry, right? So we began with components. Everyone was components, the programming mad for a while. And then now we're all just talking about services. It's exciting. It's fun. But we kind of have to remember some of the same concepts still apply. So we were components, and now we are service-oriented. We used to call us a service-oriented architecture, but there was a lot of tight coupling still and all predefined infrastructure. And some of the usual pain points, as you can imagine, in monolithic applications and all of you who've worked with enterprise applications already, were time to market and the LENDY, which was caused because of the LENDY regression test cycle and the user acceptance test cycle. But every single small, minute change that had to occur in any component. And then, lo and behold, even after a LENDY regression test and user testing process, you could still have catastrophic failures. I should not have done that. I'm almost blinded, but hey. Because one specific use case was not sufficiently tested. Now, how many of you have faced that problem?  OK, great. We're not the only ones then. JP Morgan is not doing anything wrong, but you know. Excuse me. So the pain points of monolithic applications didn't quite go away with service-oriented architecture either. We still had LENDY regression test cycles and LENDY user acceptance cycle, and also, again, failures and after production releases. So let's see what's happening. So when we talk about transactions, I wanted to revisit what was how were transactions handled in legacy systems. And before we even do that, I should level-set. What is a transaction? We should have a basic definition of transaction that I want to build upon. So I'll say the most basic definition of transaction is a sequence of changes, a sequence of events that occur as a single operation. So if you let that sink in a bit, you could have a set of changes. They all have to go in, so it's all or nothing. Otherwise, in case of a single point of failure, the entire set would be reverted back to its original state. So that is the basic definition of transaction. So in purple, if you follow this diagram, I've tried to show how would a monolithic application manage transactions. We used to all have this great, that big drum that you see there was a big helper. These were the RDBMS databases, the articles and the SQL servers, and really the Trojan horse, and not the Trojan horse, but really the workhorses in the monolithic application development world. And that provided us with a way of leveraging a gatekeeper, which was our database. And the database would handle the consistency of transactional flows by ensuring that the set of changes either went in all or none went in, and there was a rollback implemented. So the databases were key to managing consistency with monolithic application, a shared database. So if you have, for example, and customer come in in a simple online bookselling application, not Amazon, way more complicated, a lot more features. So a simple rudimentary online bookseller application, which is going to, say, for example, allow a user to find a book. Maybe they're interested in Harry Potter, the Order of the Phoenix. I was recently ordering it for my daughter, just fresh in my mind. And say they see a count of 10 books available. And the customer then decides, well, yeah, they're going to buy that book. So they click the Buy button, and they submit the payment information, which makes a call to a payment service. This could be a component within the monolithic application or a distributed component running on another infrastructure provided by a service provider. And either case, the expectation is that if the payment fails for any reason. For example, perhaps the credit card information was invalid. The expiration date was not correctly provided. Then another customer who logs in and searches for Harry Potter, the Order of the Phoenix, should see the original count of 10, and not 9, because the first customer's transaction did not succeed. Hence, the count of books should not decrease. So that is what we mean by data integrity and consistency in a transaction. So we still have to take care of these scenarios with our new paradigm. But I did want to bring in also a retouch on what was to face commit. So with service oriented architecture, we entered into the complicated environment or basically of having service providers having to interact with one another to ensure this consistency across boundaries. So then there were these entities, transaction managers, which then became the gatekeepers. Every transaction manager had a registry of registered resources that participated in specific transactions. In this case, it would be buying a book transaction. And then either synchronously or synchronously, every single change was checked and verified before the entire transaction was succeeded by the transaction management. So the complexity came in, and we still have to manage this cross boundary transactional flow. In the old days, we used to do it with our databases and our DBMS, relational databases, and with transaction managers. But we want to do something better now. All of this diagram that you're seeing up here, all these boxes here are still very tightly coupled and dependent on predefined infrastructure. And for great reasons, the industry has decided that we no longer want to be having to design upfront all our scalability needs of 10 years from now or even three years from now. We want to be able to scale up and down and be fast to market. And so this type of rigid infrastructure which leads to tight coupling, it wasn't working well anyway. So where are we now? We're, so I tried to throw in a little diagram of what our components look like. Now called microservices in the environments of today. So you could have, microservices can be scaled as needed. That's a great benefit of having a microservices architecture. In fact, in JPMorgan Chase as well, depending on the volume and the traffic, we scale our services on demand and we're not, and we're actually on our Gaia platform, we actually pay per instance. So our infrastructure cost is only, is going to be about our on demand and it's not preset. So we do see a benefit and reducing our costs by spinning up infrastructure only when demand requires that a new instance be spun up. So as you can see here, microservices no longer mean that the same set of services will be deployed in one infrastructure environment. You could have a complete mixed bag. This leads to reducing all the dependencies between services and decoupling so that your time to market, your specific service, if you're a service provider, your time to market is not impeded by another service provider's delivery cycles, for example. All right, so we still have transactions. They didn't go away, right? Nope. So we're back to the simple online bookseller service and customers trying to, again, buy the book. Now you see there are even more connection points with microservices architecture. So with our service oriented architecture, we used to have a few more connection points and with microservices we have expanded the number of connection points, right? So the point of failure has increased and we still need to handle the transactional integrity. Again, the counterbooks should not be decremented if payment service has failed. It is a simple example to keep in your mind. And at any point you could have multiple instances of any service running on the cloud. I just like cloudy pictures so I just put everything in a cloud here, but yes. So that's about it. And by the way, transactions are not always user initiated. I'm coming from the enterprise, in my mind, I think of it the most complex data management systems, which is financial systems presently and before then also insurance. And transactions can be initiated by other services as well, right? So you can have an admin, I've shown a user here, but you could have an admin service actually calling in a grooming process, initiating a grooming process, which would be changing the perhaps refreshing items in the books catalog. So the transaction initiation can occur from a user or from other services. And in both cases, data integrity concerns are valid and need to be handled. So I threw in this quote, it seemed epitome. Life is a series of natural and spontaneous changes. Don't resist them that only creates sorrow. Let reality be reality. Let things flow naturally forward in whatever way they like. This is from Lausie, right? And it seemed up to me. I mean, just think, if we can design our new systems that are built with microservices to expect failure at every connection point, then we'll build great systems. We should not hope that there are no failures. We should plan and expect failures in designer systems such that our data needs, our data integrity is going to be maintained regardless of failure at any point. So that's the goal. So keep that in mind. Okay. So in order to walk us through some concepts, I wanted to bring in a simple application with a few simple use cases. And that'll help us walk through some important concepts before we can get to the couple of approaches that I wanna present on how to manage consistency and data integrity needs with microservices applications. Let me also check my time. Okay. So imagine you have a simple tour operator online application, right? Not thinking orbits and Expedia, but we've all used Kayak orbits and Expedia, hopefully. So if you get the general idea, and in such an application at a very basic level, customers should be able to search available tours. Customers should be able to book a tour and an admin can add a tour, right? Simple use cases. So we have simple use cases and this is gonna help me talk about an important aspect which is what is the domain and context here, right? So we need to talk about domain-driven design and bounded context and I'm going to come back to these use cases when I talk about the domain-driven design and bounded context. So I threw in some diagrams here. So when we think about context, we have, for example, the booking tour use case, right? We have a customer trying to book a tour. When a customer is trying to book a tour, they will probably be dealing with the concepts of a tour, vehicle, customer reservation, hotel reservation and hotel. You know, some general conceptual entities you can imagine are into playing and into reacting to produce a, to allow a customer to book themselves on a tour which is offered on November 1st. Maybe this tour is hiking in the Appalachians, right? And on the right-hand side, you see a tour search context, right? In tour search context, you also see the tour conceptual entity. You see hotel and you see tour catalog and top 10 list. But I asked you to think with me here. Tour, in this case, may not mean exactly the same thing and actually it does not mean exactly the same thing as a tour in the booking tour context. Tour for the search tour context could mean that anytime there's a unique name, for example, hiking in the Appalachian, that denotes a unique tour, right? So the dates may not be relevant in the search tour context at all because the search tour context may just be trying to categorize tours by top 10 list, perhaps. Top 10 tours and North America list, if you can think it through like that. Then the tour conceptual entity means different things in different contexts. This is what we mean by bounded context. And when we further expand this idea that your use case flows have a specific context and your entities are relevant within that context, then you design your domain model, which leads to your physical data model creation, right? So let's follow that through, right? So now I'm gonna pick one use case. So instead of the three use cases I had listed, customer searches available to us, customer books a tour and admin ad tours. I'm gonna choose a customer books a tour. So I'm sticking to one bounded context and we still have some decisions to make when you think about domain driven design. There's some options. All right. So you could decide to model your data model, your domain model first, which can then lend itself to data model with a large aggregate model or a small aggregate model. Now the key difference here is that in the large aggregate model, you have a compositional model where the tour is composed of the other entities. The tour is composed of vehicles. Perhaps, you know, there's a boat that is involved in the first leg of the tour and then there's a bus that everyone's going to be boarding and lastly, there could be another boat that brings you back. Perhaps it's a list of vehicles. And then a tour, which is Appalachian hiking in Appalachians on November 1st, could have a list of customers already reserved on that tour. And you could also have a list of hotel reservations for that tour as well. Right? So it's a compositional model. If you notice anyone who remembers UML, it's still, I still use it these days. And as you can see, the black diamond denotes compositional modeling. And on the right hand side, you could also decide to model the domain model as small aggregate model where you have a tour and a vehicle, customer reservation, hotel reservation, all disconnected and only hanging on to a value object called tour ID to make the connection. So I should have also backtracked and talked about exactly what is an aggregate. Right? So if anyone who's not come across aggregate when we talk about domain driven design and aggregate means that there is, it's a cluster of object interrelated objects which are going to be updated or changed for that cluster of objects will always go through one route. So within a cluster of object, one object will be nominated as the aggregate route and that aggregate route will be responsible for making any changes in the entire cluster of objects. So that is what aggregate route means in these diagrams. So as you can imagine, with the large aggregate model, you'll have a few extra blocking scenarios if you think about it. Two customers trying to book in the member first hiking in the Appalachian tour. And with the aggregate route being a tour, then every time there are changes to be made to any part, say a customer decides they wanna switch the hotel reservation or they decide they're gonna add another family member, then the entire cluster of objects is going to be locked and unavailable for updates till the first transaction has completed. Right, so I'm just doing a time check. Right, with the smaller aggregate model, you have less dependencies. You have decoupled your domain model in a way where multiple updates can occur. It's totally kosher because every aggregate route is responsible for the set of changes inside its boundary. Right, but there's more to discuss on this. So again, I tried to just consolidate the pros and cons and I'm gonna bring it back to transaction boundaries. So with a large aggregate model, it's compositional object model and it's familiar to UML users, right, from legacy to present. There's continuity. So that's reassuring sometimes, but it does result in a large number of user transaction failures where, for example, if you have two users logged in and you're gonna see this some more and if someone is hanging on to an old instance of the aggregate, then their request will be rejected if they're trying to update, if someone else wins. So we'll see a little bit more on that. So you have generally poorer user experience with a large aggregate model, but there are good scenarios of using a large aggregate model because it does ensure data integrity, right? If you're going back to your monolithic ways, you do keep everything in one umbrella, one transaction managers, all changes. With a smaller aggregate model, it does reflect the more pure sense of multiple microservices interacting to complete a use case, right? A microservice, by the way, is almost a one-to-one with an aggregate, with an aggregate. So when you think about microservices and domain-driven design, you should automatically equate one aggregate to a microservice. And there are a lot of articles written on this and I've added some links also to the last slide. I believe the slide is available. These slides are available on the schedule, right? So we do improve user transaction success, right? If someone is changing the customer reservations list, then they do not have to necessarily block another customer trying to maybe pick a hotel reservation on the route, right? And, but small aggregates still have to handle cross-transaction boundary communication, right? If you think about it, if you are, and we're gonna see this actually a lot more, let me not jump ahead. So I wanted to get into two design approaches and I wanna present the first approach which is optimistic concurrency with shared databases, which everyone who's worked with enterprise systems in the past should be quite familiar with. So when you have a shared database and you have a large aggregate model, optimistic concurrency still works pretty well because it's the entire paradigm is to allow most updates to go in and only reject updates when there is a evidence of overriding behavior, right? And we'll see this, but I wanna show you a print. What are the two options I want to get into some details on? And the second option is of course, well, eventual consistency across distributed systems. So this is going back to the small aggregate model, right? We said it's purer. It lends itself more to the microservices architecture because one microservice really equates to one aggregate when you look at domain-driven design. And so we cannot rule out eventual consistency across distributed systems where, for example, a booking, a tour booking application really doesn't need to know when a payment application finishes processing a customer's payment. So that would be cross-transactional communication across bounded contexts and we look into that as well. So just to finish up on the optimistic concurrency model, so with optimistic concurrency we get optimistic locking provided by our really, excuse me, shared database and in the tour operator online application how this would work is the tour aggregate which is nominated as the tour route. It would have a version number and each time any change is made to any of its composite entities, the database version would be checked for that tour instance and if the version on the thread making the call is different from the version found in the database then the entire transaction is rejected. So this is the old way of working of ensuring data transaction integrity and if you design a large aggregate with microservices it still works very well. So the pros are of course data consistency, needs are met fully because you are in charge of all or nothing within one microservice, one large microservice that you've designed and it's easier to debug because again all the parts of all related entities are inside one microservice and you have the biggest problem is we haven't shared dependencies across transactional boundaries at all. So all the parts of a tour booking application would kind of have to roll out like a monolith. So this would be the first cut of migrating a monolithic application to microservices architecture and as long as the bounded context is not huge it's still a viable option. So we don't want to throw away optimistic locking and all the benefits that our databases provided unless there's good reason. Some of the good reasons are of course you may have hit an infrastructure wall now maybe you're not able to scale anymore there's just no space left in your database and you must create or bring in a new database server if the minute you bring in a different persistent store you may as well change your design paradigm and think about smaller aggregates in multiple microservices and how to handle data consistency across transactional boundaries. So that brings us to event sourcing paradigm and I'm keeping a time check but I think I'm good. So with event sourcing things become a lot more fun as you know I've been enjoying myself exploring this. So now you have the more freedom to communicate across transactional boundaries, right? So across bounded context your tour booking application has its APIs it has event handlers, data handlers it has its own persistent store it's completely separate from say a payment service, right? You could be on Chase, Pay, Apple Pay any payment service that's being leveraged in an enterprise world you would actually have multiple payment services being leveraged and the user being allowed the access of choosing their payment service and that's how we like things to be we wanna give users choice and we do not want tight coupling on the infrastructure layer. So you see these bubbles, these bubbles are trying to denote context so each microservice, tour booking service, payment service and admin service are running in their own bounded context their own data model and physical data model and domain model as well and all the interactions between these contexts is through a distributed event log. So this is a general paradigm and we're gonna see how this works with our simple online tour booking use case. Right, so before we do that I do wanna talk about one framework which allows us to implement such an event streaming paradigm event sourcing paradigm and that is Kafka. So I become quite a big fan of Kafka recently and Kafka is providing us the key APIs to publish a stream of records to one or more topics and we can also out of box we get a consumer API to subscribe to one or more topics and we're gonna get in a little bit of what these things mean in Kafka and then there's a streams API which kind of think of it as your ETL layer of the olden days where you used to transform data that was coming off of out of different databases or through message calls from other services. So there are many times where you need to transform the data before you can consume it, right? Even if you think about your JSON and your Jersey and Jackson there are always transformational needs even with the REST APIs or any interactions between any systems. So a streams API is now part of Kafka. It became part of Kafka I believe in version 10, 1.10. And then we have also the connector API which is your basic way of connecting to Kafka topics. So this Kafka platform as you can see there's a lot more information of course on it on the Kafka sites as well. Kafka Apache.org. It started off, it was started by LinkedIn and now is under the Apache umbrella. And yes, so Kafka cluster is as I can have multiple producers, multiple consumers, multiple connectors and multiple same processors. It scales really well and provides high availability and performance out of box. It's pretty impressive. Little bit more on the Kafka concepts. Each record gets a sequential ID, a number called the offset produces published data to the topic of their choice and consumers label themselves with the consumer group when each record publisher topic is delivered to one consumer instance within each subscribing user group. And we're gonna come into and touch upon user groups a little bit more, consumer groups, because order with streaming event sourcing applications is pretty important. Order of message consumption is still very important and we need to consider that if we really need to achieve, planning to achieve data consistency. So coming back to a simple tourbooking application, what if we implemented it with Kafka? How would things look? So again, you have your tourbooking service. Perhaps it has an API called make reservation and it has a Kafka stream client with the streaming APIs that come with Kafka. It could be a producer, a registered producer maybe with the label AA with its own name and it could be, there could also be a consumer group A. So it could be consuming messages also meant for tourbooking service. For example, what about acknowledgements from payment service that, hey, yes, I received customer XYZs payment requests and I've successfully processed. So their reservation is good to go. So asynchronous communication between bounded context that's what we're trying to achieve. So payment service could likewise have its own APIs process customer payment. Again, has a Kafka stream client and be registered as a producer and also have a consumer group B that it's participating in. Admin service likewise has its own APIs changed to a route perhaps. The itinerary is changing. Perhaps there was a hurricane and you can no longer dock at a specific Arabian island and you need to be diverted to hopefully not Texas but maybe if you're starting off in Boston, possible. And then you have this concept of topics in Kafka. So you could have the tour application topic, admin topic, payments topic and each a Kafka producer can choose to write to specific topics. So it's a lot of freedom and you can also choose to consume from multiple topics as well. So both ways flexibility. The order of and I should bring the highlighted in important concept of consumer groups. Now, since one instance in a consumer group will get to consume a message that is subscribed on. Generally it's a logical subscriber. For example, tour booking service and it's multiple instances that would make up one specific consumer group. That's pretty important because you do need tour booking service to get all acknowledgments or declinations from payment service. You wouldn't want to be missing out a message by mixing in tour booking service and a payment service and an admin service and one consumer group, which then causes some of the messages not to get to tour booking service instance. So you have flexibility of scale here because depending on your scalability needs tour booking service could have N number of instances running and all of them are registered as consumers in their own consumer group. So very achievable, but some things to think about. Right, so I think I'm reaching the end, yes. All right, so just to sum it up, don't forget your data. Data integrity within and across multi-user transactions still needs to be handled with microservices, architecture, and in this presentation we've discussed two design approaches to manage data integrity and across transactional boundaries. So thanks for listening everyone and any questions? Thank you.