To elaborate a bit on my comment about switching mechanisms, I'll tell you about what "I had to learn" when I got into the ISP business "for real" back in 2003 and then migrated that company's network to Cisco gear starting in 2004. I'll do this in a slightly more logical sequence than I learned it, to help you follow the flow a bit better.
The 7200 series routers are classic workhorses: solid, reliable, simple. It's modular in that it has six Port Adapter (PA) slots (you'll hear more about PAs later...), plus a slot for an I/O controller (originally for console/aux/flash, later added some Ethernet ports) and a back-side slot for a Network Processing Engine (NPE, which is the brains and forwarding engine of the box). PAs are hot-swappable, IO and NPE are not. These will run forever, but the NPE is a distinct limit to packets-per-second forwarding rate and a NPE swap is necessary to get more horsepower. Packets come in on the PAs, go to the NPE for forwarding, and go out the PAs, period.
The 7500 series routers had a lot of promise, but I'd argue that they never delivered. Take for example the 7507: if I remember correctly, there were two slots for Route Switch Processors (RSP) and five slots for Interface Processors (IPs). In the beginning, it was basically a bigger edition of the 7200: IPs were bigger than PAs, RSPs were different and beefier than NPEs. Packets came in on the IPs, go to the RSP for forwarding, and go out the IPs, and that was it. Cisco later realized that the RSPs couldn't really scale big enough to handle the theoretical throughput possible in the backplane, and that the Internet was growing so packet forwarding mattered. They figured out how to create a Versatile Interface Processor (VIP), which could accept two 7200 PAs in the VIP and allow people to move PAs between different platforms (easier spares, etc.). Later, they figured out how to put a true CPU on the VIP, and push a copy of the CEF FIB down to the VIP, which created "distributed switching". Now, things got really complicated: packets could arrive on an IP and leave on an IP, so the RSP handles the packets like it always has. BUT, if there's a VIP in slot 6, packets might arrive on a VIP and leave on an IP, so they can get forwarded by the VIP but have to ride the backplane over to the IP. Conversely, packets might arrive on an IP and leave on a VIP, so they have to go to the RSP for forwarding then ride the backplane onto the VIP. And of course, packets could arrive on a VIP and leave on a VIP, so the ingress VIP could do the forwarding and not really bother the RSP with the forwarding. HOWEVER, the forwarding tables had a habit of getting ugly at times, so they had to write the code such that you could disable distributed switching. Now all of a sudden, the VIPs turn into glorified IPs, and everything goes through the RSP. At this point, we have perhaps five different possibilities: non-distributed 100% on the RSP, or IP->IP, IP->VIP, VIP->IP, VIP->VIP. I'm sure you're going to say "but wait, if the customer pulls out all of the IPs and only puts in VIPs, they could just stay distributed and clean it all up!" - remember the IPs/VIPs are hot-swappable, so even if there aren't any IPs "right now", an IP could be inserted a second from now, and muck it all up.
Then, the 12000 ("GSR" or Gigabit Switch Routers) came out, somewhere around 1999 or so when the Internet was out of control. Cisco designed it with a switching fabric that was set up in such a way that there's absolutely no way for the entire bandwidth of the box to travel into or out of the Gigabit Routing Processor (GRP). They gave every linecard a CPU, give the CPU a copy of the FIB, and basically declared that distributed switching was mandatory: if the FIB should crash, the linecard goes offline while it reboots (hopefully). Now, although there's complexity in managing a full set of distributed FIBs, the switching strategy is simplified: every packet is routed by the ingress card's CPU, period. Now things are easier, at least with respect to forwarding logic.
Now, do you really want to overlay "queueing or not" on the fly? :) Hopefully, you said no: let's queue everything all the time, even if there's no congestion, and just drain the queues immediately if they're empty.