A little bit of planning before we start to code the board, to start we need to be able to add, delete and search the jobs in the job board, this is the minimum functionality we are going to need just to get started.
Having built some of this before, and because I am a back-end engineer, I am going to start with the backend services.

So here we have three web functions that will post, delete and search.

Post Job: will take some data, validate it as being a valid job and then raise a command message, directed at a Post Job Worker, the worker validates the incoming message and stores the given data in the data store, then raises a Job Changed Event, to inform the rest of the system about the change in the job.

Delete Job: will take some data, validate it as being a valid existing job and then raise a command message directed at a Delete Job Worker, the worker validates the incoming message and marks the data as deleted in the data store, and then raises a Job Changed Event to inform the rest of the system
about the change in the job.

Search Jobs will take some search criteria, validate it, and make the appropriate call to the search jobs worker, this will return the required data to the user.

Why the messaging between the “Public API” and the workers, in fact why have the workers? This is all to do with the preservation of data primarily. When a user posts a job, we do not want to ever lose that data in a failed, using a messaging system with dead queues will allow us to replay failed validated messages, this is important if someone is paying money for us to display their job. We are allowing for failure directly the data has been validated.

What about this Job Changed Event? So far all we are building is the bones of a system, if we want to add calls to google indexing API, because the job has been updated or deleted, how about an email to subscribed users when a job matching some criteria arrives, these systems will need to know about changes to the jobs, and this event can tell those systems.

We now have a plan of what we are going to build, the questions now are.

1. What is the data store going to be?
2. What is the public API, a web API, or functions?
3. What messaging system are we going to use?
4. What are the workers? another API or functions?
   
   Let’s start with the easy ones first:
   
   Question 2: The public API will be a web API, it looks the best way to go having spun up the template, we get a nice swagger ui, which will be great for initial testing

Question 4: Mainly because we have used the web API template for the public api, and this is as much an exercise in learning as anything else, the workers will all be functions triggered by receiving a command message.

Question 1: A Job Advert feels like a document, we will probably change its shape as well develop the system potentially even after release, a SQL database feels a bit to ridged, Key/Value store, may not give us the search flexibility we may need in the future, we are on Azure so let’s go with Cosmos-db and see where this takes us.

Question 3: On AWS this would be SNS/SQS, there must be an equivalent in Azure, looking that all up, it appears that Azure Service Bus and Queue Storage

Now to create some work item tickets on the Azure devops board, and look into building a walking skeleton, deployed to Azure.