Sprint Length Vs Working Increment

Due to application architecture complexity we unable to provide a working software in 1 week but we can complete server side layer code and UI layer code in a week and do integration and testing in another week.

Do you think you would then have a Sprint at all?

Due to application architecture complexity we unable to provide a working software in 1 week

I think that answers your question on whether a 1 week sprint is long enough.

Could you ask the team what they think an appropriate sprint length is?

Due to application architecture complexity we unable to provide a working software in 1 week but we can complete server side layer code and UI layer code in a week and do integration and testing in another week.

Is there any feature that can be completely delivered in one sprint (even if your sprint length is longer)? I would very much doubt that nothing can be delivered in a sprint, even the first sprint.

I would suggest looking up the concept of "vertical slicing" to enable you to deliver a working user story in a sprint, rather than doing all of the server side code first.

Functional User story which PO written can not be achieved in 1 week

Can the user stories be broken down smaller to ensure they can fit within a sprint (whether your team decide it's one week or longer)?

Let me put up my question more clear

FYI :  We do refine our stories regularly with team to make fit for sprint length but there are few stories which cannot achieve in 1 week sprint and can not break further down to achieve sensible requiement. 

Reason for the question here is, releasable increment is major parameter for us to decide sprint length in retro (since other parameter, risk  is not high due to sprint length by 1 more week).

Below question is open in Retro  

•  In end of sprint, is releasable increment mandatory? Is demo to stakeholders for feedback mandatory ?  If yes we need to revise our sprint length if not we can continue to decide DoD in Sprint planning whether it is going to be releasable or just development complete. 

@Ian , Can you please be more clear on your comment ? 

There is no RISK that our Sprint Goal may void in weeks time because we already captured agreement on user journeys and screen interactions with all stakeholders. 

Are you yourself actually sure there is no risk? Are others (stakeholders, etc) actually sure there is no risk? You may have signed up for huge surprises down the road.

I'm going to address a couple of other things because everyone above me has said everything that needs to said on those topics.  Now as always I will point out that everything I say is my opinion and not to be considered "Scrum rules". 

1. In Sprint review should team exhibit working demo to Stakeholders or can  it be optional if that can not be done in agreed sprint length ? 

2. If working demo is not available then can we skip Sprint demo session and directly look at other activities in review such as revising current state of PB with stakeholders after discussing percentage of completion in current sprint

There is no "Sprint Demo".  There is a Sprint Review but it is not a demo.  It is an opportunity for the Development Team to review the work that they have done on the increment with the Product Owner and Stakeholders in order to discuss anything that could affect the current Product Backlog.  This next quote comes from the Scrum Guide section on the Development Team. 

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint. 

So, if there is no "working demo" did the Development Team create a potentially releasable increment? 

Now I'm going to voice my immediate reaction when I read your question.  I thought to myself "has the person ever read the Scrum Guide, know anything about Scrum or Agile?"  I would suggest that you take some to read the entire Scrum Guide and try to understand what it is saying. A large part of your questions are answered there if you take the time to understand what is written.  Also, the questions you ask really can't be answered by anyone here starting with this one.

We are planning to create a new web tool. What should be our sprint length? Will 1 week sprint fit for our change

There is no way for us to know if 1 week sprints are a fit for you.  Only your Scrum Teams can determine that.  We could offer advice as we have but your questions are pretty specific and the evidence you provide supports that the answer to almost everything is "No".  Read the Scrum Guide, reread your original post and I believe you will answer a lot of your own concerns.