In this video we're going to get an overview of the next big epic case you're going to work on.
Now this next application really is significantly significantly larger than what we just put together
way more complexity more services.
Everything is just bigger in nature.
I will personally give you a quick overview of some other applications already exist out there so you
may or may not have heard of this app.
It is popular in the U.S. to some degree I suppose.
It's called StubHub and it's all about users selling tickets to sporting events concert stuff like that
to other users.
So we're gonna build something similar in nature to StubHub.
I want to outline very quickly a couple of different properties around StubHub.
So we come to this main page we see a lot of different events and whatnot.
We can click on some given event.
We then get the option to select some time or date to go so I'll select one of these we then get prompted
to select an actual ticket.
And again these are tickets that are for sale by other users.
So I will select some ticket and then go to checkout and then I get prompted to enter a log in or enter
payment information or whatever else I want to really think about what is going on behind the scenes
as we're trying to purchase these tickets.
Imagine that I'm trying to purchase a ticket for a very very popular event.
I don't know what's popular these days but maybe it's just some really popular event so maybe the instant
that tickets get listed for sale.
People just dogpile on it.
In other words tons people come to this website simultaneously and try to buy the exact same ticket.
You probably want to make sure that nobody clicks on go to check out and enters their payment information
for a ticket that has already been sold to some other user.
So you probably want to have some ability to say Hey sorry but someone else is in the process of purchasing
these tickets or something similar.
So with all this in mind let's take a look at a brief summary of some of the business rules or on the
app that we are going to put together.
So we're going to build a ticketing app.
It is definitely let me say right up front it is not going to be as fully featured as StubHub.
So it's not going to have the ideas of say different dates if I can go back to that StubHub we saw just
a moment ago I had different dates and whatnot.
It also had these different defined events.
We're not going to have that level of complexity.
Instead really just going to focus on the ticketing aspect of this.
So in our application users can list tickets for an event for sale.
So these might be tickets to a concert sports a sporting event whatever else other users can then purchase
that ticket after it's been listed any user who signs up to our application can list tickets and purchase
tickets.
So no user is more special than another.
Anyone can sell a ticket.
Anyone can purchase that ticket.
And in our application we're even going to say you can purchase your own tickets if you wanted to for
some crazy reason and here's the really important part.
Whenever a user attempts to purchase a ticket.
So in other words when a user clicks on some purchase button the ticket is then going to be locked for
15 minutes.
So the user will then have 15 minutes to enter their payment information.
So when I say when the user attempts to purchase a ticket I mean like you saw me do just a moment ago
I clicked on go to checkout.
So we're going to take clicking on something like go to check out as a user intending to buy this ticket.
And at that point time we are going to lock the ticket and no other user should be able to purchase
this ticket from out from underneath this person.
So when I click on go to checkout I've not actually entered any payment information or anything like
that.
So I user still has to pay or enter their payment information within 15 minutes.
It is just expressing the intent to purchase the ticket that's going to lock it for 15 minutes.
Now if you don't like the idea of 15 minutes here if you think that's too long it doesn't matter.
I mean we can make this 30 seconds very easily.
When I was first building this application I made the timer 30 seconds just to make it easier to test.
So 15 minutes not at all relevant while that ticket is locked.
No other user can purchase that ticket as a matter of fact.
It's just not even going to be displayed to other users.
So the instant someone locks the ticket other users who are searching for tickets they just won't even
see this one that has been locked naturally after those 15 minutes the ticket should automatically be
unlocked.
So 15 minutes by it or not that's it that's all you get.
And then of course we want to probably allow users to edit tickets because who knows maybe ticket prices
are dropping really quickly and they want to update the price or something like that.
So we should be able to edit a ticket price if the ticket is not already locked.
And this little item right here this nice little thing is going to be a source of some really interesting
challenges.
I mean a lot of this stuff is but this one in particular because it's going to very clearly demonstrate
some big challenges around asynchronous communication in micros services.
I can very easily tell you why imagine this scenario in which some user out there lists a ticket for
one hundred dollars and then some amount of time later another user clicks on purchase ticket.
So in like one is it in time a user attempts to purchase the ticket and things should be locked.
And let's imagine that at the same exact point in time the user who owns the ticket and who listed it
changes the price to a thousand dollars or something like that.
So at the same time one person tries to lock it at the same time someone else tries to change the price.
We're going to run into a ton of scenarios like that where we have to figure out how to handle these
events in some very precise well codified testable fashion.
And that's gonna be where a lot of not just this scenario right here not just this editing why lock.
There's a lot of things like that inside this application we have to deal with.
All right.
That's the overview of the business logic inside a wrap.
Now really quickly I just want to run through a couple of backups.
These mockups are not at all exhaustive.
So these mock ups for example are not showing the actual ticket creation process or editing a ticket
stuff like that.
Nonetheless I want to show you a couple of mockups just so we have some picture in mind of what we're
gonna be building is we're not gonna work on the UI for this for a good amount of time.
We're going to first focus on a lot of back and setup and I just want you to have some picture in your
mind of what we're going to eventually head towards so any user first comes your application.
We're gonna show my list of all the different tickets that are for sale on the top right.
Will have a header that will allow the user to either sign up or sign in for application.
This is going to be real production great authentication.
So like I said we're not really gonna take a lot of shortcuts this time around except for a couple of
locations I can be very clear about.
So this will be very production great authentication.
A user can sign up with an email password.
Once they've signed up they can also sign in.
Once they are authenticated the main landing page is still going to show tickets for sale but then we'll
also update the header as well.
A user can then say sign out.
They can attempt to sell some tickets or they can attempt to take a look at all the orders that they
have in progress.
So in order is when the user has locked a ticket they have created it in order.
Also when a user has successfully purchased a ticket that is an order as well.
So my orders is essentially going to list all the tickets that a user is trying to purchase if a user
clicks on one of these tickets right here.
We're then going to show some them some information about that ticket so it's price and whether or not
it is currently available for purchase.
A user can then click on purchase right there which is equivalent to over on StubHub that go to checkout
button.
So as soon as a user clicks on that purchase right there that is going to start up that 15 minute timer
that's going to lock the ticket as a user will go to a screen like this right here something and says
All right you got 30 seconds left to order.
We're going a little timer right there that automatically counts down.
We'll have a little button right there that is you can click on to pay for the tickets when they click
on that will pop up a little modal like this that allows them to enter in their credit card and expiration.
We are going to handle real credit cards here.
So we're gonna use stripe J.S. or stripe as payment processing.
So we will be able to enter in in theory real credit card numbers with real money all that kind of good
stuff to purchase these tickets.
Again not really cutting a lot of corners here finally I want to mention beyond the fact that remember
this is not the full set of mockups.
I didn't I meant to mention this in the last video we were talking about some of these big changes to
our application.
We are going to have real databases this time around as opposed to our first application.
We're also going to make use of a way more production great event bus than the homemade one we had previously.
So as you can see there's a lot of interesting stuff here.
Lot of UI to build even though this flow right here looks very simplistic in nature.
There's a lot of super subtle very nasty little bugs and opportunities to go crazy in this application.
So it's a tremendous amount of work.
I cannot tell you how much more work this is going to be than the first application but we're going
to learn so much along the way.
And I don't know you can tell from my voice but I'm super excited about this.
So let's take a pause right here.
We're gonna come back the next video and I want to outline some general architecture some the different
technologies we're going to be using.
Is there really is like I said a lot of stuff going on here.
It's a quick pause and I'll see you in just a minute.