How to break down a ticket with several story points into parent and child tickets?

Given that we see we have limited resources and only architects can complete tickets of up to 3 points, but tickets of 8+ cannot be finished in a single two-week sprint,

Your problem isn't necessarily the breakdown of work. Many splitting patterns can be found if you search Google. The real problem: You don't have a cross-functional team. For Scrum to be effective, a team should have all the skills necessary to turn work into a value increment every Sprint.

This is where a Scrum Master needs to step up and help you work through the removal of this impediment.

Imagine trying to play a chess game, but there are missing pieces: no queen or rooks. The game isn't very effective. 

Thanks @Chris Belknap for your comments.

What do you mean with cross-functional team? can you give me an example?. What do you mean with "a team should have all the skills...".

What should or how can our Scrum Master help in this sense?.

how do you usually handle complex tickets?

In complex work more is unknown than is known. So think in terms of the smallest possible experiments you can run for figuring out what is really needed. You are not just sawing away at a backlog of work. The Sprint is a validated learning loop in which the Sprint Goal mitigates a significant risk or uncertainty.

The quality of each experiment should not be in question, which means that each increment must satisfy a Definition of Done and be usable. The team should have all of the skills necessary to assure this.

What do you mean with cross-functional team? can you give me an example?

Let's say we have a Scrum Team working on an e-commerce website. To add new features, I need a team of people with all the skills to fully complete work in a Sprint: UX Design, Front-end development (Javascript), database (MongoDB), quality assurance, DevOps, etc. That team would be cross-functional as they don't have to rely on anyone outside the team. Not everyone would have the same depth and breadth as everyone else. One team member might specialize in database work, another in QA. The collective team would have all the skills necessary to complete work and make it potentially releasable every Sprint.

I'm going to take a slightly different approach. Stop thinking in terms of "parent and child tickets" and start thinking about distinct units of work. Stop thinking about "stories" and start thinking about what is needed to improve the product for the stakeholders. 

The Scrum Guide states:

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Notice it said nothing about stories or tickets.  Make the work and improvement clear in any way that makes the most sense.  As a Product Owner (which I am assuming from your other posts) it is your responsibility to ensure that the needs are clear and that the team is working on the right thing at the right time.  Let the Developers break the work into units that they can effectively do in a single Sprint. You own the need, they own the work. 

As @Chris alluded, I think you have more than a problem in defining your Product Backlog Items. I think you have an issue with your team.  I think you may have an organizational issue.  I am not sure why "only architects can complete tickets of up to 3 points" but I would think that is an area that the team should investigate.  Is it because only architects have the necessary knowledge? If so, then those architects need to spend time spreading that knowledge around.  Is it because of some rule? Then there is a rule that needs to change.  Find out why this is happening. 

I would also suggest that the Developers have some serious conversations about their use of story points. It seems like they not fully understand how they work or what a "point" is.  This link will take you to a blog post by Ron Jeffries, who is said to be the person that invented story points. It explains how they began and what he sees as problems that have evolved.  It is a short read and might be good for everyone in your team/organization to read.  https://ronjeffries.com/articles/019-01ff/story-points/Index.html

Scrum, and anything "Agile" for that matter, is not just some process that the software development organization does. It is something that requires the entire organization to adapt. From many of the posts you have made recently, I get the feeling that Scrum terms are being used but not Scrum practices.  And it is seems like agility is not a goal for your organization as much as an excuse to make up rules as you go. Good luck.  I hope that some of the advice we are all giving you is helping.  

Work Breakdown in Iterations: Instead of treating these large tickets as single work units, break them down into multiple iterations (child tickets) that fit into sprints. Each iteration should contribute to a deliverable that gets you closer to completing the overall task. Milestones and Deliverables: If the large task is too complex for one sprint, set intermediate milestones or deliverables for each sprint. These can serve as checkpoints where you can assess whether the work is on track and whether further breakdown is needed.