Software Architecture for SaaS Cloud Solutions

    Below is a transcript of GovQA’s Audio Series on Software Architecture, which was recorded on February 28, 2020. This episode outlines the differences between single and multi tenant architecture.

    If you like this episode, watch for others here on

    • The State of the State-Level Public Records Landscape — An interview with Jen Snyder, GovQA Chief Evangelist
    • GovQA Product Roadmap: What’s coming next? — An interview with Jann Curtis, Director of Product Development
    • Getting It Done in the World of Public Records — An interview with Will Repole, Chief Operating Officer and Co-Founder of GovQA.

    Interested in subscribing to the GovQA audio series episode alerts?  Sign up below.

    Learn More About Security

    Listen Now

    Episode 03052

    GovQA’s audio series will cover topics that affect and impact both you and your peers in public records managing FOIA requests. From security to legislation to litigation to solutions — this is another way we leverage our experience and expertise to support you in your day to day. Subscribe to never miss a new episode.

    Topic: Software Architecture with Chris Woods, Senior Director of Technology, GovQA

    Subscribe to the GovQA Audio Series

    GovQA’s audio series plans to cover topics of interest to you and your peers in public records. From security to legislation to litigation to solutions — this is another way GovQA supports you day-to-day. Subscribe to be the first to know when new audio episodes are posted.

    Single & Multi Tenant Architecture: The Best of Both Worlds

    How GovQA is Structured:

    1. Single-Tenant client databases for no co-mingling of data
    2. Multi-Tenant, configurable front-end web application

    Recently, we sat down with GovQA Senior Director of Technology, Chris Woods, to talk about software architecture. Listen in or read along to learn what Chris had to say.  The transcript below contains clarification and definitions not in the original audio.

    Open the infographic above to download it for personal use, or use the share buttons below to share to social media.

    View Infographic

    Episode 03052 Transcript

    Software Security for Government Workflow Solutions like FOIA Management

    Melanie: Hello I’m Melanie Pusateri, Marketing Content Manager at GovQA here with Chris Woods, Senior Director of Technology for GovQA.  Welcome, Chris.

    Chris: Hello. Welcome, everybody.

    Melanie: Today we’re going to talk about architecture — software architecture, specifically the differences between single- and multi-tenant architecture. But before we do that, would you mind telling folks a little bit about your role at GovQA?

    Chris: I manage all the development aspects of the GovQA software application.  We have three different environments: one in Azure, one in our datacenter located in Oak Brook, Illinois; and one in Canada. I help manage that process and do a little bit of security and a little bit of infrastructure work as well. 

    Melanie: You’re in the tech department at GovQA; so you could easily go in deep on the technology that we’re going to talk about today.  But we’re going to keep it high level for non-technical folks. I’ll start with a basic question: what do we mean when we say “software architecture?” What are the components involved?

    Chris: For software architecture, you can think of it like architecting a building where you start from the ground up.  With software, it works the same way. You’ve got to build tables, views, things like that in your database and in your code structure to make sure it’s going to last long term. What I mean by that is: you’ve got to think big picture to envision where you want to go. The same with a building – you have an end-game in mind. How tall you want it to be, how wide you want it to be. When you’re designing software architecture, you’ve got to think long-term.  You’ve got to think about the small features that you want in the system, but you’ve also got to plan for what you want to do down the road. 

    Melanie: So then, in the design process, why did GovQA decide to go with a single tenant instead of multi-tenant architecture? 

    Chris: Single-tenant architecture, in our mind, is very security driven. Yes, it’s a little bit more maintenance for the GovQA tech team than multi-tenant. But that doesn’t affect the customer…and we feel strongly that the added security is worth our effort.  That said, we’ve recently switched to a multi-tenant front end for the code base with a single-tenant in the back-end for the database structure. 

    And what that means is everybody runs off the same code base — so when you come into our application, everyone hits the same web server, same code base. Nobody’s on a different code base. 

    Then, when you get into the back-end of our system, all the database customers are separate. No data is ever commingled for customers, which is really secure vs. multi-tenant. In our design, the single-tenant database is more secure but still allows us to be fast in what we’re doing because we have the multi-tenant front end. We can make quick code changes – push those out quickly – and everybody gets the new features. It does add a little bit of maintenance in the back end database.  But that’s why we have a team of people to do that.    

    Melanie: A big team.  How many people do you have back here in tech?   

    Chris: I think we’ve got 25.  And we’re growing.

    Melanie: And that’s just the tech department.  That’s supported by another 80 people throughout the whole company doing customer support, success, sales, implementation, and all the other things that help make GovQA strong. 

    Chris: Absolutely.

    Melanie: Let’s back up for a minute and talk about the differences between a single- and multi-tenant architecture.  You said we have a front end multi and a back end single. But can you get a little more granular in terms of what you mean by that?

    Chris: So, a single-tenant vs multi-tenant architecture, when we’re talking about that, there’s two different sides to it: you’ve got the database side, and the code or web side of the application.  Our database side is all single-tenant, meaning every customer has their own database, their own storage. As far as the web application, they all run the same code base. So that means if we make a change, such as adding a new feature, everybody gets that new feature. Now, we have things in place that can turn things on and off “by customer” which is very beneficial as far as you can roll out something to one customer and another customer doesn’t want that.  They don’t necessarily have to turn that feature on.

    So that’s where we differ. Where we do have the single-tenant back end and the multi-tenant front end. So every customer runs off the same code base. When we do a code push or a release, all those customers get the same code.  There’s nothing different about it. There’s really just turning things on and off in the database itself as far as what customers see…what features they have.  

    Melanie: So the differentiation on the front-end, the configurability, that data where those dynamic points are actually stored is in the single-tenant database in the back-end?

    Chris: That is correct.  So everything is still separated, every configuration that a single customer has is in their own database.  Whereas we have those features that we flip on and off for the front end viewing. And that’s really cool.

    Melanie: Do you have an example of something that could be flipped on and off?

    Chris: Yeah, so one example that we’re actually coming out with here soon is our new attachments page.  We have the ability to turn that on or off by customer…or even by user. So let’s say one customer isn’t ready for it. They haven’t trained their staff on the new attachments page and they don’t want it turned on yet. We have the ability to leave on the old page and let them go with that direction.  And if somebody else wants the new attachments page, we can turn it on for them. And we can run them both at the same time on one particular site too. So, for example, if you want to see the new attachments page but I don’t – we have the ability to do that too, which is really beneficial. Because we can get feedback on things we’ve released and  get some customer input as far as usability – what doesn’t work, what does work. And we can quickly change that to make sure it works for everyone.   

    Melanie: That’s amazing. This is a great way for FOIA officers to learn and test new features themselves before rolling these out to the whole staff. So it really is the best of both worlds – multi-tenant front end; single-tenant back end. 

    Chris: Correct.  You’ve got the security in the single-tenant back end. And the flexibility in the front end with the multi-tenant architecture.

    You can think of a tenant as a customer or a client. So, when you’re doing single-tenant, each customer has their own instance of the software code and database, whereas with multi-tenant, everybody shares the same instance of the software code and database. A lot of big companies out there – like Salesforce – use multi-tenant. But they use it to scale faster; to build things and get them out there quicker.  We can still do that on the front end with our multi-tenant front-end architecture. We just have a little bit more back-end work because our database is single tenancy.

    When you do a multi-tenancy database, all your customers are in one database.  So all their data is co-mingled. It’s all stored in one single layer basically. And if someone were to get in, they could have access to all the customer data. Whereas if someone got into one of our databases it would be isolated just to that customer. So that’s where we differ from a lot of companies.     

    Melanie: Do you have any examples of multi-tenancy causing a problem in terms of security?   

    Chris: I know there have been some hacks recently.  I don’t know the names off the top of my head as far as companies out there that had that happen to them. But, once you get into the database and it’s multi-tenancy, you have access to all that data. Whereas we’ve put security policies and procedures in place that prevent that.  Even if you do get into our database, you still have to know certain things. Like if you get the username and password you still can’t find anything in the database. You would have to know the database structure. And all our databases are unique. You can’t do any “select” statements and find data. Which is just another layer of security. 

    Melanie: And there are also benefits for using single- vs. multi-tenant for customers as well, correct?  So because all the customers are on their own (database) they aren’t affected by anything anyone else is doing?

    Chris: So if someone is, let’s say, updating 10,000 records, it’s only going to affect them. It’s not going to go across all the customers, which is great. Keep in mind, though.  We can configure our solution for any customer situation. We have the front end that’s multi-tenancy –  but we do have the ability to make that single-tenant as well if we want to. It was that way before. Let’s say a specific customer wanted something that was very specific to their needs but didn’t really benefit anybody else; we have the option to actually break that out and give them their own instance and code. We have that flexibility to do that, whereas a lot of companies don’t have that flexibility because we’ve architected it the way we have.  

    Melanie: Yeah, and I feel like you can really see that when you look at the public portals from our customers.  They are all different – and that’s just the front side, I realize, but it shows that we’re configuring the software to their needs instead of the other way around.

    Chris: Right, that’s one of our biggest selling points is how we can brand our portal to look like the agency or client’s website which is a big differentiator for us.  If you look at some of our competitors, they are very “plain Jane.” But this separates us, where a customer can provide feedback and tell us how they want it to look, give us fonts and colors and images that they would like to use.  Or we can (do it for them) and simply copy what they have on their site and take it over to ours and then fit our application inside of that, which is really flexible.   

    Melanie: They can have a hand in it if they want to…or they can say “you do it” and we will..

    Chris: Right, they can say, “tell me when it’s done and I’ll look at it”.  

    Melanie: Talk to me about releases. When we update our software, how does that figure into the single/multi tenant discussion, if at all?

    Chris: It does, our code base is multi- tenant – so it’s just one code base that we push out to all our web servers that runs the core application.  Then we have the databases. Whereas in multi-tenancy systems you just have one database to update. In our environment we have much more than that.  We have thousands of databases that we have to update. So it really just takes a longer period of time to do those updates. That’s really the biggest difference. Other than that, it’s pretty much the same.      

    Melanie: The customer doesn’t know that it’s taking a long time because they’re just waiting for the release to be live.

    Chris: That’s another big piece.  When that update does happen, when the code is pushed and that customer’s database is finished updating, it’s like it never happened.  It’s a split second during the release. So, we send out notifications to let them know we are doing our quarterly release. So, it’s really just time that is the biggest difference.

    Melanie: And we time these to happen over the weekend, when government offices are closed.  By the time customers get to their desks to start their weekday, the release has been fully pushed and tested.

    I was wondering if there’s something unique about the state and local government world that makes single-tenant a better choice? Something that comes to mind is a topic we touched upon a minute ago – just that they are all so different.  And they’re all in different stages of automating their workflows. Do you think single-tenant is a better choice because it’s not forcing them to change all their processes all at once?

    Chris: Absolutely.  From a security standpoint, it’s 100% better in my mind. Their data is very separate.  If we do have local governments, say they want to make a minor change that maybe would come out in the next release but they want it sooner, we can do it sooner for them because they are separate. Now as far as the workflows, let’s say you’ve got a huge customer that has 500 workflow items; that won’t affect how another customer, that’s a small agency, maybe only has 10 workflows – that won’t affect their processing. It’s completely separate.   

    Melanie: What should someone who is listening now and currently using an on-prem solution think about when they are looking at cloud providers? What questions would you recommend they ask about single/multi tenant or the software architecture in general?

    Chris: My biggest thing is: security…ask the security questions. Where is my data being stored?  Is it being backed up? How often is it being backed up? Where is it being backed up to? Who has access to my software?  Whether it’s someone like us, that is hosting the software and implementing the software, and has access to that data; are there procedures in place to prevent someone from accidentally getting my data or deleting my data?

    So, those are the types of questions I would ask. Just make sure security is top of mind. Because with all these on-prem solutions – I don’t know how often you guys read the news, but a lot of the hacks are happening to on-premise solutions. Just because they don’t have as good security as some of these hosted solutions do — such as Azure, Amazon, and some others out there. (Hosted solutions) have the built-in security already that you don’t have to manage. They do it all for you, so it just takes another layer away that you don’t have to deal with. And they are always doing updates; so you don’t have to manage that whole process.

    Melanie: So the government IT guys listening in are like, “Hey, I don’t have to do anything?  Great! Where do I sign up?”

    Chris: Yes, and a lot of people from an AD (active directory) perspective, as far as logins; they move to the cloud so they don’t have to have a server in their on-premise solution to host that. They can just move it (the active directory) to the cloud and manage it there. They don’t have to worry about hardware costs, things like that. It’s all managed for them.  

    So the best part of our solution is you don’t really have to have IT involved. Maybe if you’re doing an integration or something, you may have to. But 90% of the time, if not more, you don’t have to have IT involved. You may have to get some type of signoff from them just to get their blessing, but that’s about it.  The best part about our service is IT doesn’t have to get involved. They don’t have to maintain hardware or security. We do all that – we provide that to the customers, which is really a good benefit for our customers. They don’t have to maintain anything – it’s all up in the cloud.       

    Melanie: And security is taken care of…

    Chris: And security is taken care of for them. They don’t have to worry about it. They could add their own security on top of it via ADFS integration if they’d like to.  They don’t have to. But a lot of customers do that; just so they have one single login for everything. IT may need to get involved for that – but that’s pretty much it. We handle all the security wrapped around the database, the application itself.  They don’t have to worry about that stuff. We do our scans, remediations and all the great things that security has.   

    Melanie: Thanks for talking to us today! If anyone has any questions, I’m sure you would be willing to take questions offline?  

    Chris: Absolutely. Thank you for having me.  

    Subscribe to the GovQA Audio Series

    GovQA’s audio series plans to cover topics of interest to you and your peers in public records. From security to legislation to litigation to solutions — this is another way GovQA supports you day-to-day. Subscribe to be the first to know when new audio episodes are posted.

    The Peers in Public Records Newsletter (formerly FOIA News) is a bi-monthly e-newsletter brought to you by GovQA. It is a collection of the latest trends in public record requests and government transparency initiatives, shared stories, informative case studies, and actionable knowledge that will help you calm the chaos and keep your organization compliant. Send your comments to

    Subscribe to the Peers in Public Records Newsletter